Beiträge von Vouk

Can you please try premiere connector 1.9.0 and check if the issue has been fixed?

Nice, you've found a really old bug. Will be fixed in the next version.

Unfortunately the zones parameter is even more complicated (https://encodingwissen.de/codecs/x264/referenz/#zonen) and it would take up more space to explain it in detail, but I have added your example as deactivated default value. So people get an idea on how to use it.

Did you run both installers?

• Voukoder application itself
• Voukoder connector for DaVinci Resolve

It's alright.

I can check this, but ... did you try this already?

Can you make a screenshot of this?

Voukoder 10 - RC2

RELEASE CANDIDATE - NOT FOR PRODUCTION USE!

Make sure you are using the latest connector for your application(s). For using NVENC (SDK 9.1) encoders driver version 436.15 or later is required.

Fixes / Changes (since version 9)

• Added options to set the language meta data for audio and video tracks
• Fixed intel QSV issues (Update your driver)
• Fixed x265 lossless preset (previousely it was near-lossless)
• Added MPEG2 encoder (with VOB, M2V and TS) container
• Removed non-working h264_nvenc 10 bit modes

Credits

Thanks to my all supporters by either PayPal, Patreon or BTC. Also thanks alot to the translators.

Top Patrons

Gronkh, Schauerland, Andreas Martin Aanerud, Michael Wooldridge and Chris Woods

Download

• https://github.com/Vouk/voukoder/releases/tag/10rc2

10 bit seems export works with HEVC/h265 (with GPUs supporting it), but not with AVC/h264.

Zitat von fabricio1211

The problem was h265 qsv, h264 qsv works fine.

Exactly. My intention was that people should test if HEVC is available now (on processors supporting HEVC encoding).

• I created an SMTPE bars MXF clip with premiere:
  
  
• Renderer this with DVR / Voukoder to ProRes 422HQ:
  
  

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '..\..\..\Desktop\smtpehd.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 512
    compatible_brands: qt
    encoder         : Lavf59.2.101
  Duration: 00:00:05.00, start: 0.000000, bitrate: 21835 kb/s
  Stream #0:0: Video: prores (HQ) (apch / 0x68637061), yuv422p10le(tv, bt709, progressive), 1920x1080, 21562 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default)

Can you please provide exact steps on how to reproduce this issue?

What player do you use?

I will check it tomorrow (sunday).

Added MPEG2 encoder (with VOB, M2V and TS) container

Available in next release.

Please test it. That was what I tried to fix. The Download link is above.

Yes, the other icons look colorful and maybe childish, but they look better than the old b/w ones.

You stated your request to change them (without providing better ones), it got rejected. Live with it.

There is not that much space left for your jokes anymore. I worry about your behaviour quite a while now, and other people start complaining about you too - and I agree with what they say.

Yes, you have your opinions, okay, good. I listen to what people say (that's what this forum/discord/twitter is for), I even checked lots of your feature request for feasability, but that doesn't necessarily mean I have to do exactly as you/they say.

Just be patient and respect other people and their opinions.

Yes, unfortunately it was not fully compatible with other parts of Voukoder and it would require major parts of it to be rewritten. Even the connectors and their ABI would require changes.

My plan is to add it back in that voukoder successor where i address all these limitations and issues.

Zitat von PC User

These rainbow icons do not remind you of anything !?

So that's the real reason why you want that icon to be changed? Because it is rainbow colored and reminds you to gay people and diversity in general?

If so, be be tolerant man and respect other peoples life styles and identities.

P.S.: It was never intended to mean anything like that, but if some people get triggered by this possible meaning i'd love to change the meaning to exactly that.

P.P.S.: I didn't design the logo. Credit goes out to noar for doing that.

It is not completely broken. It was just working in near-lossless mode ( https://x265.readthedocs.io/en/stable/lossless.html ) which is 99,9% lossless.

It is fixed in the next version.

P.S.: One post would've been enough.

Yes, I got the same result with mediainfo, and it doesn't look right. I even confirmed this with testing the file using this method: https://superuser.com/questions/1487…able-frame-rate

ffmpeg.exe -i filename.mkv -vf vfrdet -an -f null -

MP4

frame=  125 fps=0.0 q=-0.0 Lsize=N/A time=00:00:05.00 bitrate=N/A speed=68.8x
video:65kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[Parsed_vfrdet_0 @ 00000167765a3ec0] VFR:0.000000 (0/124)

MKV

frame=  125 fps=0.0 q=-0.0 Lsize=N/A time=00:00:05.04 bitrate=N/A speed=  73x
video:65kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[Parsed_vfrdet_0 @ 0000029a8cbea240] VFR:0.032258 (4/120) min: 19 max: 61 avg: 40

It also only seems to happen when an audio track is included.

I will investigate this.

Edit:

[FRAME]

media_type=video

stream_index=0

key_frame=1

pkt_pts=0

pkt_pts_time=0.000000

pkt_dts=0

pkt_dts_time=0.000000

best_effort_timestamp=0

best_effort_timestamp_time=0.000000

pkt_duration=40

pkt_duration_time=0.040000

pkt_pos=722

pkt_size=2883

[/FRAME]

[FRAME]

media_type=video

stream_index=0

key_frame=0

pkt_pts=61

pkt_pts_time=0.061000

pkt_dts=61

pkt_dts_time=0.061000

best_effort_timestamp=61

best_effort_timestamp_time=0.061000

pkt_duration=40

pkt_duration_time=0.040000

pkt_pos=5652

pkt_size=23

[/FRAME]

[FRAME]

media_type=video

stream_index=0

key_frame=0

pkt_pts=101

pkt_pts_time=0.101000

pkt_dts=101

pkt_dts_time=0.101000

best_effort_timestamp=101

best_effort_timestamp_time=0.101000

pkt_duration=40

pkt_duration_time=0.040000

pkt_pos=6798

pkt_size=23

[/FRAME]

Frame 0:

• Time: 0ms
• Duration: 40ms

Frame 1:

• Time: 61ms (Should be actually 40ms here!)
• Duration: 40ms

Frame 2:

• Time: 101ms (Should be actually 80ms here!)
• Duration: 40ms

...

So when analyzing the stream it finds the first frame takes 61ms, the second 40ms and there we have a variable frame rate.

It looks to me this is happening from rescaling the timing from 1/25 to 1/1000 and syncing it with the audio track sample rate. If I change the sample rate the offset (61ms) changes too. Seems this issue is deep within FFmpeg.

I tested this and this happens as soon as you say "preset=bd". I don't know if that is a bug or a feature, but if it's a bug it's most likely in FFmpeg or in NVENC.

What happens if you use a different preset? Does that work on your player?