Alternative to Handbrake for x264 video encoding?

[thefinalprophecy]

What do people use to encode videos into x264 besides Handbrake? I want my videos to show as using Constant Framerate when I check them with MediaInfo. For whatever reason Handbrake will use VFR even if you select CFR on the video tab, and even if you select 23.976 or "same as source". It's been a reported problem that uses have with Handbrake for quite some time so now I'm looking for an alternative.

When I run Mediainfo on 99% of the downloaded mkv/mp4 files I have, almost all of them say "writing application: mkvmerge" but as I understand it mkvmerge is basically just a multiplexing application that puts your source material into whichever container you choose. How can I make these "professional" rips without handbrake?

Thanks,

[Baldrick]

Tried vidcoder? It's based on handbrake so you might get similar problems though...

Or else try megui or staxrip.

[ozok]

It might be that mediainfo is reporting wrongly CFR as VFR, I've seen this happen.

[thefinalprophecy]

I tried Vidcoder and it produced the same result. I have megui but couldn't figure out how to get dual audio tracks but that's just learning how to use the software on my part. I need to get on that since Handbrake isn't cutting it for me.

I did hear that Mediainfo may be wrongly reporting CFR vs VFR but the thing is that it seemingly only "reports wrong" on videos encoded with Handbrake. Either the Mediainfo guys or the Handbrake guys need to fix this. From Google searches though it seems like it has been around for years with nobody intending to change anything.

[Kerry56]

I get constant framerate out of Handbrake when I select it (according to MediaInfo). I'm using a preset I made with Constant Framerate activated however, not one of the presets that come with the program.

[thefinalprophecy]

I get constant framerate out of Handbrake when I select it (according to MediaInfo). I'm using a preset I made with Constant Framerate activated however, not one of the presets that come with the program.

Hmm I wonder what it is about your preset that's doing it. I started with High Profile preset but customized to have CFR instead of VFR.

[deadmeow]

Handbrake is my 2nd favorite. I suggest Xvid4psp, which is my favorite. Never any problems with h264-mkvs from this program, unlike handbrake.

[Meritocracy]

If you want to be sure to obtain a CFR encode, do not use 'Same as source' for the framerate. Some presets also default to VFR.

Specifying a preset and a fixed framerate then selecting CFR always produces CFR based output in my experience. Selecting CFR and then further fiddling with the presets and/or framerate can reactivate VFR.

Saving your own customized presets will also help to alleviate said issue.

[thefinalprophecy]

If you want to be sure to obtain a CFR encode, do not use 'Same as source' for the framerate. Some presets also default to VFR.

Specifying a preset and a fixed framerate then selecting CFR always produces CFR based output in my experience. Selecting CFR and then fiddling with the presets and/or framerate can reactivate VFR.

Saving your own customized presets will also help to alleviate said issue.

I tried selecting 23.796 instead of "same as source" but came up with the same thing. And I have been saving my own presets based on different tests I have run. I am running an encode right now--will check for results.

If anybody wants to export and upload their favorite presets that would be good. I'm ripping my Battlestar Galactica bluray box set to mp4 (CQ 20 720p video, 2.0 and 5.1 audio tracks, chapters, mp4 container) that should yield pretty high compatibility between the various devices out there. I usually get file sizes from 1.5 GB to 2.1 GB per episode which is a pretty good balance in quality/file size for me. I am definitely open to suggestions.

Thanks for everyone's replies.

[Kerry56]

I've never had an issue with not getting CFR, even though I normally select framrate same as source. My settings are not at all esoteric. I started with the High Profile preset, changed to mkv output, Constant Framerate, CQ 19, and under the Optimise Video area I have it set to Slow speed preset for x264, High profile, 4.1 level, and have ref=4 in Extra Options.

Audio settings depend on input. Normally convert to AC3, or let existing AC3 passthrough.

Picture tab settings depend on input also.

[thefinalprophecy]

Yeah that's basically the same that I have too. I'm not new to video encoding (registered here in 2004 apparently!) but I can not figure this Handbrake framerate issue out! And the people on the Handbrake forums are basically telling me "it doesn't matter, it plays no matter what" lol. Call it OCD, but it matters to me!

[Kerry56]

Try these exact settings and do a small test encode by choosing one of the Preview selections.

[thefinalprophecy]

Ok trying that now. The only thing different really is the ref=4. What does that flag signify anyway, something about reference frames?

[Kerry56]

Yes. If you don't add it with this configuration, it will output with 5 references frames. Not a big deal, but 1080p video is supposed to have a limit of 4 reference frames at Level 4.1. 720p can have a lot more.

I use Handbrake for both those resolutions. But this is just a starting point for some encodes. I have to tweak it sometimes.

[thefinalprophecy]

Didn't work--same results. Maybe I am ripping my blurays wrong? I have been using MakeMKV to rip my blurays to my hard drive, but when I run MediaInfo on those files it shows the correct CFR.

