On Tue, Nov 22, 2011 at 12:35:20PM +0100, Janne Grunau wrote: > On Tue, Nov 22, 2011 at 12:16:19PM +0100, Anton Khirnov wrote: > > > > On Tue, 22 Nov 2011 12:01:33 +0100, Janne Grunau <[email protected]> > > wrote: > > > On Tue, Nov 22, 2011 at 07:19:55AM +0100, Anton Khirnov wrote: > > > > Also simplify the code so it's the same for video/audio/subs. > > > > --- > > > > avconv.c | 10 ++++------ > > > > 1 files changed, 4 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/avconv.c b/avconv.c > > > > index 3ba8534..b30dad4 100644 > > > > --- a/avconv.c > > > > +++ b/avconv.c > > > > @@ -1738,6 +1738,8 @@ static int transcode_video(InputStream *ist, > > > > AVPacket *pkt, int *got_output, int > > > > decoded_frame, got_output, pkt); > > > > if (ret < 0) > > > > goto fail; > > > > + pkt->data += ret; > > > > + pkt->size -= ret; > > > > > > I think it was assumed that there's only a single frame per packet for > > > video streams. This doesn't harm if it's still the case and it makes > > > sense to assume the same behaviour for all decode functions. > > > > > > > I think the API implies that if only a part of the packet is consumed, > > then the rest should be passed to the next decode call, as is done for > > audio. > > If any decoders don't expect this, then I think it makes more sense to > > fix those decoders. > > I think you misunderstood my remark. I was just saying that no demuxer > produces video packets with more than 1 frame (not sure how packed > b-frames in avi are handled). So this is a situation which will not > occur. Decoders can probably handle it, timestamps might be a problem > but nothing to worry about since this it's safe to assume that it does > not happen.
There is such thing as PB-frames in H.263++ with both P and B-frame bundled together but that beast is extremely rare. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
