Most simple Handbrake setting to convert MKV to H264 or Mp4

[hello_hello]

Thanks, I marginally got what you meant by anamorphic and aspect ratio.

Question is, which one would be easier (non taxing) for my pioneer head unit. (Therefore less chances of getting freezes)

I can't imagine it'd make a difference. 711x400 should be slightly easier to decode.

a) set the picture size to 800x480 (pioneer's resolution) and remove anamophic and uncheck the keep aspect ratio

Don't uncheck "keep aspect ratio" unless you really know what you're doing, The whole point of that is for you to pick a width, and Handbrake resizes the height accordingly so as not to distort the picture. Most likely, if you don't let HandBrake keep the aspect ratio and resize to something else manually, you'll be distorting the picture.
When encoding video with square pixels and resizing to square pixels, resolution and aspect ratio are easy enough to work out. For example 1600x900, 1280x720, 960x540, 704x396 are all 16:9. When you crop black bars, the amount of cropping needs to be taken into account when resizing.... generally you'd pick the width you want and Handbrake will do the math for you.

Anamorphic resizing is a little harder to get your head around as the resolution and display aspect ratio aren't the same thing. If it was me I'd not bother with anamorphic encoding, especially at such a low resolution. I'd just pick the width and let Handbrake resize the height to square pixels (anamorphic none). There's a potential for the video not to display correctly which can be eliminated simply by not using it.

b) set the picture size to 720(width) with anamorphic Loose and Modulus 16 (giving me a display aspect resolution of 711x400 then just using the Zoom/stretch/fill command of the pioneer)Question is, which one would be easier (non taxing) for my pioneer head unit. (Therefore less chances of getting freezes)

It'd probably work a treat if every video had the same aspect ratio as the display. But if (for example) the display is 16:9, you can encode 16:9 video that way and stretch it manually to fill the screen and it'll be fine, but what if it's a wide aspect ratio movie, or even if it's 4:3 etc? You can't stretch it to fill the screen without distorting it.

How would I know if my Pioneer head unit supports anamorphic encoding? It does not say in the manual nor in the website.

You could run a "silly encode" to test it. For Handbrake you'd need to use Anamorphic "custom". I just tried a test encode with it, and either it's custom anamorphic option doesn't work correctly, or I'm just too silly to use it, but after a few attempts this worked.
Open a video and switch to custom anamorphic. In my case it was 704x384. Change the Size width to half the original. In my case 352x384. Leave the display width as it was originally (704 in my case). Run an encode. The output video will have a resolution of 352x384 but it should display as it originally did (704x384). If the player supports anamorphic video it'll look normal. If it doesn't it'll look like the width has been squished down to half the size.
(The anamorphic custom option has two PAR settings. I assume that refers to pixel aspect ratio, but changing them seemed to have no effect. The above method with both PAR values left at 1 worked though)

If level 3 only compresses the video a little more then I'm not really interested in it since Its ok if the file size is big.

Then I'd probably stick with the medium x264 speed preset. I doubt you'll see a quality difference (file size might change a little) but medium uses 3 ref frames, slow uses 5 and slower uses 8. What should happen is if the speed preset uses more reference frames than the chosen profile and level, the profile and level should take precedence. The number of reference frames usually decreases as the resolution increases. As far as I know the current version of Handbrake should behave itself in that respect, and it appears to be (it limited you to 7) but try the medium speed preset to see what happens.

Why should I use "same as source" and constant frame rate? What if the source video is 60fps? That will mean that my converted video will also be 60fps and that won't definitely play with my pioneer head unit since it only supports max of 30fps. Right?

Constant frame rate, especially at the moment, eliminates any possibility of variable frame rate causing problems, and "same as source" would probably be the easiest way to get the "correct" frame rate 99.99% of the time. I don't live in NTSC-Land but I've literally never seen a Bluray video with a frame rate higher than 25fps.

Another thought.... you might want to try a "video only" encode to see how it plays. That might eliminate it being an audio issue. If there's no problem without audio then it'd be a matter of working out the type of audio required to keep the player happy.

[hello_hello]

Baseline profile at level 3.0 or 2.2 should use only one reference frame. I don't know why your previous video shows 7 reference frames instead.

