Hi, On Thu, Apr 7, 2011 at 2:50 AM, Anton Khirnov <[email protected]> wrote: > On Wed, Apr 06, 2011 at 05:33:32PM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Tue, Mar 29, 2011 at 1:38 PM, Anton Khirnov <[email protected]> wrote: >> > On Tue, Mar 29, 2011 at 10:09:35AM -0700, Ronald S. Bultje wrote: >> >> Hi, >> >> >> >> On Tue, Mar 29, 2011 at 9:55 AM, Anton Khirnov <[email protected]> wrote: >> >> > On Tue, Mar 29, 2011 at 05:59:49AM -0700, Ronald S. Bultje wrote: >> >> >> >> >> >> Not really. Can you confirm (likely requires a little debugging) that >> >> >> either with or without that piece of code, the number of mp2/3 frames >> >> >> written into a Xing or MPEG file is correct? >> >> > >> >> > Number of frames written is the same in both cases, since mp3 isn't >> >> > interleaved and no frames get written in av_write_trailer(). >> >> > In any case, I don't see why the number of frames would be off by one. >> >> > If anything, wouldn't it be off by a huge amount when frame != packet? >> >> > >> >> > Anyways, what we can do is: >> >> > 1) abuse nb_frames field with a note that it will be wrong when packet >> >> > != frame (slightly evil) >> >> > 2) add a nb_packets field (somewhat bloaty) >> >> > 3) have each muxer manage this by itself (evil) >> >> >> >> You're confusing av_write_frame()/interleaved_frame() with >> >> av_write_packet(). They do exactly what you think they do (I hope). >> > >> > There is no av_write_packet() =p >> > >> > AFAIU (and please correct me if I am wrong), there is av_write_frame, >> > which takes an AVPacket and directly writes it to the output file and >> > av_interleaved_write_frame(), which also takes an AVPacket and adds it >> > to queue for proper interleaving. >> >> Blegh. Anyway, can you confirm please that writing a MP3 (either >> stream-copy from whatever source, e.g. MPEG-1 system stream) as well >> as encoded MP3 using lame both writes out the correct number of frames >> in the Xing header? >> > > Encoding with the libmp3lame wrapper adds one frame of silence at the > end, so number of frames written is one higher then with -acodec copy. > Encoding with lame commandline tool adds a frame of silence at the > beginning and a frame of silence at then end, so number of frames > written is two higher than with -acodec copy.
Patch OK then. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
