VirtualDub2

[rgr]

Something's wrong with ProRes encoding -- YUV444 profiles save in YUV422 format.
YUV444+alpha profiles, on the other hand, always save in YUV444P12 (maybe that's how it's supposed to be, but I think without XQ, it should save in P10).

There's a missing YUV444P10 profile, but there should be two:

10-bit 4:4:4 Profiles:
-profile:v 4 -pix_fmt yuva444p10le ProRes 4444 (10-bit)
-profile:v 5 -pix_fmt yuva444p10le ProRes 4444XQ (10-bit)

.

[v0lt]

Originally Posted by rgr

Something's wrong with ProRes encoding -- YUV444 profiles save in YUV422 format.
YUV444+alpha profiles, on the other hand, always save in YUV444P12 (maybe that's how it's supposed to be, but I think without XQ, it should save in P10).

Show a screenshot of the settings when you get the wrong result.

There's a missing YUV444P10 profile, but there should be two:

10-bit 4:4:4 Profiles:
-profile:v 4 -pix_fmt yuva444p10le ProRes 4444 (10-bit)
-profile:v 5 -pix_fmt yuva444p10le ProRes 4444XQ (10-bit)

And they were there (at least one) before the encoder window changed.

The "4444" and "4444xq" profiles are available when selecting the "YUV 4:4:4 + Alpha" format.

[rgr]

Which prores_ks setting is Quality equivalent to? Bitrate?

[poisondeathray]

Originally Posted by rgr

Something's wrong with ProRes encoding -- YUV444 profiles save in YUV422 format.

In Apple ProRes terminology (see the whitepaper), "HQ" indicates 10bit422 pixel type only . The term "HQ" is reserved. "HQ" is not a quality control slider for a given pixel type. For example, you cannot have "Prores HQ" and 4:4:4 .

4:4:4:4 pixel type can only be Apple Prores 4:4:4:4 and Apple Prores 4:4:4:4XQ

So the profile "HQ" setting selection in vdub2 is probably overriding the YUV 444 settings, and that would be correct behaviour. Perhaps it could be redesigned so "illegal" combinations are greyed out, or maybe a warning message

[v0lt]

Originally Posted by rgr

It works correctly for me. Here's how it plays in ffplay

Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 640x480, 17283 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)

Which prores_ks setting is Quality equivalent to? Bitrate?

-qscale:v
https://trac.ffmpeg.org/wiki/Encode/VFX#Prores

[poisondeathray]

Originally Posted by v0lt

It works correctly for me. Here's how it plays in ffplay

Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 640x480, 17283 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)

I'd argue that's technically incorrect - and that could cause compatibility issues in some programs

fourcc "apch" indicates Apple ProRes 422 (HQ)

[rgr]

Originally Posted by v0lt

It works correctly for me. Here's how it plays in ffplay

Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 640x480, 17283 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)

It doesn't matter anymore (last post)
The source was 16-bit YUV444?
I'll check again.

-qscale:v
https://trac.ffmpeg.org/wiki/Encode/VFX#Prores[/QUOTE]

Thx.

[rgr]

Originally Posted by poisondeathray

I'd argue that's technically incorrect - and that could cause compatibility issues in some programs

fourcc "apch" indicates Apple ProRes 422 (HQ)

I think it would be best to use the options provided here: https://github.com/oyvindln/vhs-deco...e-FFmpeg-Guide

Profiles can be the following:
10-bit 4:2:2 Profiles
-profile:v 0 -pixel_format yuv422p10lep - ProRes Proxy
-profile:v 1 -pixel_format yuv422p10lep - ProRes LT
-profile:v 2 -pixel_format yuv422p10lep - ProRes 422 (Standard)
-profile:v 3 -pixel_format yuv422p10lep - ProRes HQ

10-bit 4:4:4 Profiles
-profile:v 4 -pix_fmt yuva444p10le ProRes 4444 (10-bit)
-profile:v 5 -pix_fmt yuva444p10le ProRes 4444QX (10-bit)