I'd be guessing it's related to the x264 speed preset but are you sure about only 1 reference frame? I'm using MeGUI's encoder configuration as a guide, as I've not caught it telling lies yet. It shows three reference frames for the medium speed preset using Baseline profile, regardless of the level. It appears to be doing everything else correctly, such as disabling B frames and setting the appropriate VBV restrictions, so I assumed it's getting the number of reference frames correct too.
According to MeGUI's encoder setup you're not down to one reference frame until you get to the VeryFast preset. Unless that's what you were referring to and I missed it.

That's one of the things I've always disliked about Handbrake. It's never updated it's Advanced tab to show you what the current settings are according to the chosen speed preset. The workaround for that with the current version seems to be to disable the speed presets completely in order to use the advanced tab, but that doesn't seem ideal to me.
And I wish it'd display the whole command line when configuring the encoder, not just the extra bits it adds when changing an advanced option. At least then there'd be no ambiguity regarding the exact command line being used.

I've got Vidcoder installed. It's version 1.4.23 while I think the current version is 1.4.24, but it doesn't seem to lock you out of the x264 speed presets in order to use the advanced tab. It'll only display the correct settings in the advanced tab if you're using the medium speed preset... the logic behind that still alludes me completely... and it doesn't display the full command line either, but at least you can use both a speed preset and some advanced options.

[joms]

Thanks for the reply.

Ok I think I know how i got 7 reference frames based on the previous replies. I think despite setting things to normal preset and assigning level 2.2, i set the speed to slower/slowest. I didn't think it would influence the reference frames. I thought it would just burn things slowly and surely like what you do when burning DVDs (i burn using 2x or 4x only). This is because i encode while sleeping at night so even if i choose slowest speed, everything will still get done when i wake up.

Anyway, I encoded 4 settings:

1) Normal Preset - Baseline - Level3 - RF10 - Stereo downmix
2) Normal Preset - Baseline - Level3 - RF10 - Dolby Digital downmix
3) Normal Preset - Baseline - Level3 - RF18 - Stereo downmix
4) Normal Preset - Baseline - Level3 - RF18 - Dolby Digital downmix

All 4 files have a reference frame of 1 (i checked). mp4 container, H264, size is 711x400 Anamorphic Loose 16

File 1 = still froze from time to time
File 2 = still froze from time to time
File 3 = so far so good, no freezing for 30 mins now
File 4 = not yet tested

It seems the freezing is due to the RF settings.

[hello_hello]

My bad. The penny didn't drop. I assume jagabo was correct about the single reference frame, as you were referring to using HandBrake's "Normal" preset at the time, which by default uses the x264 very fast preset, and I probably hadn't kept up with the conversation.

It seems the freezing is due to the RF settings.

It looks that way so far, but it's no doubt causing the problem indirectly because level 3 allows for higher bitrates than your player can cope with. If you add the reduced VBV settings to the encoder options manually, you can still use RF encoding and level 3, although the fact that RF10 currently increases the bitrate enough to always cause freezing probably serves as an indicator it's seriously overkill. Even RF18 is probably overkill for the resolution you're using if you're only ever going to view the encodes using a small screen.

For the record, if the Dolby Digital mixdown you referred to is Handbrake's Dolby Prologic II mixdown, I can't think of a reason why it'd have an adverse effect on playback. For a player which can't decode Dolby Prologic II, it's just stereo audio.

[jagabo]

Baseline profile at level 3.0 or 2.2 should use only one reference frame. I don't know why your previous video shows 7 reference frames instead.

I'd be guessing it's related to the x264 speed preset but are you sure about only 1 reference frame? I'm using MeGUI's encoder configuration as a guide, as I've not caught it telling lies yet. It shows three reference frames for the medium speed preset using Baseline profile, regardless of the level. It appears to be doing everything else correctly, such as disabling B frames and setting the appropriate VBV restrictions, so I assumed it's getting the number of reference frames correct too.
According to MeGUI's encoder setup you're not down to one reference frame until you get to the VeryFast preset. Unless that's what you were referring to and I missed it.

Yes, you're right. I had forgotten the x264 preset, in combination with the profile and level, determines the max reference frames Baseline@3.0 Medium uses 3 refernce frames. But he said he was using the Normal Handbrake preset which sets x264 to veryfast, Baseline@3.0 Veryfast uses 1 reference frame. But maybe he changed the x264 preset. In the Handbrake image he posted I see that it's set to Slower.

