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