On Mon, Feb 08, 2016 at 09:36:42AM -0800, Neil Birkbeck wrote:
> I'm sending an updated patch that persists the data within the CVS
> (between IRAP access units with no_rasl_output_flag=1). If this seems
> like overkill, we can fallback to Hendrik's suggestion of just sending
> it once. I did
I'm sending an updated patch that persists the data within the CVS
(between IRAP access units with no_rasl_output_flag=1). If this seems
like overkill, we can fallback to Hendrik's suggestion of just sending
it once. I did consider this alternative but figured the side data
could get lost if some
On Fri, Feb 5, 2016 at 3:05 AM, Neil Birkbeck wrote:
> According to the ITU-T H.265 v3, in Table D - 1, the persistence scope
> of the mastering display metadata is "The Coded Video Sequence (CVS)
> containing the SEI message". So I guess we want to clear when we start
>
According to the ITU-T H.265 v3, in Table D - 1, the persistence scope
of the mastering display metadata is "The Coded Video Sequence (CVS)
containing the SEI message". So I guess we want to clear when we start
the next CVS, so I guess when we see the next IDR frame.
Given that the SEI comes
On Thu, Feb 04, 2016 at 06:05:08PM -0800, Neil Birkbeck wrote:
> According to the ITU-T H.265 v3, in Table D - 1, the persistence scope
> of the mastering display metadata is "The Coded Video Sequence (CVS)
> containing the SEI message". So I guess we want to clear when we start
> the next CVS, so
On Mon, Feb 01, 2016 at 12:11:10PM -0800, Neil Birkbeck wrote:
> Please see updated patch.
>
> On Mon, Jan 25, 2016 at 11:39 PM, Neil Birkbeck
> wrote:
> > I guess png is another example; 10 is the denominator for the 32-bit
> > integer:
> >
Please see updated patch.
On Mon, Jan 25, 2016 at 11:39 PM, Neil Birkbeck wrote:
> I guess png is another example; 10 is the denominator for the 32-bit
> integer:
>
I guess png is another example; 10 is the denominator for the 32-bit
integer:
https://github.com/FFmpeg/FFmpeg/blob/b58cfa616c169c90166938608e7135cdab5820e0/libavcodec/pngenc.c#L290
In the standards, the primaries and white point coords are usually only
referenced in 2-4 significant figures
On Mon, Jan 25, 2016 at 10:37 PM, Michael Niedermayer
wrote:
> On Fri, Jan 22, 2016 at 02:54:21PM -0800, Neil Birkbeck 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
>>
On Thu, 21 Jan 2016 15:57:38 -0800
Neil Birkbeck 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).
Also, the mkv adjustments are here:
https://mailarchive.ietf.org/arch/search/?email_list=cellar=1=sZyfPTM-QY69P-0omfOIiTN622o
On Fri, Jan 22, 2016 at 2:54 PM, Neil Birkbeck
wrote:
> Hmm. I don't have a good idea of how likely it is for this conversion to
> float (by
On Thu, Jan 21, 2016 at 02:26:39PM -0800, Neil Birkbeck wrote:
> Add support for parsing SEI_TYPE_MASTERING_DISPLAY_INFO and propagate
> contents into
> the AVMasteringDisplayMetadata side data. Primaries are ordered in RGB order
> and
> the values are converted to the natural ranges ([0,1] for
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
encoding from hevc, so suspect there is not
13 matches
Mail list logo