questions - suggestions - etc

[Conner]

Hello

I'm glad to see that someone has picked up the ball with Handbrake and have been keeping it up to date with new H.264 items.

A bit about myself. I've been compressing video in one way or another for about 10 years, using Cleaner back in the day (still has the best deinterlacing I've seen in any compression application) and using sorenson squeeze now for DV captures, and of course Handbrake (unless HB can't handle the DVD for some reason) for compressing DVDs. My 'goal' is to compress all my DVDs to mp4s to be able to play them when I want from my computer - or on my laptop when I travel, and at some point I'll own a iPod video (still waiting for a bigger screen) - so my compression target is 'to be able to play on an iPod video and have good quality'.

First some questions...

I d/ld the UB build yesturday and am a bit confused. When choosing H.264 Video, I get as options in the encoder x264 (h.264 Baseline iPod) and x264 (h.264 Main), in the previous 'a2' build there were three options with a baseline 3.0 as one of them. I am unclear if there is something wrong with the a4 UB build - or if 'ipod' is baseline 3.0. Since I don't own a video iPod, I can't confirm if the file will work. So is the UB 'a4' build 'good' and the terminology has just changed, or is there something wrong?

Is there any way to tell what 'baseline' a mp4 file is that has been compressed? The movie info screen in QT only shows 'H.264 Decoder' as the Format, nothing about baseline, nor does the properties screen seem to mention anything about baseline.

And now as a longtime user I'll toss out my suggestions - things I would like to see Handbrake do ... not sure if there is a good place to post these or not, but here goes.

1) I would like to be able to step thru the video frame by frame in the picture settings screen. The reason for this is so that I can tell if the video needs to be deinterlaced or not. With the 10 frames or so that you can preview, you don't always hit a frame that shows interlacing. Sure you can usually tell pretty quick if something is going to be interlaced or not - but for example Season 3 of X-Files seems to be pretty random, some episodes are interlaced, some are not. Pie in the sky request would be some sort of adaptive deinterlacing - but I'm guessing this is not something easy to do.

2) Chapters don't seem to start/stop exactly where they should, seems like they might be rounded or something, I will often get a bit before the start - or a bit after - or miss the very start, etc. The 'old' DVD ripping program OSeX seems to pull chapters out exactly, so I don't think it's something that 'can't be done'. This seems to be more important to Music Videos - they seem to like to lump all the videos as chapters to a title rather than having them all individually.

3) I'd like to be able to encode a VOB file. There are times when a DVD is set up in a way that makes Handbrake barf one way or another, Stargate SG-1 Season 7 and 8 have messed up audio. With Stargate I was able to extract the title using OSeX, then encode that to mpeg4 using Open Shiiva and the audio was correct. I would rather use Handbrake to compress of course (:

4) For cropping, I'd like some sort of 'maintain aspect ratio' checkbox, so that if I"m cropping the top it will crop the sides enough to keep image from getting squashed or stretched. I can guestimate them pretty good and/or do the math to get the exact numbers, but it could be something that is just 'done for me' instead.

5) I would like to see more audio options. If, for example, I'm coming from a mono source, it would be nice to be able to compress this to mono aac. I am guessing behind the scenes it uses the QT aac compression, which has 'good better best' options for encoding - does HandBrake us 'best' or 'better' ? Or does it use different encoding?

I suggest keeping a few versions back of the binary builds. As a developer (I do database administration/programming) I know that 'programmer' bug free is different that 'user' bug free - and it would be nice to be able to d/l an 'older' version in case the latest has some issues.

Anyway, I'll be around, and always willing to try out new builds. I have a Mac Pro 2.66 (only 1GB mem currently, will be bumping it up), a Mac Book 1.83/2GB setup (with XP pro in bootcamp) and a old Dell P4 3.4ghz 'laptop' (10lbs is not a laptop, heh) running Vista. I got a ton o DVDs to go thru, so it will be a never ending process most likely ... so if something doesn't work in a build I'll let you know (:

Thanks

[dynaflash]

I d/ld the UB build yesturday and am a bit confused. When choosing H.264 Video, I get as options in the encoder x264 (h.264 Baseline iPod) and x264 (h.264 Main), in the previous 'a2' build there were three options with a baseline 3.0 as one of them. I am unclear if there is something wrong with the a4 UB build - or if 'ipod' is baseline 3.0. Since I don't own a video iPod, I can't confirm if the file will work. So is the UB 'a4' build 'good' and the terminology has just changed, or is there something wrong?

In an effort to simplify the choices, for the mac gui I took out level 1.3 baseline. There really seemed no reason to keep it with the new baseline level 3.0 that is now available and works better on the iPod.