[Kerry56]

That's weird. Shouldn't get different results using the same program with the same settings. Here is a test clip using those settings:

Avatar MediaInfo file.txt

[hello_hello]

Have a look in Handbrake's log file after running one of those encodes which result in VFR. Any mention of frames which weren't decoded, or repeated, or dropped, or anything similar?

I don't use Handbrake much myself, so I'm taking a guess, but maybe if there's a problem along those lines and the output video includes repeated frames because the input video does (a frame with twice the usual duration, as opposed to two identical frames in a row), Handbrake outputs it as VFR regardless of the setting. The output video could in fact effectively be CFR, but within the CFR video there's a few repeated frames which make it VFR.... depending on how you look at it. Or maybe if for some reason a frame can't be decoded, Handbrake changes the duration of the proceeding frame to compensate.... that sort of thing. If that's what it's doing... well it's probably a good thing and at least it's telling you in a round about way.

I can't at the moment, but I have Handbrake installed and I'm pretty sure I can easily find a source video with repeated frames.... some old (apparently CFR) TV captures which gave me grief when trying to re-encode them with MeGUI until I worked out what was happening.... so later on I'll try re-encoding one with Handbrake to see if I'm on the right track. Until then, it's at least a possible explanation....

PS One way to check the source video might be to open it with MKVMergeGUI, add the audio (if it was extracted as a separate file) and resave it as a new MKV without specifying a frame rate. The video/audio sync for the new MKV should be fine. Then repeat the process but this time specify the frame rate (whatever the original frame rate might be). This time the output MKV should definitely be CFR. If the original video was VFR in places, or if there is (enough) repeated frames, the output MKV will likely have video/audio sync issues.

[thefinalprophecy]

That's weird. Shouldn't get different results using the same program with the same settings. Here is a test clip using those settings:


[Attachment 19465 - Click to enlarge]

I agree, very weird! Feel free to try it out for yourself using my same videos. I cropped a 1 minute segment from my source MKV using Boilsoft Video Splitter to do a direct split--no reencode. The second file is after converting in Handbrake using the High Profile preset, changing resolution to be 1280x720 and changing VFR to CFR (Same as source). Nothing else has been changed and this is a vanilla Handbrake install. See if you come up with the same results.


https://dl.dropboxusercontent.com/u/23922163/Battlestar_Galactica_Season_2_%28Disc_4%2...00s%29-002.mkv

https://dl.dropboxusercontent.com/u/23922163/Battlestar_Galactica_Season_2_%28Disc_4%2...ighprofile.mp4

[thefinalprophecy]

PS One way to check the source video might be to open it with MKVMergeGUI, add the audio and resave it as a new MKV without specifying a frame rate. The video/audio sync for the new MKV should be fine. Then repeat the process but this time specify the frame rate (whatever the original frame rate might be). This time the output MKV should definitely be CFR. If the original video was VFR in places, or if there is (enough) repeated frames, the output MKV will likely have video/audio sync issues.

I'll try that with MKVMergeGUI when I get home but last time I tried that I was getting the av out of sync.

[Kerry56]

Ok, I downloaded the source mkv and ran it through my settings in Handbrake. I still get CFR output. I didn't try resizing, but I can do that if needed.

Here are the files from the log in Handbrake and the inspection of the output with MediaInfo:

[jagabo]

Handbrake has a habit of spontaneously switching to VFR mode as you work your way through the tabs. I haven't figured out exactly when it happens. Always make sure CFR is set just before you start rendering.

[hello_hello]

All I can suggest (given my theory seems to have gone out the window) is going through the log file after an encode, specifically the log file under the "Encode Log" tab. It's very detailed and the chances are if you go through it carefully enough you'll find something which tells you exactly what's going on.

I found a video which is reported to be CFR by MediaInfo (25fps) and opened it with MeGUI, which showed the total number of frames as being 36317. I then told ffmsindex to convert it to 25fps. The duration in MeGUI's preview stayed the same but the frame count increased to 36355.

I ran the same video through Handbrake twice. Once using "same as source" for the framerate, the second time using 25fps, both times selecting CFR. Each time the Handbrake output totalled 36355 frames. The log file (Encode Log tab) even specified how many frames it expected to find, how many it did find, and how many it had to duplicate to output a CFR of 25fps.

[hello_hello]

I'll try that with MKVMergeGUI when I get home but last time I tried that I was getting the av out of sync.

If you just open an existing MKV and remux it as a new MKV nothing should change. If you specify a frame rate though it will, if the original video isn't really CFR, and that'll probably cause audio sync issues.

[thefinalprophecy]

I'll try that with MKVMergeGUI when I get home but last time I tried that I was getting the av out of sync.

If you just open an existing MKV and remux it as a new MKV nothing should change. If you specify a frame rate though it will, if the original video isn't really CFR, and that'll probably cause audio sync issues.

