Quoting Mark Thompson (2016-03-28 14:48:22) > On 28/03/16 08:15, Anton Khirnov wrote: > > Quoting Mark Thompson (2016-03-27 17:26:43) > >> On 27/03/16 13:26, Anton Khirnov wrote: > >>> For video, frame_number tracks the number of frames sent to the encoder. > >>> So it should be incremented when we submit a frame, not when we get a > >>> packet back. > >>> --- > >>> avconv.c | 13 +++++++------ > >>> 1 file changed, 7 insertions(+), 6 deletions(-) > >> > >> Code change LGTM (tested and fixes the problem). > >> > >>> + /* > >>> + * For video, number of frames in == number of packets out. > >>> + * But there may be reordering, so we can't throw away frames on > >>> encoder > >>> + * flush, we need to limit them here, before they go into encoder. > >>> + */ > >> > >> But this comment seems rather unhelpful now. > > > > Why? It is still as valid as it was before. > > I was questioning the first line. Correct me if I'm wrong, but I thought the > new encode API discards the constraint that number of frames in == number of > packets out? > > If not, then that should probably be documented more carefully. The only > relevant comment in avcodec.h: > > * ... ... For each > * input frame/packet, the codec will typically return 1 output > frame/packet, > * but it can also be 0 or more than 1. > > kindof says that they are disconnected, except it doesn't explicitly exclude > that the totals are actually always equal.
Right, the first line won't necessarily be true with the new API. But we still have to assume it holds true for video in this code, otherwise -frames cannot work (except perhaps by looking at timestamps somehow). I'll reword the comment to be more accurate. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
