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 <nfx...@googlemail.com> wrote: > On Thu, 21 Jan 2016 15:57:38 -0800 > Neil Birkbeck <neil.birkb...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
