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.birkb...@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 <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