12-bit 4:4:4 Profiles
(Well when FFmpeg finally pushes a fix for ProRes 12-bit...) -- ???
-profile:v 4 -pix_fmt yuva444p12le ProRes 4444 (12-bit)
-profile:v 5 -pix_fmt yuva444p12le ProRes 4444QX (12-bit)


The FourCC codec IDs for the different Apple ProRes variants:
Apple ProRes 422 High Quality: apch (hcpa in little-endian)
Apple ProRes 422 Standard Definition: apcn (ncpa in little-endian)
Apple ProRes 422 LT: apcs (scpa in little-endian)
Apple ProRes 422 Proxy: apco (ocpa in little-endian)
Apple ProRes 4444: ap4h (h4pa in little-endian)
Apple ProRes 4444XQ: ap4x (x4pa in little-endian)

[rgr]

gives:

Video: APCH 1920x1080 59.94fps 1012627kbps [V: prores hq, yuv422p10le, 1920x1080, 1012627 kb/s]

(MediaInfo)

but also MediaInfo:

Video
ID                             : 1
Format                         : ProRes
Format version                 : Version 1
Format profile                 : 422 HQ
Codec ID                       : apch
Duration                       : 67 ms
Bit rate mode                  : Constant
Bit rate                       : 1 013 Mb/s
Width                          : 1 920 pixels
Height                         : 1 080 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 59.940 (60000/1001) FPS
Color space                    : YUV
Chroma subsampling             : 4:4:4
Scan type                      : Progressive
Bits/(Pixel*Frame)             : 8.147
Stream size                    : 8.06 MiB (100%)
Writing library                : Lavc
Matrix coefficients            : BT.709

ffmpeg:

  Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 1920x1080, 1012627 kb/s, 59.94 fps, 59.94 tbr, 60k tbn (default)

The results are ambiguous

Now I know why Vegas is going crazy with these files and interpreting them however it wants

Edit:
But looking at frame properties makes it even more interesting

frame,video,0,1,0,0.000000,0,0.000000,0,0.000000,1001,0.016683,36,2105459,1920,1080,0,0,0,0,yuv444p12le,N/A,I,0,0,0,0,tv,bt709,unknown,unknown,unspecified
frame ,video,0,1,1001,0.016683,1001,0.016683,1001,0.016683,1001,0.016683,2109591,211401 6,1920,1080,0,0,0,0,yuv444p12le,N/A,I,0,0,0,0,tv,bt709,unknown,unknown,unspecified

[poisondeathray]

Originally Posted by rgr

I think it would be best to use the options provided here: https://github.com/oyvindln/vhs-deco...e-FFmpeg-Guide

That would be ideal ;

