[FFmpeg-user] yuv422p16le silently converted to yuv422p10le - even if pix_fmt is set to 16bit

[Carl Eugen Hoyos]

Andy Civil <andycivil <at> gmail.com> writes:

> > Don't you agree that the behaviour (not encoding 10bit
> > information as 16bit) is intended and desirable?
> 
> One of the benefits of community software is that it frees you from the 
> corporate megalith philosophy of serving you what they think you want,

> rather than what you actually ask for.

The important point is that no pixel_format was asked for 
by the user, ffmpeg had to auto-select one.
In the past, it sometimes behaved erratically, I strongly 
believe that the changes that have been made in this 
regard are very important.

That said, I misunderstood the original question (thank you, 
Michael, for pointing it out):
FFmpeg is not choosing colour spaces in this case, 
but the v210 decoder is older than the yuv422p10 colour 
space.
I was so far against changing it to output yuv422p10, but 
I understand now that the current situation may be confusing, 
the patch should be simple. 
(volunteers?)

To elaborate: There is always only 10 bit of yuv422 in 
the whole operation, in the past this was (to reduce the 
number of colour spaces) called "16 bit yuv 422 with 10 
bit of information". When the additional colour space was 
added, the ffv1 decoder was changed to actually use the 
new colour space. At no time was there more than 10bit 
encoded or decoded, the only bug I see is that ffmpeg -i 
does not tell about the number of used bits (only the 
colour space).

> There are many reasons for wanting something illogical 
> such as a 10-bit sequence encoded as 16-bit; we depend 
> on FFmpeg doing what we ask and not something else.

And this is exactly what FFmpeg does if (and of course 
only if) you specify that you want something illogical 
which was not done in this case.

Carl Eugen