RE: The mp3 radio downloads that use MPlayer.
From: batguano...@hotmail.com Will FFmpeg not demux them properly, or will the demuxed files not play on some players I mean mux, not demux, doh ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: The mp3 radio downloads that use MPlayer.
On Wed Jul 17 19:39:04 BST 2013, bat guano wrote: Is it necessary for get_iplayer to use MPlayer instead of FFmpeg for muxing the mp3 downloads? Will FFmpeg not demux them properly, or will the demuxed files not play on some players? Or is there some other reason? Hello bat! I have recently referred to this in my post here: http://lists.infradead.org/pipermail/get_iplayer/2013-July/004448.html Quote: Then MPlayer is used to demux the raw MP3 stream from the FLV file... (FFmpeg is also capable of demuxing this, but as I recall from posts many months ago, some issues arise in some Open Source OSes during this process... With the abolition of the RealAudio streams - it is very hard to find one, even in Radio Archive Pages - and the impracticallity of dumping WMA streams in real-time, Mplayer is now almost exclusively used for demuxing those MP3 streams from the flashaudio radiomode; perhaps it is now time to review those issues, that is if they persist even with the latest FFmpeg packages, so as to do away completely with MPlayer in the next GiP update...) A very quick search of the archive produced this result: http://www.mail-archive.com/get_iplayer@lists.infradead.org/msg00439.html and I do recollect dinkypumpkin mentioning some reasons back then why MPlayer is still being used, but it was long ago and the issue (if indeed it is one) hasn't resurfaced - until now, that is... Cheers Vangelis. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: The mp3 radio downloads that use MPlayer.
...mentioning some reasons back then why MPlayer is still being used... Hi I've just tried using FFmpeg instead of MPlayer... Downloaded an mp3 flv file:- get_iplayer --type=radio --pid=b036jqq9 --raw --force Tried to mux it with FFmpeg:- ffmpeg -i Another_Country_with_Ricky_Ross_-_Lord_Huron_b036jqq9_default.flv -c copy output.mp3 Gives errors:- Application provided invalid, non monotonically increasing dts to muxer in stream 0 Maybe this is the reason that MPlayer is used instead... Or maybe a different/more sophisticated command is needed for FFmpeg to mux the mp3 from BBC's flv files. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: The mp3 radio downloads that use MPlayer.
On 17/07/2013 20:19, bat guano wrote: Gives errors:- Application provided invalid, non monotonically increasing dts to muxer in stream 0 What version of ffmpeg are you using? ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: The mp3 radio downloads that use MPlayer.
On 17/07/2013 19:39, bat guano wrote: Hi I don't have any problems with MPlayer but... Is it necessary for get_iplayer to use MPlayer instead of FFmpeg for muxing the mp3 downloads? Will FFmpeg not demux them properly, or will the demuxed files not play on some players? Or is there some other reason? Older versions of ffmpeg either croak on the overlapping timestamps often encountered in the FLV file or spew a stream of scary-looking error messages when re-muxing. Even though ffmpeg's mp3 muxer was eventually changed to deal with that situation, the libav fork didn't those changes, so all Debian derivatives were affected. The ffmpeg patch was a bit over a year ago, and I haven't looked at it since then. I know that libav created a new release branch since then, but I don't know if it received those changes. If you have more recent information, chime in. It would be nice to get rid of a dependency, but get_iplayer still uses mplayer for WMA downloads. Until we can reliably offload those tasks to ffmpeg, we'll need to keep mplayer around. Also, before making that change, we would need to establish a matrix of distros we intend to support and test the packaged ffmpeg for all of them. I'm not sure what criteria would be appropriate for that. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: The mp3 radio downloads that use MPlayer.
(My mail client - Vista's Windows Mail - is misbehaving today...) On Wed Jul 17 20:21:55 BST 2013, dinkypumpkin wrote: Older versions of ffmpeg either croak on the overlapping timestamps often encountered in the FLV file or spew a stream of scary-looking error messages when re-muxing. Even though ffmpeg's mp3 muxer was eventually changed to deal with that situation, I guess this is the stream of errors I witnessed during my test... It would be nice to get rid of a dependency, but get_iplayer still uses mplayer for WMA downloads. Until we can reliably offload those tasks to ffmpeg, we'll need to keep mplayer around. As discussed last January here: http://lists.infradead.org/pipermail/get_iplayer/2013-January/003764.html in my own tests I have found out that 1.x builds of FFmpeg are a very reliable means of downloading wma streams (albeit in realtime, like MPlayer...) V. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: The mp3 radio downloads that use MPlayer.
I downloaded a shorter audio file: in the end a perfectly playable mp3 file was produced Still gives errors for me:- Application provided invalid, non monotonically increasing dts to muxer in stream 0 get_iplayer --type=radio --pid=b036jrr2 --raw --force ffmpeg -i Morning_Briefing_-_17_07_2013_b036jrr2_default.flv -f mp3 -vn -c:a copy foo.mp3 ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: The mp3 radio downloads that use MPlayer.
On 17/07/2013 21:34, bat guano wrote: Still gives errors for me:- Application provided invalid, non monotonically increasing dts to muxer in stream 0 get_iplayer --type=radio --pid=b036jrr2 --raw --force ffmpeg -i Morning_Briefing_-_17_07_2013_b036jrr2_default.flv -f mp3 -vn -c:a copy foo.mp3 Your code should be new enough, but you'd have to hunt around in your repo history to make sure the relevant changes were actually there. What, if any, is the version of ffmpeg packaged for your system? ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: The mp3 radio downloads that use MPlayer.
What, if any, is the version of ffmpeg packaged for your system? No idea. Ubuntu 11.04 is no longer supported. But although I see the red errors:- Application provided invalid, non monotonically increasing dts to muxer in stream 0 The file does mux OK as with Vangelis. The resulting mp3 file seems OK. So maybe it is just a matter of switching off or reducing the loglevel like you said. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: The mp3 radio downloads that use MPlayer.
On 17/07/2013 21:58, bat guano wrote: But although I see the red errors:- Application provided invalid, non monotonically increasing dts to muxer in stream 0 The file does mux OK as with Vangelis. The resulting mp3 file seems OK. So maybe it is just a matter of switching off or reducing the loglevel like you said. That's the thing - your're getting something different than Vangelis and I are seeing with ffmpeg 1.2, and I'm not sure why, given your code is pretty new. To suppress your messages would require -loglevel fatal, but I'm not sure suppressing other error messages is a good idea. Vangelis and I get a different set of messages at warning level, so they can be suppressed with -loglevel error, which seems a bit safer. IIRC, that was the gist of the changes last year - convert those error messages to warnings and ignoring any clipping. I don't have my ffmpeg repo to hand, so I'll have check that. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: The mp3 radio downloads that use MPlayer.
... I'm not sure why, given your code is pretty new... Hi I've just compiled FFmpeg again from git. Still have the red errors. See attachment. Maybe this can be fixed by posting the problem on the FFmpeg-users mailing list. But I think it's safest for get_iplayer to carry on using MPlayer to mux the mp3 files. @ubuntu:~$ ffmpeg -i Morning_Briefing_-_17_07_2013_b036jrr2_default.flv -c copy output.mp3 ffmpeg version git-2013-07-18-1816f55 Copyright (c) 2000-2013 the FFmpeg developers built on Jul 18 2013 03:35:49 with gcc 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) configuration: --enable-gpl --enable-libaacplus --enable-libfaac --enable-libfdk-aac --enable-libilbc --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-librtmp --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-nonfree --enable-version3 --enable-x11grab libavutil 52. 40.100 / 52. 40.100 libavcodec 55. 18.102 / 55. 18.102 libavformat55. 12.102 / 55. 12.102 libavdevice55. 3.100 / 55. 3.100 libavfilter 3. 81.101 / 3. 81.101 libswscale 2. 4.100 / 2. 4.100 libswresample 0. 17.102 / 0. 17.102 libpostproc52. 3.100 / 52. 3.100 Input #0, flv, from 'Morning_Briefing_-_17_07_2013_b036jrr2_default.flv': Duration: 00:30:25.80, start: 0.00, bitrate: 129 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s Output #0, mp3, to 'output.mp3': Metadata: TSSE: Lavf55.12.102 Stream #0:0: Audio: mp3, 44100 Hz, stereo, 128 kb/s Stream mapping: Stream #0:0 - #0:0 (copy) Press [q] to stop, [?] for help [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 7053 = 7020 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1482422 = 1482390 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 2957794 = 2957760 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4433163 = 4433130 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 5908622 = 5908590 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 7383994 = 7383960 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8859363 = 8859330 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 10334822 = 10334790 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 11810194 = 11810160 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 13285563 = 13285530 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 14761022 = 14760990 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 16236394 = 16236360 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 17711763 = 17711730 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 19187222 = 19187190 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 20662594 = 20662560 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 22137963 = 22137930 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 23613422 = 23613390 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 25088794 = 25088760 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 26564163 = 26564130 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28039533 = 28039500 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 29514994 = 29514960 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 30990363 = 30990330 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 32465733 = 32465700 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 33941194 = 33941160 [mp3 @ 0x9d47f20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 35416563 = 35416530 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 36891933 = 36891900 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 38367394 = 38367360 [mp3 @ 0x9d47f20] Application provided
