How best to handle (1) DV format in HB & (2) VHS videos?

[Mysterious]

Edited 4 Feb., pointless even attemtping to get help on this forum.
Happy HIGH n MIGHTY like to tell the newbie users where to get off .. well thank you for such a buggy hopeless program that crashes all the time, cannot cope with basic container formats .. cannot cope with the ideal lossless video format because apple produced it, not Linux. Of course Handbrake is a Linux program . it's not supposed to be ideal for Mac. It's not supposed to work ideally with QuickTime. Never was .. never will because QuickTime does not exist on Linux so Handbrake will never fix their compatibility issues.

The devs have made this very loud n clear.

So in other words, Handbrake will always be the same. Always a program that crashes due to QuickTime incompatibilities. Always waste hours & hours & days & weeks & months of your time with out-of-sync audio & video issues or encodes that just didn't work, crashes & program freezes, audio stream longer or shorter than the video, lol

Hardly a classy app. Definitely not one of your reliable plug n play apps that 'simply' does the job asked of it every single time. Unfortunately Handbrake will always be like this because the devs made it clear they will never fix the quicktime issue due to QT not existing on Linux. Seems they are reluctant to check other issues also. Seems HB cannot handle other high profile H264 formats with aac audio either. MPeg Streamclip has none of these issues despite not being updated in 3 years.

Yes I removed the original post. I removed the activity log. Was sitting here for over 2 weeks. Did you miss it. OH sorry. The replies somehow missed it I guess.

[mduell]

Thoughts as I read through your post:
What's your goal here?
Source is anamorphic so keep that.
DV sources are interlaced so you'll want decomb on to deal with that.
VHS sources are generally low quality so you'll want a higher than normal (for SD) rate factor.
Your choice in x264 settings are incredibly bizzare.
The source is pretty low quality.

I'd suggest starting with the High Profile preset. Disable detelecine since the material isn't telecined. Dump the AC3 passthrough track since the source is PCM. Lower the quality to about RF 22.

Then tell us what you want to change about the encode.

[Mysterious]

Thank you for your response. What did you mean my X264 settings are bizarre? lol Advice always welcome.
I'll try what you suggested & see how it goes. I didn't realise I had AC3 passthrough enabled, when AC3 did not even exist on the source. Looking back at my queue 5 completed & editing them, AC3 passthrough is not enabled, only one audio track AAC conversion. Odd.

I am rather conditioned into using VBR. I have a particular custom preset I base my conversions on. Reduced MeRange on this project to 48 or 32.
I am more use to converting to DVD, so conditioned into VBR use.

Objective is to provide a reasonable quality version of this project to others to share over a p2p file sharing network. I guess objective is to keep file size down whilst maintaining visible quality. 200-350 MB range. Some of the things I check for detail are hair, eyes. If hair looks blurry, I would prefer to up the quality so I can see the individual hair fibres on camera close-ups. ie: I compare to original source.

[mduell]

Thank you for your response. What did you mean my X264 settings are bizarre? Advice always welcome.

Well I looked at the first pass without realizing it was turbo so they looked pretty weird. In retrospect they're just slow.

I'll try what you suggested & see how it goes. I didn't realise I had AC3 passthrough enabled, when AC3 did not even exist on the source. Looking back at my queue 5 completed & editing them, AC3 passthrough is not enabled, only one audio track AAC conversion. Odd.

You didn't, but I suggested starting with the High Profile preset, which does.

I am rather conditioned into using VBR.

It's always a good time to upgrade to CRF.

I have a particular custom preset I base my conversions on. Reduced MeRange on this project.

Reduced? You're double the reasonable maximum.

[Mysterious]

DV sources are interlaced so you'll want decomb on to deal with that.

Decomb set to default or push across to Deinterlace?
If I push it across to Deinterlace, there's several Deinterlace options.

I am curious about the cropping the top of the video & exporting same height. Thus stretching the source. Won't this in itself cause some kind of blurriness? 576 down to 574, exporting as 576. Oh I notice on the new CBR high profile setting, it will now export as 720 x 592, loose anamorphic 767x592. ie: 2/0/10/12 crop as previously. Anamorphic Strict would be 698x574/744x574