Yeah nothing changed. It came out basically the exact same, and running it through Handbrake still turned up VFR.

[thefinalprophecy]

All I can suggest (given my theory seems to have gone out the window) is going through the log file after an encode, specifically the log file under the "Encode Log" tab. It's very detailed and the chances are if you go through it carefully enough you'll find something which tells you exactly what's going on.

I found a video which is reported to be CFR by MediaInfo (25fps) and opened it with MeGUI, which showed the total number of frames as being 36317. I then told ffmsindex to convert it to 25fps. The duration in MeGUI's preview stayed the same but the frame count increased to 36355.

I ran the same video through Handbrake twice. Once using "same as source" for the framerate, the second time using 25fps, both times selecting CFR. Each time the Handbrake output totalled 36355 frames. The log file (Encode Log tab) even specified how many frames it expected to find, how many it did find, and how many it had to duplicate to output a CFR of 25fps.

Just endoded that same 1 minute test clip to High Profile + CFR + 1280x720 resolution. This is my output file and the logs from Handbrake. If you or someone could look at my logs and tell me why I'm getting VFR instead of CFR on my output clip it would be very helpful!

[hello_hello]

The log file seems to be pretty definite it's outputting CFR. The only thing I can see which might offer a clue is this:

[10:27:28] sync: got 1432 frames, 1434 expected
[10:27:28] decomb: deinterlaced 0 | blended 0 | unfiltered 1431 | total 1431
[10:27:28] render: 1431 frames output, 0 dropped and 0 duped for CFR/PFR

I'll go out on a limb and guess PFR means progressive frame rate, but I don't know for sure.
Anyway.... the question would be what happened to the missing frames? The log file says it expected 1434, got 1432 and encoded 1431.
When I tested myself with my video the log file showed Handbrake duplicated around 19 frames to output CFR.

I'll have to mess around with it again a bit later, but at the moment I'm leaning towards it being a Handbrake and/or MP4 oddness in respect to the handling of audio delay. Your sample has an audio delay relative to the video of 83ms, which is pretty much the duration of two frames at 23.976 fps. Or maybe MediaInfo is getting it wrong.
When I remux the MP4 as an MKV with MKVMergeGUI without specifying a frame rate, MediaInfo no longer reports an audio delay relative to the video and it also reports a constant frame rate. It appears so far the log file is at least correct, the output video contains 1431 frames.

Maybe try again without the audio, or using MKV instead of MP4 to see what happens. I'll experiment a bit more later on today, unless someone else more clever comes along first.

[jagabo]

It's very common for codecs to miss a few frames when decoding. Things like open GOPs, b frames before the first I frame, etc. cause a few frames at the start and/or end to be missed. I wouldn't worry about that at all.

I don't use handbrake much but I always get CFR encodes when I specify CFR (checked with MediaInfo). Like I said earlier, just before starting the encode I check the CFR setting since the program occasionally switches back to VFR for some reason.

[hello_hello]

It's still have a feeling it's something to do with the first couple of frames, but I've no idea what. I discovered, when playing the original MP4 and the remuxed MKV with MPC-HC, and while using ffdshow's on screen display to have a look-see, the original MP4 sample actually starts playing at frame number 2, according to ffdshow, and as that's frame zero for the remxued MKV, they're two frames apart from start to finish. So maybe it depends on WTF is really going on with those first two frames and how the frame rate is calculated, because according to ffdshow, the rest of it is CFR from start to finish.

Here's how MPC-HC/ffdshow displays the first frame of the MP4 version:



Now after remuxing it as an MKV without specifying a frame rate:



After remuxing it as an MKV while specifying a frame rate (23.976):



What's also a little strange is when I remuxed without specifying a frame rate, the output MKV seemed to inherit a little of the original MP4's "oddness".
ffdshow displays the frame rate as 23.974 instead of 23.976, and it displays a slightly different frame duration accordingly, but.... it's wrong. I'm not sure I've ever seen ffdshow get it wrong like that before, but if I skip to the last frame and look at the timestamp, it's 00:59:683 both times, so the frame rates must be the same. And to confirm that, I extracted the timecodes from each MKV and they were identical.

PS Well it turns out the first frame oddness was being caused by MPC-HC's internal MP4 splitter. When I switched to Haali, the first frame went back to being frame zero instead of frame two, but I still suspect there's something odd going on there. Trying to work out what though.... I might give up.

[jagabo]

Turn on the frame type parameter. I think you'll find the first two frames are b frames.

[hello_hello]

According to ffdshow, the first frame is an I-frame, followed by a whole bunch of P-frames until the first scene change when the next I-frame appears. The first B-frame doesn't make an appearance until around frame number 70.

Same regardless of which splitter is used, only with MPC-HC's internal splitter, the frame count starts at frame two.