[FFmpeg-user] maintaining full swing when encoding in 10 bit (want to preserve all values from 0-1023)

[Andy Furniss]

Marwan Daar wrote:
> On 11/11/2015 10:18 AM, Andy Furniss wrote:
>>
>> Possibly because it did work but every video player by default
>> will assume limited range for yuv so stretch and not display
>> anything above/below the video levels. It will also be pot luck
>> whether by default you will get to see 10 bit 444 or whether the
>> player ends up converting it to 8 bit 420.
>
> I'm using media player classic with madVR. It's configured for 10 bit
>  output and full range. More importantly, when I view the png file
> using madVR, it renders perfectly (full range, and in 10 bit), which
> leads me to believe the issue is with the encoded mp4 file, rather
> than the madVR playback. I could be missing something critical here,
> though. Perhaps the decoding requirements for a png and an mp4 file
> are dissociated in such a way that 10 bit playback is respected for
> one but not the other. I really don't know. I'll look into imagemagic
> and see if I can get any more information.

OK, I don't know about windows software.

>>
>> FWIW using your 1.png I can convert to full range yuv44410le and
>> back to png and the result is very similar to the master (=+1 on
>> the values as shown by imagemagic display).
>
> That's very encouraging! Did you use Zeranoe's 10 bit build to do
> this?

No, I am testing on Linux and was specifically looking at whether it was
possible to get full range working with 48 bit png -> yuv and back. I
didn't go as far as actually encoding with x264. If I had the only test
I would be able to do was get a screen dump (8/24 bit) of the output of
a player which would have made looking at numbers compared to the master
more difficult. Just because you are using 10bit the result of playing
will still be 8 bit as that's what most computer screens are.

This doesn't mean that 10 bit yuv is pointless as X bit rgb -> 8 bit yuv
and back looses loads of colours, so 10 bit yuv is better even if your
source is only 8 bit rgb.

> p.s. I haven't been able to figure out what "le" vs "be" refers to
> (e.g. yuv44410le). Do you know what it means?

little endian and big endian.