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

Neil Birkbeck neil.birkbeck at gmail.com
Fri Jan 22 23:54:21 CET 2016


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
>


More information about the ffmpeg-devel mailing list