[FFmpeg-devel] [PATCH 1/3] mpegvideo_parser: implement parsing of the picture structure field
michael at niedermayer.cc
Tue Feb 13 20:55:33 EET 2018
On Tue, Feb 13, 2018 at 08:39:09PM +0200, Jan Ekström wrote:
> On Tue, Feb 13, 2018 at 2:13 PM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > ...
> > 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 ...)
> OK, so they are inseparable? Then it makes sense to pass them
> together. Until now I only had the information that the two pictures
> were in the same PES packet.
> In that case the best thing we can do is set the field order correctly
> for the set by parsing both field pictures' information. I just
> wondered if the two field pictures are separately coded pictures, just
> like with PAFF in AVC or how interlacing is generally done with HEVC
> (which we even decode as separate fields right now).
> Thus, I was just trying to query if the two field pictures were indeed
> two separate images, and thus could be properly tagged and passed
> through, without the latter picture apparently getting ignored. For
> that at this point of time no new APIs would be needed, only work with
> the parser.
interlaced video can be stored in more than one way, either in a inseperable
way or seperable field pictures.
Abother inseparable case is for example H263 PB frames, coding 2 frames
For all these cases parsers should idealy be able to output information
> > 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
> Yes, although I think the feed/receive APIs make it work both ways
> (you can feed more or receive more).
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel