[Bug 796519] Add AV1 codec parser

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796519

Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #9 from Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> ---
(In reply to Georg Ottinger from comment #7)
> many thanks for your feedback. For most of them I can just go ahead and
> implement the changes.
> 
> I do want to note two things:
> 
> 1.) About CamelCase - I tried to stick two the AV1 Bitstream Spec - and in
> my  understanding its using underscore notation for "direct" read bits from
> the stream and CamelCase if there is some calculation involved.
> 
> -> here the question is what is better: Sticking to the original notation
> from the Spec? Or following the gstreamer standard layout?

My personal preference is to respect coding style, you can introduce a
namespace for your attribute to differentiate the calculated one.

> 
> 2.) About reserving space in the structs. 
> itu_t_t35_payload_bytes[] is not defined in the Spec - thus it is unclear to
> me how many bytes to reserve.
> 
> Quote from the Spec: "Note: The exact syntax of itu_t_t35_payload_bytes is
> not defined in this specification. External specifications can
> define the syntax. From a decoder perspective, it suffices to say that
> decoders should ignore the entire OBU if they don’t understand it. The last
> byte of the valid content of the data is considered to be the last byte that
> is not equal
> to zero. This rule is to prevent the dropping of valid bytes by systems that
> interpret trailing zero bytes as a padding continuation of the trailing bits
> in an OBU. This implies that when any payload data is present for this OBU
> type, at
> least one byte of the payload data (including the trailing bit) shall not be
> equal to 0."
> 
> -> Should I follow the advise and ignore the entire OBU?
> 
> coded_tile_data[] - its size is variable with a maximum of 64KB per tile
> list entry. (and there are max. 512 of tile_list_entries) ... I can't
> allocate this statically.

> 
> -> Maybe I should reserve a pointer for this? (this would also need a API
> function for freeing the space after use)

If the spec does not specify a maximum, dynamic allocation is required, and
then a free function is required too.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.