Time to return the favor to the blogosphere and the mplayer-users mailing list, where most of this information was painstakingly discovered. I’m working on a phase of the new ArtsConnectEd site where we’re trying to automate the importing of all of our various media types into two standard, embeddable formats: mp3 and flv. The source media is in everything from Real Audio and Real Video to different flavors of quicktime (mp4, etc), old mp3 codecs, some avi, and even wav files. We also need to generate thumbnails for all the video, and properly detect the edge cases where we have an audio-only quicktime file that wants to be a video but clearly should actually be an mp3 audio file.
The solution is ffmpeg and mplayer / mencoder, and the amazing thing is it’s almost as easy as just throwing a file at it and telling it what format you want. The developers of these tools have done a truly amazing job.
Things get much trickier when you introduce Real Media into the mix. An unfortunate number of our Channel videos are in this format, so it’s something we have to solve. After many attempts and failed encodings - including one hair-pulling episode where it turned out the audio was actually out of sync in the original file and not in the transformed version - I believe I have a “good enough for now” command line formula for converting Real Media to flv. (ffmpeg actually can’t handle .rm files, so this is all done in mencoder)
mencoder realmediafile.rm -ni -o flvoutput.flv -oac mp3lame -lameopts abr:br=56 -srate 22050 -ovc lavc -lavcopts vcodec=flv:vbitrate=300:mbd=2:mv0:trell:v4mv:cbp:last_pred=3 -fps 30.000 -ofps 24 -mc 1 -of lavf -lavfopts i_certify_that_my_video_stream_does_not_use_b_frames
Some of that is over my head and I just copied it (last_pred=3??) but the real key for this process seems to be knowing and accurately setting the input stream’s framerate using -fps xx.xx. Without that, the real demuxer will sometimes guess wrong and get out of sync, resulting in an unpleasant hung process as it comes across the next data chunk. I only noticed this happening with RV40 on multirate files, RV30 seemed solid. You can pull the info about the stream, including framerate and original dimensions, using mplayer:
mplayer -identify -frames 0 -vc null -vo null -ao null realmediafile.rm
Even cooler, in the cases where the .rm file isn’t local, both of those commands work by feeding them a stream like rtsp://server/realmediafile.rm!
With any luck, someone will find this page and save themselves a day of frustration. Or someone will find this page and notice I’m doing something wrong and correct me!
Using the “harddup” switch makes all the difference with audio/video sync problems going from rm to flv. I was having similar problems until I tried this:
mencoder big.rm -o big.flv -oac mp3lame -lameopts abr:br=56 -srate 22050 -ovc lavc -lavcopts vcodec=flv:vbitrate=128:mbd=2:mv0:trell:v4mv:cbp:last_pred=3 -ofps 24 -mc 1 -of lavf -vf harddup
In your particular example you mention it’s necessary to specify the frame rate of the incoming video and encode it with that same info (i.e., -fps 30.000), however, I don’t think that’s the real problem (notice I am NOT using it above). Plus, this is not going to work in a production environment where users could be uploading any kind of file they want. The command line above still syncs beautifully even without specifying the fps in. Using -ofps is fine.
Btw, here’s a link the descibes all the switches in detail for mencoder: http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html
You asked what last_pred=3 means, and it says last_pred= is the amount of motion predictors from the previous frame. So there you go. Also, the “i_certify_that_my_video_stream_does_not_use_b_frames” no longer works (at least not for me with the latest version).
I have spent many hours myself researchin rm to flv issues, so I hope this helps you and anybody else with similar issues. I have not tested it extensively, but so far so good.
Comment by David — June 30, 2008 @ 7:47 pm
David - Thanks for the tips! I just ran some tests with harddup, and it seems to help a bit with the sync, but I’ve still got a few files that are giving me trouble. They’re somehow encoded with the audio starting approximately 5 seconds before the video, and they play back ok in RealPlayer on Windows, but mencoder just can’t make them sync. I can do it if I manually tweak the delay, but it’s not consistent across files so that’s a huge pain… If you have time to play, one file I’m messing with is at:
rtsp://ice.walkerart.org:8080/translocations/media/Jamie.rm
… or grab a copy for local use here: http://newmedia.walkerart.org/Jamie.rm
Thanks for the help!
Comment by Nate Solas — June 30, 2008 @ 8:54 pm
Nate, I played with that file, but I’m afraid since there is a sync problem in the source there is probably no way to fully correct it when encoding. That said, IMHO I don’t think the 5 second delay is that big a deal. If you have any RM files that are flawless, but coming out bad when converted, I am happy to look at those.
Comment by David — July 1, 2008 @ 7:32 am
@David - Thankfully the RM files that are in good shape to begin with are also converting cleanly, and the harddup switch seems to clear up the framerate issues I was having.
For the delayed video files, since it’s a finite number and we now produce them properly, I think I’m going to try to have someone go through and log the filename and the shift time so I can just put some special cases in my script to deal with them. It’s pretty strange - mencoder does a ton of churning up front, duplicating frames trying to bring the a/v into sync, and it gets really close… just never quite there.
Thanks again for your input and for taking the time to test!
Comment by Nate Solas — July 1, 2008 @ 8:32 am
when i need to convert audio files to some formats,like mp3,mps.wav,avi etc,i use a software called Axara Audio Converter http://www.sharewarecheap.com/Audio-Converters-category_Update_16_1.html,it can convert audio files between Mp3, Mp4, WMA, M4A,WAV, rm, etc.works great!
Comment by sharewarecheap — July 3, 2008 @ 1:33 am