[FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.

[Neil Birkbeck]

Also, the mkv adjustments are here:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=sZyfPTM-QY69P-0omfOIiTN622o


On Fri, Jan 22, 2016 at 2:54 PM, Neil Birkbeck <neil.birkbeck at gmail.com>
wrote:

> Hmm. I don't have a good idea of how likely it is for this conversion to
> float (by dividing a constant) to not be bit-exact on different
> architectures (compilers?) when there should not be any other math
> transforming the metadata (other than the conversion back to the integer
> coding for cases like hevc, which for a given architecture is possible
> without loss). The fact that this could happen at all does make it annoying
> in terms of bit-exact test expectations across arch, and this is the main
> concern, right? (for this type of metadata, it is really a hint to
> TVs/algorithms, and some will ignore it altogether)
>
> I suppose we already have that problem when converting from some internal
> rational to any float field in mkv (say "Duration", or
> "SamplingFrequency"), as even converting these fields to a AVRational
> inside ffmpeg eventually has to do the division to get a float/double for
> mkv.
>
>
>
>
> On Fri, Jan 22, 2016 at 1:01 AM, wm4 <nfxjfg at googlemail.com> wrote:
>
>> On Thu, 21 Jan 2016 15:57:38 -0800
>> Neil Birkbeck <neil.birkbeck at gmail.com> wrote:
>>
>> > Thanks for the quick review, Michael.
>> >
>> > The display primaries are encoded as integers (rational with fixed
>> > denominator, I guess) in h265 and HDMI InfoFrames (but in mkv
>> extensions,
>> > they will be floats). Float is sufficient to represent the 16-bit
>> integer
>>
>> Is there still a chance to stop Matroska from making this mistake?
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>