The "iPod" in the title just signifies to less proficient users that it works on the iPod. It is just baseline level 3.0. Gui change, thats all. We are still on the fence as to how to best handle that to be the most descriptive.

Any reason to keep the "old" baseline level 1.3 and we can bring it back.
Always open to ideas.

[Conner]

thanks - that was my guess but just wanted to be sure. A 'whats new' even on the dev builds might be nice - of course I tend to not read everything so if it was listed somewhere, then ... uh ... I'm just blind (:

and I just noticed there is now a forum for requests - thanks !

::goes to make a post::

heh, or not, still locked - well, when I CAN post there I will (:

[rhester]

and I just noticed there is now a forum for requests - thanks !

::goes to make a post::

heh, or not, still locked - well, when I CAN post there I will (:

Consider that a preview of things to come. =) Right now this site is still focused purely on support of/for developers, but our scope/mission is likely to expand rapidly in the very near future.

Rodney

[Conner]

Any reason to keep the "old" baseline level 1.3 and we can bring it back.
Always open to ideas.

does baseline 3.0 work with the first gen video iPod or just the most recent? If the first gen video iPods can play both 1.3 and 3.0 then I don't know of any reason to keep both.

[dynaflash]

They play both.

[jbrjake]

1) I would like to be able to step thru the video frame by frame in the picture settings screen. The reason for this is so that I can tell if the video needs to be deinterlaced or not. With the 10 frames or so that you can preview, you don't always hit a frame that shows interlacing. Sure you can usually tell pretty quick if something is going to be interlaced or not - but for example Season 3 of X-Files seems to be pretty random, some episodes are interlaced, some are not. Pie in the sky request would be some sort of adaptive deinterlacing - but I'm guessing this is not something easy to do.

Stepping through frame by frame: difficult. Having it load more frames for you to preview through instead of the 10 or so it does currently: easy. Adaptive deinterlacing: I'd love it, too, but no--not easy without calling another program for post processing filters more elaborate than ffmpeg's.

3) I'd like to be able to encode a VOB file.

So would I. I think that would be a really useful feature. Anyone know how to go about that? In fact, I wish HandBrake could read any source file ffmpeg could decode....that way I could use mencoder to adaptively deinterlace video before feeding it to HandBrake.

4) For cropping, I'd like some sort of 'maintain aspect ratio' checkbox, so that if I"m cropping the top it will crop the sides enough to keep image from getting squashed or stretched.

Err...I thought HandBrake did do this, with the "Keep aspect ratio" checkbox? Can you explain more, please?

I definitely think there's some room for improvement on the aspect ratio calculator, though. I'm considering adding a read-out of how much the output aspect ratio differs from the source (including autodetected cropping) at some point, so people can decide when to scale up and when to scale down for anamorphic encodes.

I am guessing behind the scenes it uses the QT aac compression, which has 'good better best' options for encoding - does HandBrake us 'best' or 'better' ? Or does it use different encoding?

Different. The open source FAAC library, I believe. "Good better best" is pretty much just Apple's way of explaining bit rate, as far as I know....so you're setting that yourself in HandBrake.

[Conner]

Err...I thought HandBrake did do this, with the "Keep aspect ratio" checkbox? Can you explain more, please?

the aspect ratio for the final movie has the ratio maintained, I am talking about the cropping though, you can crop say 10 off the top, and then going one more will make the final movie change its size, so there is a range of about 12 pixels of pre compressed size that go to the same final size - meaning that you're either stretching or squashing the image a bit. It may not sound like much, but certain material I can tell if this has happened, and I try to avoid it.

Think of it as a cropping ratio, seperate from the image ratio.

Different. The open source FAAC library, I believe. "Good better best" is pretty much just Apple's way of explaining bit rate, as far as I know....so you're setting that yourself in HandBrake.

no, if you export audio in QT, there is a data rate, channels (Stereo/mono), sample rate, and encoding quality, where 'best' takes longer to encode but comes out with better quality at the same bitrate. Open Shiiva must have used QT behind the scenes because it had the same options as Quicktime for the aac encoding.

Thanks for the answers. Still would like to see some sort of step thru, even if it's say 10 consecutive frames in 10 different places of the file, or something, being able to catch frames that show the interlacing can really be a crap shoot sometimes.

[jbrjake]

the aspect ratio for the final movie has the ratio maintained, I am talking about the cropping though, you can crop say 10 off the top, and then going one more will make the final movie change its size, so there is a range of about 12 pixels of pre compressed size that go to the same final size - meaning that you're either stretching or squashing the image a bit. It may not sound like much, but certain material I can tell if this has happened, and I try to avoid it.

