Interplay Conversion Again
September 17th, 2008 by 
Multimedia Mike
I haven’t forgotten about that goal of converting Interplay MVE files to a more modern format. In fact, I have been periodically updating my FFmpeg and libx264 snapshots in order to take another stab at the problem. The crashing issue I experienced before turned out to be a known FFmpeg-x264 interaction issue that was being actively discussed on the ffmpeg-devel mailing list at the time I was experiencing the problem. Robert’s guides helped, too, at least in the not-crashing department.
But… I don’t know… sometimes I can’t shake the feeling that x264 is an elaborate hoax perpetrated by a number of my open source multimedia colleagues.
I think the foregoing movie was generated using the default FFmpeg preset, but I got similarly awful results for all the profiles. I guess libx264 is working, and achieving miraculous compression rates to boot. Maybe a little too much for my goals, though. The resulting files decode better in Apple’s QuickTime Player than they do with FFmpeg’s decoder– makes me wonder what those 119 H.264 decoder tests in the FATE suite are even useful for.
Posted in Open Source Multimedia | 
9 Comments »
September 17th, 2008 at 11:11 pm
Looks like someone is encoding with -qp 51 ;)
September 18th, 2008 at 12:48 pm
Yeah, it looks like FFmpeg and libx264 together are blathering something about qp=51? Default value, perhaps? Seems like the preset file should take that into account. Or is it even possible to specify qp to x264 via FFmpeg? I tried -qp 1 and -qp 100 and libx264 still vomited the same putrid encoding.
September 18th, 2008 at 1:07 pm
Still looks like massive progress, from the sidelines here :D
If X264 eventually works in FFMpeg, all the better, since I can likely work with that much better then the horrible things I’ve had to do in the past (with or without a GUI).
September 18th, 2008 at 1:12 pm
I guess what I’m wondering about here is the baseline: Is libx264 supposed to work in the first place? My expectations might be too high to begin with.
September 19th, 2008 at 7:19 am
libx264 works fine. It’s more a case of you’renotdoingitright. :) What command lines are you using? Put the new ffpresets in ~/.ffmpeg/ and then try something like:
ffmpeg -i infile -acodec libfaac -ab 128k -vcodec libx264 -vpre hq -b 500k -bt 500k -threads 0 outfile.mp4
Or you can try swapping -b -bt with -crf 24 or somewhere between ~20 and 30. Or -cqp, as you please. There’s no real hocus pocus needed, but if you’re observing consistently bad quality then you’re probably doing it wrong.
September 19th, 2008 at 10:40 am
I’m working with the baldursgame-*.mve files available from http://samples.mplayerhq.hu/game-formats/interplay-mve/ if you would like to try your luck. My typical command line looks like:
ffmpeg -i baldurgate-logo.mve -vcodec libx264 -vpre hq -b 1M -bt 1M -an out.mp4
That’s giving me the consistently cruddy quality. I’m only focusing on the video for this phase so I’m ignoring audio with -an. -threads parameter doesn’t work. I think that’s because I didn’t compile libx264 with thread support.
I even cranked up -b and -bt to 10M each but it doesn’t have any effect.
September 23rd, 2008 at 8:25 am
10Mbit/s isn’t much when ffmpeg tells libx264 that the video is 90000fps
September 23rd, 2008 at 4:43 pm
Yeah, I’ve been starting to suspect that the Interplay MVE demuxer might be telling FFmpeg something bad. Obviously, x264 must be working for someone.
April 29th, 2009 at 1:14 am
[…] those, who are interested in playing 16-bit MVE files (yes, Mike, I am talking about you) here are some bits of information I’ve gathered at my […]