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.
Looks like someone is encoding with -qp 51 ;)
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.
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).
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.
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.
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.
10Mbit/s isn’t much when ffmpeg tells libx264 that the video is 90000fps
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.
Pingback: Kostya’s Wild Codec World » A bit on Interplay MVE 16-bit