[FFmpeg-devel] [PATCH 1/3] mpegvideo_parser: implement parsing of the picture structure field

[Michael Niedermayer]

Hi

On Mon, Feb 12, 2018 at 03:13:46AM +0200, Jan Ekström wrote:
> On Mon, Feb 12, 2018 at 12:23 AM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> >
> > I think a better API is needed to export the picture_structure correctly.
> >
> 
> I might be misunderstanding the problem at hand, but I'm not sure if a
> better API is required right now in the sense that if we define that:

> * the demuxer and/or parser should return a decode'able coding unit

> (whether or not it can actually be decoded depends on the state of
> things). In case of field coded pictures this would be one coded
> field, if I understand correctly.

Whats a "decode'able coding unit" ?
A frame ? a field ? a slice ? an access unit ? a group of pictures ?

Should the user be able to choose at which level the parser should
split packets depening on her needs ?

currently and in the past the parser output was what was most convenient
to use for decoders and muxers internally, that was a "frame" when 
everything can be packetized as frames (no unpaired fields) or fields
when unpaired fields where possibly. In almost all parsers thats
also identical to an access unit.

If there are 2 fields in a packet that can be as 2 field pictures or
as a interlaced frame coded in a way thats inseperable. Then you have
2 timestamps really and might have information associated with each
field in principle. Our API doesnt have a place to put the information
for the 2nd field anywhere. (which is together with picture_structure
what i meant with needing a better API ...)

This exists more so if you would split at GOP level or wanted information
about slices from a parser returning fields.
(if a future API would support this)

spliting at slice level is for example usefull for network transmission
so that transmitted units are more aligned to slices.



> * and, if the decoder then needs two coded field pictures to generate
> a combed together "frame" - so be it. The new decoding/encoding APIs
> let you have a non-synchronized amount of input VS output.

We have several decoders that can be fed with input at lower granularity
like slices since a long time ago. So iam not sure how any "new APIs" are
related here


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180213/44ca820e/attachment.sig>