BTW apologies, I had edited both my other posts after you responded to each. I hadn't expected such a fast response. I'm impressed but apologies.

[mduell]

I forgot to mention before that if you want slow/efficient options that's fine, but at least go with some that make sense. Rodeo's post covering the x264 presets is a good resource.

DV sources are interlaced so you'll want decomb on to deal with that.

Decomb set to default or push across to Deinterlace?
If I push it across to Deinterlace, there's several Deinterlace options.

Decomb default. If you still see combing, try playing with the decomb custom options or just go to deinterlace slower.

I am curious about the cropping the top of the video & exporting same height. Thus stretching the source. Won't this in itself cause some kind of blurriness? 576 down to 574, exporting as 576. Oh I notice on the new CBR high profile setting, it will now export as 720 x 592, loose anamorphic 767x592. ie: 2/0/10/12 crop as previously. Anamorphic Strict would be 698x574/744x574

You may as well go with strict and avoid the resizing. Also you probably want to check the cropping to see if autocrop got it right.

[Mysterious]

CBR & VBR seem to crop differently for some odd reason.

I did countless experiments using CBR & VBR (single & dual pass, advanced & basic settings, presets.) Size versus quality, I have to say for this particular VHS conversion project, VBR came out on top. In order to be near happy with the quality of the CBR it needed to be above the objective maximum file size (considerably actually.)

(1) In CBR during different parts of the video, it did not handle them well. (a) Camera pan up to red light above & back down, the shade & difference of lighting fading into background, I could visibly see 'PEG' artifacts. (b) Camera moving & zooming across the top of a wooden shining surface of an organ, in CBR it looked wavy, a little like looking in distance on a hot sunny day, that moving wavy mirage effect.
VBR seemed to handle both of these much better.

(2) One small change I made was to shrink the start & end titles by a couple seconds again. And used Photoshop to clean them. This won't have had much if any effect in CBR since it uses the same data rate all way through. But VBR should have benefited by the lack of unevenness that was partially replaced (not totally removing the overall unevenness.) Sure, the intro & end don't last long so was only a minimal change.

I realise many of the advanced functions of HB are experimental. And I guess the reason the devs here are pushing CBR is that they are aware HB's VBR has some issues.
With a decent MPeg2 encoder using VBR with destination for DVD, the vbr is generally seemless & smooth. You don't notice it. However, just now & again I could see what looked like picture perfect frames shine up. I guess it was more than one frame for my eyes to notice it. Not a smooth running of the VBR. Many people perhaps would not have noticed. Perhaps I can be a little too detailed & analytical at times lol

[Deleted User 11865]

CBR & VBR seem to crop differently for some odd reason.

Rate control and cropping are completely unrelated. This makes absolutely no sense.

I realise many of the advanced functions of HB are experimental. And I guess the reason the devs here are pushing CBR is that they are aware HB's VBR has some issues.

Again, nonsense. The HandBrake devs are not pushing CBR.
My best guess is that you're referring to Constant Quality (CRF), which is completely unrelated to CBR (Constant Bitrate). Please get your terms straight.

Both Constant Quality (CRF) and Average Bitrate (ABR) output video with a variable bitrate (VBR). Under normal conditions, at a given bitrate, the output of 2-pass ABR and CRF should be nearly identical.

[Mysterious]

My best guess is that you're referring to Constant Quality (CRF), which is completely unrelated to CBR (Constant Bitrate). Please get your terms straight.

Both Constant Quality (CRF) and Average Bitrate (ABR) output video with a variable bitrate (VBR). Under normal conditions, at a given bitrate, the output of 2-pass ABR and CRF should be nearly identical.

Ok thanks. Sorry for my confusion. Different results between them from what I see. But perhaps I need glasses. I'm not a high n mighty video professional like you. Yes I'm a Newb to HB. Happy now. And trying to cope with HB's constant issues with coping with formats, crashing. Past 3-4 months has been fun. Out of sync A/V.

Nonsense

Sure anything I say is. Logs, experience with HB, all nonsense.

I am curious about the cropping the top of the video & exporting same height. Thus stretching the source. Won't this in itself cause some kind of blurriness? 576 down to 574, exporting as 576. Oh I notice on the new CBR high profile setting, it will now export as 720 x 592, loose anamorphic 767x592. ie: 2/0/10/12 crop as previously. Anamorphic Strict would be 698x574/744x574

