[Bug 796519] Add AV1 codec parser

[GStreamer (GNOME Bugzilla)]

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

--- Comment #13 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Georg Ottinger from comment #10)
> (In reply to sreerenj from comment #5)
> > All of the other codecparser APIs(h264, vp9 etc) accept a pointer to
> > data(which needs to be parsed) as the input argument of APIs, why av1parser
> > designed to accept BitReader instead of raw data?
> > This is asking the user to deal with BitReader in order to invoke the
> > parsing APIs which is not an ideal way IMHO.
> 
> When coding the test case for me it seemed the more straight forward way to
> use Bitreader as an argument - cause I am dealing here with a Stream of
> different OBUs with variable sizes. The VP9 codecparser exposes one parsing
> function (frame_header), AV1 has to deal with a number of differen OBUs
> (frame, frame_header, tile_group, sequence, metadata, tile_list). BitReader
> comes in handy, cause it is taking care about the bit-position accounting.
> If I change the interface to "const guint *data, gsize size" - I will loose
> the information how many bits/bytes were actually processed and handle this
> one layer above. 
> 
> That said I have no objections to change the interface as suggested.

Please Correct me if I'm wrong,
IIUC AV1 is it always packetized (one full frame in a buffer with all necessary
OBUs in it). right? If so, why can't we do it similar to vp9? Only one API
which accepts the input raw data and parse+fill all the necessary structures
(sequece, frame etc) if the corresponding obus are present?

Or do you think it is possible to have the container formats to send only OBUs
to the decoder instead of the whole frame (similar to H264 and HEVC)?

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