That's unavoidable. It's what I was referring to above, when I mentioned a desire to have HandBrake tell users how much the output aspect ratio differs from the source AR. Would let people decide for themselves whether stretching or squashing distorts the ratio more for a given source and output.

Boring explanation:

Your height and width have to be multiples of 16, because MPEG compression divides the frames into 16x16 pixel blocks.

But if you do the math, you'll quickly see that mod16 (cleanly divisable by 16) values won't give you your proper aspect ratio.

For example, say you wanted to do a full height anamorphic encode of a 2.35:1 aspect ratio film.* Your correct height would be 363.57 pixels. However, because it has to be a mod16 value, you have to either stretch to 368 or squash to 352.

There's no way around it, unfortunately.

Oh, and regarding AAC: Ok. I now think the "Good Better Best" thing is Apple's way of changing the compression quantizer. I'm not familiar with libfaac, though, so I'm not prepared to figure out how to tell it a quantizer value to use in place of its default.

*Arithmetic I glossed over above for my example:
480 * 1.78 = 854.4
854.4 / 2.35 = 363.57

[Conner]

That's unavoidable. It's what I was referring to above, when I mentioned a desire to have HandBrake tell users how much the output aspect ratio differs from the source AR. Would let people decide for themselves whether stretching or squashing distorts the ratio more for a given source and output.

Boring explanation:

Your height and width have to be multiples of 16, because MPEG compression divides the frames into 16x16 pixel blocks.

But if you do the math, you'll quickly see that mod16 (cleanly divisable by 16) values won't give you your proper aspect ratio.

For example, say you wanted to do a full height anamorphic encode of a 2.35:1 aspect ratio film.* Your correct height would be 363.57 pixels. However, because it has to be a mod16 value, you have to either stretch to 368 or squash to 352.

ya, I know all this. What I am saying is that *if* the final movie is going to be 640x480, then the program should be able to do the math so that if I do a manual crop, if I crop stuff off the top, it will automatically crop off the sides to keep the cropping aspect ratio in line with the final aspect ratio. Sorenson Squeeze, for example, does this if you want it to.

There's no way around it, unfortunately.

oh, there's always a way around ... 'easy' ? perhaps not (:

[jbrjake]

ya, I know all this. What I am saying is that *if* the final movie is going to be 640x480, then the program should be able to do the math so that if I do a manual crop, if I crop stuff off the top, it will automatically crop off the sides to keep the cropping aspect ratio in line with the final aspect ratio. Sorenson Squeeze, for example, does this if you want it to.

Okay...so you want a checkbox that forces the manual height and width crop values to be linked to each other and compared against the source aspect ratio? Sure, that's doable. It will lead to cutting off portions of the visible frame, though I guess you knew that when you asked for it.

There's no way around it, unfortunately.

oh, there's always a way around ... 'easy' ? perhaps not (:

I mean there's no way around display distortion when cropping MPEG video. Cropping to the aspect ratio won't help, because the final pixel height and width still have to be cleanly divisible by 16--that still means stretching or squashing.

You can crop your 640x480 video down to 627.76*472, a perfect 1.33 AR, but what do you do then? Stretch it up to 640x480, needlessly reducing picture quality and increasing file size? Scale to the nearest mod16 values for height and width and distort the AR? Scale down to the next 1.33 AR pair of mod16 height and width values, needlessly reducing resolution? Each option has its place, but there's no way around the problem.

[Conner]

Okay...so you want a checkbox that forces the manual height and width crop values to be linked to each other and compared against the source aspect ratio? Sure, that's doable. It will lead to cutting off portions of the visible frame, though I guess you knew that when you asked for it.

Yep, that's what I'm saying I'd like.

There's no way around it, unfortunately.
I mean there's no way around display distortion when cropping MPEG video. Cropping to the aspect ratio won't help, because the final pixel height and width still have to be cleanly divisible by 16--that still means stretching or squashing.

You can crop your 640x480 video down to 627.76*472, a perfect 1.33 AR, but what do you do then? Stretch it up to 640x480, needlessly reducing picture quality and increasing file size? Scale to the nearest mod16 values for height and width and distort the AR? Scale down to the next 1.33 AR pair of mod16 height and width values, needlessly reducing resolution? Each option has its place, but there's no way around the problem.

Well, I would rather have uniform stretching or uniform reducing (I'll call this zooming) rather than having this be ununiform (I'll call this stretching)

Using an example in handbrake which might make it a bit more clear.

I have a run of the mill Source 720x480, output 640x480 track. Auto crop tells me I need to crop 6 from the left, and 2 from the right, 0 and 0 on the top.