Again, my mistake in reference to cropping, But I"m a NEWBIE remember. Or perhaps it was all Just my imagination of course.

[mduell]

Your posts don't make much sense. They read like buzzword bingo, possibly autogenerated.

Given the constant misuse of terminology it's difficult to tell what you actually did. Activity logs would be useful.

[mduell]

Happy HIGH n MIGHTY like to tell the newbie users where to get off .. well thank you for such a buggy hopeless program that crashes all the time, cannot cope with basic container formats .. cannot cope with the ideal lossless video format because apple produced it, not Linux.

You mean Apple's completely proprietary video formats they refuse to share with anyone?

[dynaflash]

Edited, pointless even attemtping to get help on this forum.
Happy HIGH n MIGHTY like to tell the newbie users where to get off .. well thank you for such a buggy hopeless program that crashes all the time, cannot cope with basic container formats .. cannot cope with the ideal lossless video format because apple produced it, not Linux. Of course Handbrake is a Linux program . it's not supposed to be ideal for Mac. It's not supposed to work ideally with QuickTime. Never was .. never will because QuickTime does not exist on Linux so Handbrake will never fix their compatibility issues.

Um, you do realize that in fact HandBrake as we know it was originally developed on the Mac right (well, in fairness its *very* first platform was the now defunct BeOS, but I digress) ? In fact the mac version up until fairly recently was considered the flagship platform of HandBrake. The Windows Gui while older than the Linux Gui came after the Mac Gui. Only fairly recently with the addition of j45's most excellent Linux Gui (which was pretty much modeled after the mac version originally) was Handbrake largely adopted by the Linux crowd. Oh, and in fact if its a "Linux" program why are most of the presets aimed at Apple devices ? Why is it that the Mac version is the only one that supports a platform specfic audio encoder (CoreAudio) which the other platforms do not ? So to say that HandBrake is a "Linux Program" is ... at best incredibly inaccurate.
It would appear at first glance that http://www.macworld.com/article/152258/ ... f2010.html might disagree with you. But whatever.

The devs have made this very loud n clear.

As far as I know I am the first dev to reply in this thread, so not sure exactly where that comes from.

So in other words, Handbrake will always be the same. Always a program that crashes due to QuickTime incompatibilities.

Hmm, well thats a very interesting observation, as far as I can tell though one with no basis in fact or supporting evidence of any kind. But, if you say so ....

Always waste hours & hours & days & weeks & months of your time with out-of-sync audio & video issues or encodes that just didn't work, crashes & program freezes, audio stream longer or shorter than the video, lol

Hardly a classy app. Definitely not one of your reliable plug n play apps that 'simply' does the job asked of it every single time. Unfortunately Handbrake will always be like this because the devs made it clear they will never fix the quicktime issue due to QT not existing on Linux. Seems they are reluctant to check other issues also. Seems HB cannot handle other high profile H264 formats with aac audio either. MPeg Streamclip has none of these issues despite not being updated in 3 years.

Well, thats the beauty of it all. HandBrake comes with a Money Back Guarantee. Heres your refund. Sounds like Mpeg Streamclip is the software for you. Enjoy.

[Mysterious]

thank you for your wonderful replies. I'm wrong as always. But hey I'm just a newbie who came here looking for help. Looking at my other threads, seems comments only come when someone is ready to spill their unpleasantness.
What I said about Quicktime compatibility was not wrong, and just need to read around the forums to see the dev's saying they will not make HB more compatible with it. So many (not all) of my posts here were QT related.

[dynaflash]

thank you for your wonderful replies. I'm wrong as always.

You said it not me.

<Locked> for trolling.

[s55]

What I said about Quicktime compatibility was not wrong, and just need to read around the forums to see the dev's saying they will not make HB more compatible with it. So many (not all) of my posts here were QT related.

Stop making crap up. HandBrake outputs standard complaint files. QT plays said standard complaint files mostly without issue..... There isn't anything more to be said or done here.

The only thing we've made clear, is that QT won't be used for encoding, but this doesn't matter given that x264 is a far superior encoder which produces the same standards complaint files. This doesn't make QT's decoder any less "compatible"