[joms]

I don't know though if the reference frame has anything to do with the freezing that is occurring since as per my test, even at reference frame = 1, i still get freezing as long as the RF is set to 10. It seems the RF is the one that is giving me problems.

As per my previous post:

1) Normal Preset - Baseline - Level3 - RF10 - Stereo downmix
2) Normal Preset - Baseline - Level3 - RF10 - Dolby Digital downmix
3) Normal Preset - Baseline - Level3 - RF18 - Stereo downmix
4) Normal Preset - Baseline - Level3 - RF18 - Dolby Digital downmix

All 4 files have a reference frame of 1 (i checked). mp4 container, H264, size is 711x400 Anamorphic Loose 16

File 1 = still froze from time to time
File 2 = still froze from time to time
File 3 = so far so good, no freezing for 30 mins now
File 4 = not yet tested

[joms]

For your info:

RF 18: (Working so far)


File size : 422 MiB
Duration : 43mn 22s
Overall bit rate mode : Variable
Overall bit rate : 1 361 Kbps

Format profile : Baseline@L3.0
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1

Bit rate mode : Variable
Bit rate : 1 197 Kbps
Width : 720 pixels
Height : 400 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 fps
Minimum frame rate : 23.974 fps
Maximum frame rate : 23.981 fps


----------------------------------------------------------------------------------


RF 10: (Not working - freezes)


Codec ID : mp42
File size : 1.49 GiB
Duration : 43mn 22s
Overall bit rate mode : Variable
Overall bit rate : 4 920 Kbps


Format profile : Baseline@L3.0
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1

Bit rate mode : Variable
Bit rate : 4 757 Kbps
Width : 720 pixels
Height : 400 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 fps
Minimum frame rate : 23.974 fps
Maximum frame rate : 23.981 fps

[jagabo]

Then it looks like bitrate peaks may be your main problem. Typically, a video will have bitrate peaks several times the average bitrate unless otherwise constrained. Nobody would use RF=10 for video they're just going to watch on a small screen. You probably won't notice a difference between x264's veryfast and slow presets either.

Baseline@3.0 will allow peaks as high as 10000 kbps. You may need to manually add "--vbv-bufsize 8000 --vbv-maxrate 8000" to the Extra Options box to prevent peaks over 8000. Baseline@2.2 will limit peaks to 4000 kbps so you could just use that instead. Standard definition material at RF=18 won't often have peaks over 8000 kbps anyway, and not a lot over 4000 even. Visually, the difference you'll see by limiting peaks is a little more blocking or roughness in high action sequences.

You can use Bitrate Viewer to see a graph of a file's bitrate and its peaks. The program actually reads the entire file so its stats are much more reliable than other programs.

<edit>

It looks like Handbrake isn't passing the vbv options to the x264 encoder. You may have to stick to Baseline@2.2.

I figured it out: don't use the leading --, use = signs, and separate arguments with a :. For example:

 vbv-bufsize=8000:vbv-maxrate=8000

Those will get passed along properly to x264.

If you want to use a slower preset you can force max reference frames to 1 (or whatever you need) by adding ref=1 to that:

 vbv-bufsize=8000:vbv-maxrate=8000:ref=1

By the way, you can also use ref=n to increase reference frames above what an x264 preset normally uses.

</edit>

[joms]

Thanks for the reply.

I will test your code. The only thing that is bothering me right now is that, why did I also have freezes last time when I was only using baseline / level 2.2 / RF10 ? If my level is 2.2 then my bitrate shouldn't have gone over 4000kbps right? Thinking along this line, what does increasing RF quality do (from 18 to 10) aside from increasing bitrate? Is there anything else that it increases? The bitrate might not be the problem, it might be something else that increases when I use RF 10.

Update: I used bitrate viewer on my latest files:

Baseline/Level 3/RF 18 - Ave Bitrate (1,197kbps) / Peak (7,283kbps)
Baseline/Level 3/RF 10 - Ave Bitrate (4,757kbps) / Peak (13,671kbps)

I guess it is bitrate that is making my video freeze! I will try encoding using your code now!

