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. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