Using the constraint of 16 pixel blocks, I can go to 640x480 or 624x480. Either one of these will cause some stetching and will end up with a final picture that is flatter or squished. It is my preference to go ahead and crop the top by 4 pixels and bottom by 2 pixles to get it close to the right aspect ratio and then compress to 640x480. For me this is the lesser of the two evils (either having a picture extra cropped or a picture stretched a bit since unless you don't crop anything, it's nearly impossible to avoid stretching/zooming the image up or down)

Thanks for following along (:

[jbrjake]

It is my preference to go ahead and crop the top by 4 pixels and bottom by 2 pixles to get it close to the right aspect ratio and then compress to 640x480. For me this is the lesser of the two evils (either having a picture extra cropped or a picture stretched a bit since unless you don't crop anything, it's nearly impossible to avoid stretching/zooming the image up or down)

K, I think I've got it now. Tough to keep all the different usage scenarios straight in my head. For some folks, scaling video up is the greater sin, and I guess I internalized that dogma.

I started looking at the preview frames issue, btw. Providing more than 10 frames isn't quite as easy as I hoped. Thought I could do it just by changing the number of iterations through a loop in PictureController.mm, but I now see all the real work's being done with raw video buffers in hb.c....

[jbrjake]

Trying to add more preview frames is more difficult than I expected.

PictureController.mm's Display:
calls
hb.c's hb_get_preview()
calls
libavc.h's avpicture_fill()

But what I can't figure out is where it's decided that there will be 10 frames displayed, or from where in the video each frame is selected.

I tried increasing the range of values fPicture iterates through in PictureController.mm. But if I click "next" after the 10th frame, all it does is repeat the final one.

The ten frames, though, seem to be evenly spread throughout the video. This leads me to infer that, somewhere, there's a function saying "Ok, choose 10 evenly spaced frames to preview"--but I can't seem to locate it.

As far as I can tell, the hb_get_preview() function only serves one frame at a time. Yet, nowhere in there do I see anything that would tell it from *when* in the video to select a frame. On the other hand, in PictureController.mm, there's an fPicture variable that corresponds to the frame. This *is* passed to hb_get_preview(), but that only seems to use it to set a unique temporary filename...

(I wish ffmpeg had better documentation of its API.)

[jbrjake]

Trying to add more preview frames is more difficult than I expected.

But, in the end, really simple. The code I couldn't find is in scan.c, as hb_log could have told me had I checked.

So now I've got Handbrake making 20 preview frames instead of 10. Takes twice as long to do it, though, so I'm hesitant on committing it to the svn. Maybe 15 frames? I definitely think 10 is a little low, and makes locating interlace artifacts a crapshoot.

The other possibility is a widget in the preferences, that lets users adjust the number of preview frames to decode and the distance between them. Or just a checkbox that tells scan.c to decode consecutive frames from a given point in the film like ffmpegX does. However, as the previews are loaded as soon as HB identifies a DVD/VIDEO_TS, it would require a relaunch of the app for changes to take affect.

(I'm still thinking about your other suggestions, Conner, but this was the easiest to do so I'm looking at it first.)

[Conner]

So now I've got Handbrake making 20 preview frames instead of 10. Takes twice as long to do it, though, so I'm hesitant on committing it to the svn. Maybe 15 frames? I definitely think 10 is a little low, and makes locating interlace artifacts a crapshoot.

The other possibility is a widget in the preferences, that lets users adjust the number of preview frames to decode and the distance between them. Or just a checkbox that tells scan.c to decode consecutive frames from a given point in the film like ffmpegX does. However, as the previews are loaded as soon as HB identifies a DVD/VIDEO_TS, it would require a relaunch of the app for changes to take affect.

(I'm still thinking about your other suggestions, Conner, but this was the easiest to do so I'm looking at it first.)

I wouldn't bother going from 10 to 15 or 20... it really doesn't address the issue and as you said it takes twice as long to process. The issue is not being able to identify interlaced source, the best way to identify interlaced souce is to take consecutive frames, not single random frames - as you said this would be a crapshoot. I've not used ffmpegX, but a checkbox solution sounds pretty good.

Since the other forums are now open, I'll repost there since it makes more sense to have this disuccsion there rather than here (:

[Lafaboune]

5) I would like to see more audio options. If, for example, I'm coming from a mono source, it would be nice to be able to compress this to mono aac.

I saw this planned feature for 0.8.0 future release and I hope is't s not .AAC limited but .mp3/.ogg too

Very useful for old Series with mono audio channel, you can put 2 audio tracks with the same video quality or boost video bitrate with 64 kbps available