[jagabo]

The only thing that is bothering me right now is that, why did I also have freezes last time when I was only using baseline / level 2.2 / RF10 ?

Weren't you using a different x264 preset back then? That would give you more than 1 reference frame.

If my level is 2.2 then my bitrate shouldn't have gone over 4000kbps right?

Yes. Though you should check with Bitrate Viewer.

Thinking along this line, what does increasing RF quality do (from 18 to 10) aside from increasing bitrate? Is there anything else that it increases?

I don't think so. But many things change when you use different x264 presets. Here's a table of many of them:

https://forum.videohelp.com/threads/347067-VirtualDub-H-264-Encoder-Speed?p=2169830&vie...=1#post2169830

[joms]

whoa, i encoded with the same specs but placed your code and after running it in bitrate viewer it gave me this:

ave bitrate (195579kbps) peak (314621kbps)

I will try encoding it again. There must be some mistake





Update: I encoded it again (2nd try), and used also ref=3 and it gave me the same results! average (194707kbps) and peak (315086kbps) bitrate is way high.

Code i used is:

1st try:
vbv-bufsize=8000:vbv-maxrate=8000

2nd try:
vbv-bufsize=8000:vbv-maxrate=8000:ref=3


Update: Theres something very wrong, i encoded again removing the code and it still gave me a high reading in bitrate viewer. Ill try to close / re-open handbrake and encode again.

[jagabo]

Try Constant Frame Rate instead of Variable Frame Rate. I notice the Bitrate Viewer report says 1000 fps. Many players and tools don't work properly with VFR, especially in MP4/M4V.

And stop using RF=10. That's ridiculous for something you're going to watch on a 7" screen.

[theewizard]

there are only ? 3 prime considerations.. together they all boil down to total bitrate and peak bitrate

resolution, FPS, and quality (amount of data per pixel), most of the time .. resolution and and fps don't change (unless you use VFR which is dumb)
res*fps= pixel count per second
quality*bitrate= data needed
too high a quality setting and you exceed the data rate the device can decode and display

its that simple

too low ... its a blocky pixelated jaggey image

Thanks for the reply.

I will test your code. The only thing that is bothering me right now is that, why did I also have freezes last time when I was only using baseline / level 2.2 / RF10 ? If my level is 2.2 then my bitrate shouldn't have gone over 4000kbps right? Thinking along this line, what does increasing RF quality do (from 18 to 10) aside from increasing bitrate? Is there anything else that it increases? The bitrate might not be the problem, it might be something else that increases when I use RF 10.

Update: I used bitrate viewer on my latest files:

Baseline/Level 3/RF 18 - Ave Bitrate (1,197kbps) / Peak (7,283kbps)
Baseline/Level 3/RF 10 - Ave Bitrate (4,757kbps) / Peak (13,671kbps)

I guess it is bitrate that is making my video freeze! I will try encoding using your code now!

[joms]

I only used RF10 to see if the code you gave me is working because RF10 goes beyond the 8000kbps and the code will restrict it from going over 8000kbps.

I am now trying Constant framerate without the code first to check if i will get a bitrate over 8000kbps

[jagabo]

Oh, I just remembered that Handbrake doesn't always produce CFR MP4 files when specified. If your player can handle MKV you might want to use that instead.

[joms]

Nope, my player can't handle MKV. Only mp4 container and mp4 or H264 codec.


Ok, it seems the code didn't work. It lowered the peak rate but not below 8000kbps. (note: I used RF10 since it gives a peak bit rate of above 8000kbps)

Code used = vbv-bufsize=8000:vbv-maxrate=8000

RF10/Constant Framerate (same as source)/Baseline/Level 3.0/Without Code = average(4758kbps) / Peak (13783kbps)
RF10/Constant Framerate (same as source)/Baseline/Level 3.0/With Code = average(4691kbps) / Peak (11181kbps)

[joms]

Ok, it seems the code didn't work

RF10/Constant Framerate (same as source)/Baseline/Level 3.0/Without Code = average(4758kbps) / Peak (13783kbps)
RF10/Constant Framerate (same as source)/Baseline/Level 3.0/With Code = average(4691kbps) / Peak (11181kbps)

Code used = vbv-bufsize=8000:vbv-maxrate=8000

