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!