But for any alpha channel 4444 profiles, prores_ks should be used instead - because -c:v prores still has the "not full alpha channel bug" . eg. for 12bit you get 4092 instead of 4095 . This leads to partial transparency when something should be 100% opaque. (But this is not a vdub2 issue , it's a libavcodec issue)

Originally Posted by rgr

The results are ambiguous

Now I know why Vegas is going crazy with these files and interpreting them however it wants

That's why it's important to get as close as to apple certified specifications as possible. Various bugs and handling issues in different programs

[rgr]

But I must say that I haven't been able to get Yuv444p10 with FFmpeg either. FFmpeg (7 and 8) happily reports that "output will be in Yuv44p10," but the final output is always 12-bit.

Report submitted: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20468

[rgr]

Originally Posted by poisondeathray

prores_ks should be used instead

Right.

[poisondeathray]

Originally Posted by rgr

But I must say that I haven't been able to get Yuv444p10 with FFmpeg either. FFmpeg (7 and 8) happily reports that "output will be in Yuv44p10," but the final output is always 12-bit.

Report submitted: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20468

Apple Prores 4444 is supposed to be 12bit (the whitepaper says "up to") , and up to 16bit for the alpha

Funny because Years ago, people were complaining that the ffmpeg variant was 10bit only, it finally got fixed 12bit to match official Prores 4444 a few years ago. Now you're complaining you want 10bit ???

But I've never seen Official Apple Prores 4444 come in 10bit (from a certified implementation) . There are old ffmpeg produced 10bit4444 prores streams which sometimes caused problems in editors such as glitched frames - I wouldn't consider those completely valid streams, but early days for ffmpeg prores

[rgr]

Originally Posted by poisondeathray

Apple Prores 4444 is supposed to be 12bit (the whitepaper says "up to")

"Up" doesn't mean "only".

From official spec:
Like standard Apple ProRes 4444, this codec supports up
to 12 bits per image channel and up to 16 bits for the alpha channel.

[rgr]

OK, available profiles:


10-bit 4:2:2 Profiles
-profile:v 0 -pixel_format yuv422p10lep - ProRes Proxy
-profile:v 1 -pixel_format yuv422p10lep - ProRes LT
-profile:v 2 -pixel_format yuv422p10lep - ProRes 422 (Standard)
-profile:v 3 -pixel_format yuv422p10lep - ProRes HQ

10-bit 4:4:4 Profiles (unavailable now)
-profile:v 4 -pix_fmt yuva444p10le ProRes 4444 (10-bit)
-profile:v 5 -pix_fmt yuva444p10le ProRes 4444QX (10-bit)

12-bit 4:4:4 Profiles
-profile:v 4 -pix_fmt yuva444p12le ProRes 4444 (12-bit)
-profile:v 5 -pix_fmt yuva444p12le ProRes 4444QX (12-bit)

And pix_fmt doesn't have to be specified.

[poisondeathray]

Profile 4 and 5 for 10bit are the same as 4 and 5 for 12 bit. (ie. There is no 6 or 7; it's not a typo, you can look at the ffmpeg libavcodec code)

I'd feel better if you could produce an official Apple Certified Prores 4444 stream at 10bit . I tried before with various Apple Certified software, it's not possible (at least back then). If you could do that, it would provide evidence for developer to make that a valid option

When you make hacked streams that software does not expect or it's a bit "off" from the certified implementations, you potentially end up with problems. Look at your Sony Vegas experience with some of these streams.

If you really wanted to, try using a ffmpeg build about 6-7 years ago. The Prores 4444 streams were 10bit only (12bit was not available) - this is what people were complaining about . Those streams had problems in software like Resolve (I'm not sure if it was the direct reason)

[rgr]

Originally Posted by poisondeathray

Profile 4 and 5 for 10bit are the same as 4 and 5 for 12 bit. (ie. There is no 6 or 7; it's not a typo, you can look at the ffmpeg libavcodec code)

Yes, I know -- in these cases pix_fmt determines the bit depth (i.e. it should, because it doesn't work).

[rgr]

Originally Posted by poisondeathray

Those streams had problems in software like Resolve (I'm not sure if it was the direct reason)

Are you suggesting that if an app has a problem with a file encoded according to the official specification, it's the video file's fault, not the app?

[poisondeathray]

Originally Posted by rgr

Are you suggesting that if an app has a problem with a file encoded according to the official specification, it's the video file's fault, not the app?

There are no problems with Apple certified streams (or very rare compared to the ffmpeg/libavcodec produced prores )

The situation has improved significantly with "unofficial" ffmpeg/libavcodec created prores encodes - but you still get cases of bugs and odd behaviour . The "unofficial" streams have a significantly higher failure rates on Mac HW silicon decoding affecting many programs (Resolve, Adobe, FCPX) - bugs like flickering, odd bad frames . SW decodes tend to have fewer problems, but they still occur albeit much less frequently than 5-10 years ago

[rgr]

I'm just noticing that last month VirtualDub created a YUV444P10 file for me using the HQ profile

frame,video,0,1,0,0.000000,0,0.000000,0,0.000000,1001,0.016683,36,2649757,1920,1080,0,0,0,0,yuv444p10le,N/A,I,0,0,0,0,tv,bt709,unknown,unknown,unspecified

And this despite the fact that Media Info at MPC thinks otherwise.

Video: APCH 1920x1080 59.94fps 1155238kbps [V: prores hq, yuv422p10le, 1920x1080, 1155238 kb/s]