Encode DVD source and retain original video dimensions

[babygdav]

An ntsc source material like broadcast, dv tape, vhs, dvd, are all targeted originally to be displayed on a 3:2 aspect tv...

Do you just make this stuff up? I doubt that in the whole history of television manufacture there's ever been a 3:2 (1.5:1) television sold. In the old tube days they were all 1.33:1; these days they're (mostly) 1.78:1.

When 640x480 is displayed on a monitor, no squishing occurs, but if fed to a tv, it occurs to fit the 3:2 aspect ratio tv set instead of the 4:3 computer monitor.

Nonsense.

Whoops! Good catch!
Responded sleepy just as I got up, no glasses. He he... 2 next to 3 next to 4...

Anyways, original post corrected.

....

Basically, anything off the dvd has 720 horizontal pixels of information and any reduction to 640 throws away some of that - thus, NO 640 pixel encode of a 720 source dvd video contains what you had. Better to encode to 720, and specify the correct par rather than 640 with a par of 1:1 to retain the most detail possible.

[babygdav]

Using Quicksync reduces the 3+ hour encode to less than 15 minutes. (Only if you have an Intel cpu - sorry amd users.)

Wow, that's impressive... But how does the quality and size compare to a 3h encode with x264 ?

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cloud-comput...hite-paper.pdf

Extensive details here.

[abolibibelot]

@aedipuss

abolibibelot - your post #19 is a 16/9 source and needs to be re-encoded that way. you did it to 4:3 that's why a 1/3 of the video frame is missing.

I didn't do that encode, as explained, I was looking for a good quality recording of that documentary series and found this on some, well, rapid-stream-of-water kind of website, and wrote as a comment that the conversion had not been done right... In this case it wasn't even 4:3 vs. 16:9, it was Handbrake's auto crop cropping wildly wherever it saw black bars during its analysis, and the actual display aspect ratio (I re-read the discussion in question before posting this yesterday) was 1.44 (so neither 1.33 nor 1.78). The point was, don't let Handbrake do the cropping automatically.

@babygdav

There's also 4:3 letterboxed, in which case a crop of the top and bottom black bars helps reduce encoded file size since there's no video information of importance there. 1:1 pixel size depends on the crop and aspect ratio of the letterboxed video.

Black bars should be highly compressible, I never tested but from what I could gather encoding with or without black bars shouldn't affect the output's size by much. However they should still be removed (if they're present for the totality of a video), because if leaving them, the 4:3 frame will be displayed with both “letterbox” black bars and “pillarbox” black bars. I've seen this on TV too, on the Woodstock movie for instance, as broadcast on the french channel Arte in summer 2015 : if I remember correctly, the aspect ratio of the movie was 2.35:1 but the aspect ratio of the actual footage was narrower, probably 1.85, and so on a 16:9 screen there were large “letterbox” black bars (because of the 2.35:1 frame) and large “pillarbox” black bars (because of the 1.85:1 picture inside the 2.35:1 frame) ; a correct 16:9 TV broadcast should have switched to the 1.85 AR after the opening credits (or cropped it to 1.85 altogether if it didn't remove anything substantial to the credits).

On the historical aspect of aspect ratios, I found this video very well made, clear and thorough :
https://www.youtube.com/watch?v=3CgrMsjGk7k

[ss2012]

Wow didn't think I'd get so many opinions, thought it'd be a straight answer lol.

[babygdav]

https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Hardware-Based-Tra...aspx?pageNum=2

Generally, your initial handbrake settings are fine. Custom 0 crop, let it auto detect and set the rest.

Only improvement would be gpu accelerated encoding, if you have a Intel gpu with Quicksync, nvidia card, etc and have everything set in preferences to use the gpu to speed up encodes.

Else, cpu encodes will always work albeit slowly.