[joms]

I tried using the ver2.2 without any code and the same exact settings as above and it gave me a bitrate reading = average (3811kbps) / Peak (5752kbps).

I thought ver2.2 limits bitrate to 4000kbps? It still went pass it? Is this a bug in handbrake?

[hello_hello]

It could be that Handbrake does things a little "differently". The command line version of the x264 encoder behaved differently to the version Handbrake used in the past. In respect to making sure reference frame limits aren't exceeded when changing the x264 speed preset.... that sort of thing.
The command line version of the x264 encoder doesn't enforce VBV restrictions at all. If you want to use them for a particular level, then you need to add them to the command line yourself, or an encoder GUI might automatically do it for you. I think the latest version of Handbrake applies the appropriate VBV goodness automatically for each level. I'm not sure, but if it does, maybe adding different VBV settings to the command line yourself would have no effect, or maybe it'd throw a spanner into the "Handbrake" works. Anyway.....

It might be worth paying the log file a visit and investigating the command line Handbrake is using. Maybe look for an encode log where you added VBV settings yourself, and then for one where you didn't.

I looked back through the thread (post #20) would seem to indicate Handbrake has become rather VBV enthusiastic, automatically adding the appropriate VBV settings for the level being used. You didn't add vbv-bufsize=10000:vbv-maxrate=10000 yourself, I assume? So I guess it might pay to investigate how much x264 command line cleverness was endowed on Handbrake and if manually adding vbv-bufsize=8000:vbv-maxrate=8000 yourself is working correctly. I'm not even sure VBV settings will be included in the command line in Handbrake's log file, at least not until you add some yourself. It could be the normal VBV restrictions are "hard-wired" into the version of the x264 encoder which Handbrake uses.

[joms]

Hmmm that's a bit too technical for me now lol. If someone could help in and do the test on how to manually add a max bitrate on handbrake, itd be nice to know. Thanks

[hello_hello]

Best as I can tell from a few quick encodes, Handbrake does add VBV restrictions automatically according to the chosen profile and level, but if you specify something else, it uses "something else" instead.

For each little test I only encoded 500 frames. CRF10, veryfast, x264 speed preset, baseline profile, level 3.

With "vbv-bufsize=8000:vbv-maxrate=8000" included, MeGUI's output had an average bitrate of 6554kbps and a peak bitrate of 11295kbps, and for Handbrake they were 6533kbps and 11144kbps respectively. Without VBV settings, MeGUI produced an average of 7386kbps and a peak of 13776kbps. For Handbrake, 7420kbps and a peak of 13885kbps.

I guess there's only so much VBV can do. It appears the settings are being applied but I assume they don't act as a "hard limiter" on the bitrate as such, or they can only limit it successfully when the average bitrate realistic. By using such a low CRF value with fairly restrictive VBV settings, you're effectively telling the encoder to achieve two opposing goals. Output a quality which requires a bitrate of "x" while not using the required bitrate.

I suspect once you're encoding with a CRF value which isn't likely to have more than brief encounters with a bitrate higher than 8000kbps, the VBV settings will be able to do their job and the playbak problems will disappear.

[jagabo]

The issue may only be in how short term bitrates are reported. If you look at Bitrate Viewer's options there are three different ways of measuring bitrate: per second, per GOP, per GOP enhanced. Those don't correspond to what's truly important to a player. I trust x264's calculations more than Bitrate Viewer's.

A DVD player is a hardware device that has a fixed amount of memory and a fixed max rate at which data can be read off the disc. The DVD player uses a read ahead buffer and will have several compressed frames and several decompressed frames in memory. One of the decompressed frames is currently being displayed, other decompressed frames are waiting to be displayed, several frames are in the process if being decompressed, and finally the data from several compressed frames is in memory waiting to be decompressed. What's critical to the player is that this pipeline of frames never runs dry -- that every 1/30 second there is at least one frame decompressed and ready for display. That means you can have short term bitrate spikes higher than the maximum sustained rate at which the drive is reading data off the disc -- as long as there are frames around it with a lower rate.

This pipeline is what the vbv settings in x264 correspond to. Bitrate Viewer's reports don't take this pipeline into account, only showing per second, or per GOP bitrates.

If you find that the vbv 8000 encodings still give you problems try setting it lower until you find what works. For the time being I would leave reframes set to 1 to rule out problems with that. Once you've found what vbv settings work, go back and increase reframes to find what max the player allows. Careful though -- max reframes is likely to vary with the frame size. It might be safest to just leave it at 1.

[joms]

yeah for now ill stick with ref frame to 1. So far I am having no more problems with FPS-constant/baseline/level 2.2/RF18

How about framerates? I plan to use "same as source" but how about constant or variable? I see different suggestions in google some telling people that constant is better, some say variable.

My max framerate as per the manual is 30. Can i set my framerate to same as source and constant but assign in the option box to have a max framerate of 30? so that in videos which uses more than 30fps, it will automatically go down to 30 and on videos which are recorded below 30fps, it will just use the original framerate as per source?

[jagabo]

How about framerates? I plan to use "same as source" but how about constant or variable? I see different suggestions in google some telling people that constant is better, some say variable.

It depends on what you mean by "better". If you're looking for the most compression or the best quality at a particular bitrate (file size) then VFR is better. But as I mentioned before, many players (and editors if you ever have need to edit the videos later) don't handle VFR properly. So by using VFR you get a tiny bit more (or better) compression but you pay for it in compatibility.

With RF based encoding there is usually only about 1 percent difference in file size between CFR and VFR. With quality based encoding you can't see a 1 percent difference. I'd rather have wider compatibility than that extra 1 percent.

My max framerate as per the manual is 30. Can i set my framerate to same as source and constant but assign in the option box to have a max framerate of 30? so that in videos which uses more than 30fps, it will automatically go down to 30 and on videos which are recorded below 30fps, it will just use the original framerate as per source?

I would keep the frame rate the same as the source except in cases where the source's frame rate exceeds what your player is capable of. For example, with a 60 fps source you'll probably get the smoothest playback at 30 fps. A 50 fps source will give likely give you the smoothest playback at 25 fps. With other frame rates you'll just have to experiment.

[hello_hello]

The issue may only be in how short term bitrates are reported. If you look at Bitrate Viewer's options there are three different ways of measuring bitrate: per second, per GOP, per GOP enhanced. Those don't correspond to what's truly important to a player. I trust x264's calculations more than Bitrate Viewer's.

Yes I see what you mean. Although why would the frame based method show a maximum bitrate lower than the average bitrate?

I still had one of the VBV test encodes loaded in Bitrate Viewer and changing the method for reporting bitrates had the following effect on the maximum bitrate reported. Average bitrate remained the same (6554kbps).

Second based: 11295 kbps
GOP based: 9741 kbps
Frame based 2335 kbps

[jagabo]

The issue may only be in how short term bitrates are reported. If you look at Bitrate Viewer's options there are three different ways of measuring bitrate: per second, per GOP, per GOP enhanced. Those don't correspond to what's truly important to a player. I trust x264's calculations more than Bitrate Viewer's.

Yes I see what you mean. Although why would the frame based method show a maximum bitrate lower than the average bitrate?

If Bitrate Viewer is confused about the frame rate you can't trust what it says about bitrates. Different parts of the program may calculate rates differently resulting in different mistakes when the frame rate is misunderstood.

[theewizard]

Second based: 11295 kbps GOP based: 9741 kbps Frame based 2335 kbps

well the math is off somewhere
seconds bitrate 11295, frame bitrate 2335... even if averaged ..30 frames times 2335 is over 60,000
Not 11295
,
problem is.. where do the numbers come from
frame could be Decompressed display rate
while seconds could be compressed data from the file

it seems to me to be the only thing that explains the 5:1 difference
comparing apples to oranges , so to speak
makes it hard to understand what is really happening

stick with 2.2 and rf18 or rf 20
and i think you will be OK

[joms]

Yep. I'm trying out level 2.2 and RF18. So far so good.

By the way, is there any better alternative to bitrate viewer?

[jagabo]

where do the numbers come from

It's all meaningless because Bitrate Viewer screwed up the frame rate calculation. Use MKV instead and you'll get proper results. Or remux the MP4 into MKV with MMG and check the bitrate graph with that.

[joms]

or... get an alternative program to bitrate viewer that doesn't screws up the frame rate calculation =)