On 10/23/2021 7:25 PM, Jan Ekström wrote:
> Since effectively D has taken over NAL unit 62 for this stuff, just
> call it RPU_BUFFER or so, and take in everything NAL unit 62?
Sounds OK to me if others are OK.
- Derek
___
ffmpeg-devel mailing list
ffmpe
On 10/23/2021 7:15 PM, James Almer wrote:
>> Do'h, will fix.
>
> That being said, would Dolby RPU NALUs like this using other values for
> temporal and layer id be valid? Or can we just assume that's never
> happening?
They also use 63 for an EL, according to other codebases an docs. I didn't
i
On Sat, Oct 23, 2021 at 9:16 PM James Almer wrote:
>
> On 10/23/2021 2:52 PM, Derek Buitenhuis wrote:
> > On 10/23/2021 3:18 PM, James Almer wrote:
> >> 0x7c01 is just the NAL header that signals type 62, nuh_layer_id 0 and
> >> nuh_temporal_id 0.
> >>
> >> forbidden_zero_bit= 0
> >> nal_
On 10/23/2021 2:52 PM, Derek Buitenhuis wrote:
On 10/23/2021 3:18 PM, James Almer wrote:
0x7c01 is just the NAL header that signals type 62, nuh_layer_id 0 and
nuh_temporal_id 0.
forbidden_zero_bit= 0
nal_unit_type = 10
nuh_layer_id = 00
nuh_temporal_id_plus1 =
On 10/23/2021 3:18 PM, James Almer wrote:
> 0x7c01 is just the NAL header that signals type 62, nuh_layer_id 0 and
> nuh_temporal_id 0.
>
> forbidden_zero_bit= 0
> nal_unit_type = 10
> nuh_layer_id = 00
> nuh_temporal_id_plus1 =001
>
> So the last two checks
On 10/21/2021 10:48 AM, Derek Buitenhuis wrote:
Signed-off-by: Derek Buitenhuis
---
* The NAL reordering approach is a result of discussions with Anton and James
a few months ago.
* I've put the NAL reordering in ff_h2645_packet_split, rather than a bitstream
filter for a few reasons:
Signed-off-by: Derek Buitenhuis
---
* The NAL reordering approach is a result of discussions with Anton and James
a few months ago.
* I've put the NAL reordering in ff_h2645_packet_split, rather than a bitstream
filter for a few reasons:
* I don't think having a decoder's behavior rely on
