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 > <mich...@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.
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list email@example.com http://ffmpeg.org/mailman/listinfo/ffmpeg-devel