Aspect ratio/resolution differences with HB 0.9.3

HandBrake for Windows support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

I have a simple batch file command that I was using with HB 0.9.2 but with 0.9.3 it gives very different output dimensions.
I will give log results for both versions of HB applied to the identical input file, a 480x480 mpeg2 with a display aspect ratio of 4:3 (per media info for example). Here is the command line:

Code: Select all

"%HBFolder%handBrakecli.exe" -i %mpgName% -o %mp4Name% -e ffmpeg -E faac -w 640 -Y 480 -b 900 -B 128 -R 48 -v
The test input is a one minute clip that is letterboxed to 16:9

Here is the log output for HB 0.9.2:
[17:34:23] hb_init: checking cpu count
[17:34:23] hb_init: starting libhb thread
[17:34:23] thread ed36b0 started ("libhb")
HandBrake 0.9.2 (2008022300) - http://handbrake.m0k.org/
2 CPUs detected
Opening I:\videos\adscan\Lost Worlds - ''Pirates of the Caribbean'' (Recorded...
, CSPAN).mpg...
[17:34:23] hb_scan: path=I:\videos\adscan\Lost Worlds - ''Pirates of the Caribbe
an'' (Recorded..., CSPAN).mpg, title_index=1
[17:34:23] thread ed3858 started ("scan")
[17:34:23] scan: trying to open with libdvdread
ERROR: dvd: DVDOpen failed (I:\videos\adscan\Lost Worlds - ''Pirates of the Cari
bbean'' (Recorded..., CSPAN).mpg)[17:34:23] file is MPEG Program Stream
[17:34:23] hb_sample_pts: pts 216198 at 1449984
[17:34:23] hb_sample_pts: pts 561543 at 4311040
[17:34:23] hb_sample_pts: pts 938420 at 7153664
[17:34:23] hb_sample_pts: pts 1304786 at 9984000
[17:34:23] hb_sample_pts: pts 1641122 at 12865536
[17:34:23] hb_sample_pts: pts 2010491 at 15693824
[17:34:23] hb_sample_pts: pts 2427908 at 18538496
[17:34:23] hb_sample_pts: pts 2794274 at 21393408
[17:34:23] hb_sample_pts: pts 3172652 at 24260608
[17:34:23] hb_sample_pts: pts 3505985 at 27099136
[17:34:23] hb_sample_pts: pts 3890369 at 29964288
[17:34:23] hb_sample_pts: pts 4193672 at 32788480
[17:34:23] hb_sample_pts: pts 4524002 at 35674112
[17:34:23] hb_sample_pts: pts 4914392 at 38492160
[17:34:23] hb_sample_pts: pts 5331809 at 41349120
[17:34:23] hb_sample_pts: pts 5693670 at 44210176
[17:34:23] add_audio_to_title: added MPEG audio stream 0xc0
[17:34:23] scan: decoding previews for title 1
[17:34:23] scan: preview 1
[17:34:23] scan: preview 2
[17:34:23] scan: preview 3
[17:34:23] scan: preview 4
[17:34:23] scan: preview 5
[17:34:23] scan: preview 6
[17:34:23] scan: preview 7
[17:34:23] scan: preview 8
[17:34:23] scan: preview 9
[17:34:23] scan: preview 10
[17:34:23] scan: 480x480, 29.970 fps, autocrop = 58/56/8/4
[17:34:23] hb_stream_update_audio: id=c0, lang=Unknown (MPEG) (2.0 ch), 3cc=und,
rate = 0, bitrate = 0, flags = 0x0 (0)
[17:34:23] scan: title (0) job->width:464, job->height:272
[17:34:23] thread ed3858 exited ("scan")
Scanning title 1[17:34:23] thread ed3858 joined ("scan")
...
[17:34:23] libhb: scan thread found 1 valid title(s)
+ title 1:
+ vts 0, ttn 0, cells 0->0 (0 blocks)
+ duration: 00:01:04
+ size: 480x480, aspect: 1.33, 29.970 fps
+ autocrop: 58/56/8/4
+ chapters:
+ 1: cells 0->0, 0 blocks, duration 00:01:04
+ audio tracks:
+ 1, Unknown (MPEG) (2.0 ch)
+ subtitle tracks:
[17:34:23] thread f08e88 started ("work")
[17:34:23] 1 job(s) to process
[17:34:23] starting job
[17:34:23] + device I:\videos\adscan\Lost Worlds - ''Pirates of the Caribbean''
(Recorded..., CSPAN).mpg
[17:34:23] + title 1, chapter(s) 1 to 1
[17:34:23] + 480x480 -> 640x368, crop 58/56/8/4
[17:34:23] + video frame rate: 29.970 fps
[17:34:23] + video bitrate 900 kbps, pass 0
[17:34:23] + PixelRatio: 0, width:640, height: 368
[17:34:23] + encoder FFmpeg
[17:34:23] + audio 128 kbps, 48000 Hz
[17:34:23] + encoder faac
[17:34:23] + c0, Unknown (MPEG) (2.0 ch)
[17:34:23] + Requested mixdown: Dolby Pro Logic II (HB_AMIXDOWN_DOLBYPLII)
[17:34:23] + Actual mixdown: Stereo (HB_AMIXDOWN_STEREO)
[17:34:23] thread f09480 started ("reader")
ERROR: dvd: DVDOpen failed (I:\videos\adscan\Lost Worlds - ''Pirates of the Cari
bbean'' (Recorded..., CSPAN).mpg)[17:34:23] + output: J:\Videos\MP4\Lost Worlds
- ''Pirates of the Caribbean'' (Recorded..., CSPAN).mp4
[17:34:23] thread f2d4b8 started ("muxer")
[17:34:23] thread f53b28 started ("MPEG-2 decoder (libmpeg2)")
[17:34:23] thread 112a3a0 started ("Renderer")
[17:34:23] 0.567033s: Film -> Video
[mpeg4 @ 0x873de0]removing common factors from framerate
[17:34:23] thread 150b580 started ("MPEG-4 encoder (libavcodec)")
[17:34:24] thread 1513ae8 started ("MPGA decoder (libavcodec)")
[17:34:24] thread 15d5068 started ("AAC encoder (libfaac)")
[17:34:24] sync: expecting 1974 video frames
[17:34:24] sync: first pts is 18000
Encoding: task 1 of 1, 2.33 %[17:34:24] 2.936067s: Video -> Film
Encoding: task 1 of 1, 4.00 %[17:34:25] 3.770233s: Film -> Video
Encoding: task 1 of 1, 5.12 %[17:34:25] 4.871333s: Video -> Film
Encoding: task 1 of 1, 6.53 %[17:34:25] 5.705500s: Film -> Video
Encoding: task 1 of 1, 7.80 %[17:34:26] 6.506300s: Video -> Film
Encoding: task 1 of 1, 87.54 % (88.85 fps, avg 88.40 fps, ETA 00h00m03s)[17:34:4
3] reader: done
[17:34:43] thread f09480 exited ("reader")
Encoding: task 1 of 1, 94.48 % (89.49 fps, avg 88.41 fps, ETA 00h00m01s)[17:34:4
5] 63.429833s: Film -> Video
Encoding: task 1 of 1, 97.37 % (89.49 fps, avg 88.41 fps, ETA 00h00m01s)[17:34:4
6] sync: got 1932 frames, 1974 expected
Encoding: task 1 of 1, 97.87 % (87.59 fps, avg 88.28 fps, ETA 00h00m00s)[17:34:4
6] thread 1513ae8 exited ("MPGA decoder (libavcodec)")
[17:34:46] thread 112a3a0 exited ("Renderer")
[17:34:46] thread 150b580 exited ("MPEG-4 encoder (libavcodec)")
[17:34:46] thread 15d5068 exited ("AAC encoder (libfaac)")
[17:34:46] thread f53b28 exited ("MPEG-2 decoder (libmpeg2)")
[17:34:46] thread f53b28 joined ("MPEG-2 decoder (libmpeg2)")
[17:34:46] thread 112a3a0 joined ("Renderer")
[17:34:46] render: lost time: 0 (0 frames)
[17:34:46] render: gained time: 0 (0 frames) (0 not accounted for)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] thread 150b580 joined ("MPEG-4 encoder (libavcodec)")
[17:34:46] encavcodec: closing libavcodec
[17:34:46] thread 1513ae8 joined ("MPGA decoder (libavcodec)")
[17:34:46] thread 15d5068 joined ("AAC encoder (libfaac)")
[17:34:46] thread f09480 joined ("reader")
Muxing: this may take awhile...[17:34:46] mux: file size, 8735368 bytes
[17:34:46] mux: track 0, 7670774 bytes, 951.94 kbps
[17:34:46] mux: video bitrate error, +418529 bytes
[17:34:46] mux: track 1, 1030308 bytes, 127.86 kbps
[17:34:46] mux: overhead, 6.93 bytes per frame
[17:34:46] thread f2d4b8 exited ("muxer")
[17:34:46] thread f2d4b8 joined ("muxer")
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 0 buffer(s)
[17:34:46] fifo_close: trashing 7 buffer(s)
[17:34:46] Freed 2 buffers of size 512
[17:34:46] Freed 3 buffers of size 1024
[17:34:46] Freed 2048 buffers of size 2048
[17:34:46] Freed 0 buffers of size 4096
[17:34:46] Freed 0 buffers of size 8192
[17:34:46] Freed 36 buffers of size 16384
[17:34:46] Freed 0 buffers of size 32768
[17:34:46] Freed 32 buffers of size 345600
[17:34:46] Freed 52 buffers of size 353280
[17:34:46] Allocated 34250752 bytes of buffers on this pass and Freed 34217984 b
ytes, 32768 bytes leaked
[17:34:46] thread f08e88 exited ("work")
[17:34:46] thread f08e88 joined ("work")
[17:34:46] libhb: work result = 0

Rip done!
[17:34:47] thread ed36b0 exited ("libhb")
[17:34:47] thread ed36b0 joined ("libhb")
HandBrake has exited.
And here is the log file for HB 0.9.3:
[17:55:45] hb_init: checking cpu count
[17:55:45] hb_init: starting libhb thread
HandBrake 0.9.3 (2008112300) - http://handbrake.fr/
2 CPUs detected
Opening I:\videos\adscan\Lost Worlds - ''Pirates of the Caribbean'' (Recorded...
, CSPAN).mpg...
[17:55:45] hb_scan: path=I:\videos\adscan\Lost Worlds - ''Pirates of the Caribbe
an'' (Recorded..., CSPAN).mpg, title_index=1
[17:55:45] scan: trying to open with libdvdread
[17:55:45] dvd: not a dvd - trying as a stream/file instead
[17:55:45] file is MPEG DVD Program Stream
[17:55:45] add_audio_to_title: added MPEG audio stream 0xc0
[17:55:45] scan: decoding previews for title 1
[17:55:45] scan: audio 0xc0: mp2, rate=48000Hz, bitrate=384000 Unknown (MPEG) (2
.0 ch)
[17:55:45] scan: 10 previews, 480x480, 29.970 fps, autocrop = 58/56/8/4, aspect
1:0.89, PAR 8:9
[17:55:45] scan: title (0) job->width:416, job->height:368
[17:55:45] libhb: scan thread found 1 valid title(s)
+ title 1:
+ vts 0, ttn 0, cells 0->0 (0 blocks)
+ duration: 00:01:04
+ size: 480x480, aspect: 0.89, 29.970 fps
+ autocrop: 58/56/8/4
+ chapters:
+ 1: cells 0->0, 0 blocks, duration 00:01:04
+ audio tracks:
+ 1, Unknown (MPEG) (2.0 ch)
+ subtitle tracks:
[17:55:45] 1 job(s) to process
[17:55:45] starting job
[17:55:45] Height out of bounds, scaling down to 480
[17:55:45] New dimensions 544 * 480
[17:55:45] work: sanitizing track 0 mixdown Dolby Pro Logic II to Stereo
[17:55:45] job configuration:
[17:55:45] * source
[17:55:45] + I:\videos\adscan\Lost Worlds - ''Pirates of the Caribbean'' (Rec
orded..., CSPAN).mpg
[17:55:45] + title 1, chapter(s) 1 to 1
[17:55:45] * destination
[17:55:45] + J:\Videos\MP4\Lost Worlds - ''Pirates of the Caribbean'' (Record
ed..., CSPAN).mp4
[17:55:45] + container: MPEG-4 (.mp4 and .m4v)
[17:55:45] * video track
[17:55:45] + decoder: mpeg2
[17:55:45] + bitrate 9000 kbps
[17:55:45] + frame rate: same as source (around 29.970 fps)
[17:55:45] + dimensions: 480 * 480 -> 544 * 480, crop 58/56/8/4
[17:55:45] + encoder: FFmpeg
[17:55:45] + bitrate: 900 kbps, pass: 0
[17:55:45] * audio track 0
[17:55:45] + decoder: Unknown (MPEG) (2.0 ch) (track 1, id c0)
[17:55:45] + mixdown: Stereo
[17:55:45] + encoder: faac
[17:55:45] + bitrate: 128 kbps, samplerate: 48000 Hz
[17:55:45] dvd: not a dvd - trying as a stream/file instead
[17:55:45] reader: first SCR 288
[17:55:45] mpeg2: "" (1) at frame 0 time 3003
[17:55:45] 0.400400s: Film -> Video
[17:55:45] sync: expecting 1974 video frames
[17:55:45] sync: first pts is 3003
Encoding: task 1 of 1, 2.79 %[17:55:46] 2.769433s: Video -> Film
Encoding: task 1 of 1, 3.95 %[17:55:46] 3.603600s: Film -> Video
Encoding: task 1 of 1, 5.12 %[17:55:46] 4.704700s: Video -> Film
Encoding: task 1 of 1, 6.43 %[17:55:47] 5.538867s: Film -> Video
Encoding: task 1 of 1, 7.50 %[17:55:47] 6.339667s: Video -> Film
Encoding: task 1 of 1, 93.52 % (89.34 fps, avg 86.08 fps, ETA 00h00m02s)[17:56:0
7] 63.263200s: Film -> Video
Encoding: task 1 of 1, 94.68 % (85.21 fps, avg 85.78 fps, ETA 00h00m01s)[17:56:0
7] reader: done. 0 scr changes
[17:56:07] sync: got 1902 frames, 1974 expected
[17:56:07] work: average encoding speed for job is 85.783287 fps
Muxing: this may take awhile...[17:56:08] mpeg2 done: 1903 frames00m01s)
[17:56:08] render: lost time: 0 (0 frames)
[17:56:08] render: gained time: 0 (0 frames) (0 not accounted for)
[17:56:08] mp2-decoder done: 0 frames, 0 decoder errors, 0 drops
[17:56:08] libhb: work result = 0

Rip done!
HandBrake has exited.
HB 0.9.2 is giving me the desired result with a PAR of ~1:1 and encoded size of 640x368, which MediaInfo declares as 16:9. This displays the correct 16:9 aspect ratio when played in VLC.

HB 0.9.3 is giving me an encoded size of 540x480 and MediaInfo says it is 544x480 with 1.133 aspect ratio. This displays the wrong aspect ratio when played in VLC, although I realize VLC can force difference aspect ratios.

Interesting things I note in the log data are:
1. Both versions come up with the same autocrop numbers: 58/56/8/4
2. HB 0.9.3 comes up with ..... aspect: 0.89 ...... while HB 0.9.2 says .......aspect: 1.33.... (which agrees with mediaInfo).

I know there are different aspect ratios (PAR, DAR, etc.) but I can't imagine what definition would yield 0.89 for this input. (?).

All I really want to know is how do I have to change the CLI args to get the behavior I was getting with the previous version, although I welcome learning more about what is going on also.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

Your source is 468*366 after cropping.
The stream signals a PAR of 8/9.
468 * 8 / 9 = 416
416 / 366 = source display aspect ratio of 1.1366.
Your specified width of 640 / 1.1366 = 563.
A height of 563 > max height of 480, so scale height down to that.
480 * 1.1366 = approximately 546.
546 does not divide cleanly by 16, so move to the nearest number that does: 544.

The only change is that now HB properly reads the source stream's PAR.
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

Thanks for the reply jbrjake and for HB.

The 8:9 PAR read by HB is not correct. Does HB actually read a PAR signal directly from the MPEG2 stream or does it compute it from the signaled DAR and storage dimensions?

The storage dimensions are 480x480. The signaled DAR (from mediaInfo) is 4:3. (Also I know this file was intended for SD TV playback.) Thus the correct input PAR is 4:3.

If my stream has an incorrect PAR field, is there a way to force HB to override it? I tried things like

-P 16:4:3

but they did not seem to do it.

If HB is reading the PAR directly from the stream I wonder if it would not be better to have it compute it based on DAR and storage dimensions? I say this because of what I found in a Google books search:

http://books.google.com/books?id=t0Dq7E ... &ct=result

Scroll up a few lines to see the paragraph on Aspect Ratio.

This book seems to say that DAR is the primary signal for aspect ratio in MPEG2, no?

I have verified the same behavior on other files. These are MPEG2's from SD Tivo recordings at 480x480 or 352x480 storage dimensions. MediaInfo reports DAR = 4:3 for all of them. HB reads PAR = 1.13 for 480x480 and PAR= 0.65 for 352x480. The encoded MP4's all have incorrect DAR's that make the videos play narrow.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

A: Mediainfo is not an authority.

B: The proper syntax for forcing a PAR in the CLI is -P16:4:3 because of how gnu getopt parses optional arguments to short option names.

C: I don't understand your argument about reading the sequence PAR. If that was the problem, there wouldn't be a problem, since your PAR is your DAR in this case. If HB was mistakenly reading DAR as PAR, you would get the result you want for this source. And if 8/9 was actually the DAR, then it would also be correct for it to display narrower than storage width....

D: If there is a problem here, it is your source. If you are certain 8/9 is not correct, then you should be filing a bug with TiVo or the broadcaster. HB can only work with what it's given. If it can't trust the video it's reading, it can't trust anything.
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

jbrjake:

Thanks for clarifying the -P option syntax. Whether to include the whitespace isn't clear from the CLI documentation.

I infer from your response that HB does read the PAR signal directly (rather than computing it from 2 or more other parameters). In that case I agree with you that my source files must have incorrect PAR signals.

What I was suggesting, based on the paragraph from the book link, was that if DAR is considered the primary signal in the current MPEG2 spec, then perhaps it is safer to read DAR and compute PAR based on DAR and stored dimensions (?). Maybe source files are more likely to have errors in the PAR signal than in the DAR signal (?).

Can you suggest utility software for determining video parameters from MPEG2 files that is more authoritative than mediaInfo ? One can also do ffmpeg -i <videofileName> -- is that better? (I've searched.)

Edit: Added info:
I have mp4box and I noticed it will give info on .mpg program stream files. Here is what it says for my file:
Track type: Video (MPG2)
Source: MPG2 480x480 @ 29.97 FPS PAR: 4:3
I'm now wondering if HB is actually getting the correct PAR.

Also, I've tried different -P settings and cannot find any combination of CLI parameters that will give me what I want.

Here is what I want:
1. If the input file is not letterboxed (i.e., autocrop doesn't crop), I want the output to be 640x480 with 1:1 PAR.
2. If the input file is letterboxed and autocrop removes M top lines and N bottom lines, I want the output to be 640x(480-M-N) with 1:1 PAR
(This is exactly what HB0.9.2 did with my simple command line given in the first post.)
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

Additional data: GSpot reports both DAR and PAR as 1.33 for my file. So far HB 0.9.3 is the only program that comes up with PAR = 0.89 for this file.
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

I've had some discussions on this DAR/PAR topic with DanR, one of the technical gurus at VideoReDo, a low-cost MPEG2 (and .Tivo, DVRMS, and VOB) editor program with a very good reputation.

I quote him with his permission:
We pretty much ignore the the sequence header display extension in our display and scale the
encoded dimensions based strictly on the DAR. This approach has never given us any
problems.

Of course, our own H.264/MPEG4 conversion code (still in development) doesn't seem to
have this problem as it ignores the display extension and simply sets the SAR/PAR of
the H.264 correctly.
Add this to facts presented earlier in this thread:

1. A recent book states that DAR is the primary aspect ratio signal for MPEG2.
2. mp4box reads the PAR as 1.33 (rather than 0.89 from HandBrake).
3. gspot reads the PAR as 1.33

I think this makes a pretty strong case that HandBrake needs a better way to read (or compute) PAR from MPEG2 videos.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

I prefer to trust in van.

You are barking up the wrong tree.

Libmpeg2 is well aware of how aspect ratio signaling works in MPEG-2, and it uses that information to calculate a PAR from the sequence header. It does not see your sequence as MPEG-2, so it follows MPEG-1 rules.

libmpeg2/header.c:finalize_sequence()

Code: Select all

    if (sequence->flags & SEQ_FLAG_MPEG2) {
	switch (sequence->pixel_width) {
	case 1:		/* square pixels */
	    sequence->pixel_width = sequence->pixel_height = 1;	return;
	case 2:		/* 4:3 aspect ratio */
	    width = 4; height = 3;	break;
	case 3:		/* 16:9 aspect ratio */
	    width = 16; height = 9;	break;
	case 4:		/* 2.21:1 aspect ratio */
	    width = 221; height = 100;	break;
	default:	/* illegal */
	    sequence->pixel_width = sequence->pixel_height = 0;	return;
	}
	width *= sequence->display_height;
	height *= sequence->display_width;

    } else {
	if (sequence->byte_rate == 50 * 0x3ffff) 
	    sequence->byte_rate = 0;        /* mpeg-1 VBR */ 

	switch (sequence->pixel_width) {
	case 0:	case 15:	/* illegal */
	    sequence->pixel_width = sequence->pixel_height = 0;		return;
	case 1:	/* square pixels */
	    sequence->pixel_width = sequence->pixel_height = 1;		return;
	case 3:	/* 720x576 16:9 */
	    sequence->pixel_width = 64;	sequence->pixel_height = 45;	return;
	case 6:	/* 720x480 16:9 */
	    sequence->pixel_width = 32;	sequence->pixel_height = 27;	return;
	case 8: /* BT.601 625 lines 4:3 */
	    sequence->pixel_width = 59;	sequence->pixel_height = 54;	return;
	case 12: /* BT.601 525 lines 4:3 */
	    sequence->pixel_width = 10;	sequence->pixel_height = 11;	return;
	default:
	    height = 88 * sequence->pixel_width + 1171;
	    width = 2000;
	}
    }

    sequence->pixel_width = width;
    sequence->pixel_height = height;
    simplify (&sequence->pixel_width, &sequence->pixel_height);
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

jbrjake,

How does one tell either from your code snippet or my activity log that HB did not recognize my file as MPEG2?

I don't see any case statement in the code snippet that gives 8:9 for the PAR.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

Heh, building the post I was working off of a web-based code repository's copy of libmpeg2, but I didn't want Trac line numbers on the sides, so I went to the code currently used by HB for the actual code snippet I pasted.

In older versions of libmpeg2, case 12 was 8/9 instead of 10/11 -- they recently switched to using ITU PAR values, which compensate for overscan.

Which raises the question of, how are you possibly getting the old values? HB 0.9.3 used the newer code with 10/11, and Scott built the Windows binaries off a clean checkout. And I can't think of any other way libmpeg2 would read 8/9 than that, somehow, it was built linked to the old lib. I've spent a bunch of time staring at the libmpeg2 code and can not conceive of any other way a 480*480 source would show up as 8/9 unless it was being parsed by an old copy of libmpeg2 and did not register the sequence as MPEG-2.
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

So where do we go from here? My Activity Log clearly says it was 0.9.3. I think I downloaded it sometime around 15 Dec, give or take a week. Has the download package changed since it was released in late November? In other words is there any point in downloading a fresh copy?
User avatar
s55
HandBrake Team
Posts: 10347
Joined: Sun Dec 24, 2006 1:05 pm

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by s55 »

any chance you could create a ~30 second sample of that clip and post it on a file download site?
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

s55 wrote:any chance you could create a ~30 second sample of that clip and post it on a file download site?
Sure! Here is the ***download link***.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

Well HB is definitely getting the 8/9 from m->info->sequence->pixel_width and pixel_height. I added some debug lines and it isn't a one-off error during scan....every sample during the encode has it filled in that way. And it gets it on all platforms.

Except I still, for the life of me, have no clue how that's possible. The version of libmpeg2 in use simply should not be capable of setting that as a PAR....and again, it is not misinterpreting the aspect ratio. It derives the PAR from the aspect ratio.

Patching contribs is a real pain with HandBrake's build architecture, but I guess adding debug lines to libmpeg2 is the next step.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

Ah. The source utilizes an optional component of MPEG2 to signal a display_width of 720 and a display_height of 480.

Which means instead of the PAR being
(4/3) / (480/480) = PAR 4/3
It's doing...
(4/3) / (720/480) = PAR 8/9

Looks to me like it is working entirely correctly and obeying MPEG-2 spec. Your source appears to be messed up, and the evidence indicates a strong likelihood that the other tools you use are only getting you the "right" result because they do not implement the full MPEG-2 spec.
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

As I understand it the relationship is:

(width/height) = DAR/PAR, where

width and height are encoding (or storage) dimensions in pixels.
DAR is display aspect ratio
PAR is pixel aspect ratio, also known as SAR (sample aspect ratio).

I assume the 4/3 you used must be the DAR -- what else would it be?

The encoding width and height are 480/480.

Thus we have PAR = DAR/(width/height) = (4/3)/(480/480) = 4/3

Now if you choose to subsitute 720/480 for DAR (possibly makes sense, i.e., defining a revised DAR per the optional 720/480 signal) you get: PAR = (720/480)/(480/480) = 3/2

To get your 8/9 result you have to substitute 720/480 for 480/480 but how can this be correct? In the forumla these are supposed to be encoding (or storage) dimensions in pixels, not display_width and display_height as signaled by the "optional component" (Sequence extension?).

It still doesn't look right to me.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

We're talking about the MPEG-2 spec here.

http://lists.mplayerhq.hu/pipermail/ffm ... 12115.html
Måns Rullgård wrote:Here's what the spec says:

display_horizontal_size - See display_vertical_size.

display_vertical_size - display_horizontal_size and
display_vertical_size together define a rectangle which may be
considered as the "intended display's" active region. If this
rectangle is smaller than the encoded frame size, then the display
process may be expected to display only a portion of the encoded
frame. Conversely if the display rectangle is larger than the
encoded frame size, then the display process may be expected to
display the reconstructed frames on a portion of the display device
rather than on the whole display device.

display_horizontal_size shall be in the same units as
horizontal_size (samples of the encoded frames).

display_vertical_size shall be in the same units as vertical_size
(lines of the encoded frames).

display_horizontal_size and display_vertical_size do not affect the
decoding process but may be used by the display process that is not
standardised in this Specification.

> Is this an incorrect stream or a bug in libavcodec?

Another quote from the spec:

aspect_ratio_information either specifies that the "Sample Aspect
Ratio" (SAR) of the reconstructed frame is 1,0 (square samples) or
alternatively it gives the "Display Aspect Ratio" (DAR).

- If sequence_display_extension() is not present, then it is
intended that the entire reconstructed frame is intended to be
mapped to the entire active region of the display. The sample
aspect ratio may be calculated as follows:

SAR = DAR * horizontal_size / vertical_size

NOTE 1 - In this case horizontal_size and vertical_size are
constrained by the SAR of the source and the DAR selected.

- If sequence_display_extension() is present then the sample
aspect ratio may be calculated as follows:

SAR = DAR * display_horizontal_size / display_vertical_size

This is obviously nonsense. Those divisions have to be reversed to
make any sense at all. With that correction, the standard appears to
imply that the DAR specified in the sequence header refers to the
displayed picture, i.e. display_horizontal_size x display_vertical_size.

In our case, this means that the 640x480 video is intended to be
cropped (where to cut would be specified in a picture display
extension, of which there are none in your stream) and displayed on a
640x240 output device with aspect ratio 4/3. Such a device would have
a SAR of 1/2.
Further elucidated by the developer of GSpot on doom9:
http://forum.doom9.org/showthread.php?p ... post542247
stegre wrote: But back to sequence_display_extension. I've confirmed, by both the behavior of my home DVD player and by the ISO MPEG-2 specification, that the very last thing I suggested is actually the case: the two SDE values in question,"display_horizontal_size" and "display vertical size", do indeed represent the "active part" of the frame. But we're supposed to "resize from" that, not "crop to" it. This is gonna confuse things, but the fact of the matter is that those values, when present and not equal to the frame size (normally 720 x 480 NTSC or 720 x 576 PAL), will change the pixel aspect ratio. In fact, the MPEG-2 specification defines the pixel aspect ratio (which they confusingly call "SAR") in terms of it. Here, I'll summarize the whole deal:

1. MPEG defines four possible aspect ratios for the physical display screen, as measured in inches or cm (not pixels). That's called "DAR", and the four possibilities are 4:3, 16:9, 2.21:1 and "variable” - which I won't get into, because of #2 below.

2. The DVD spec does not allow the last two possibilities above, so all DVD's have a DAR of 4:3 or 16:9.

3. Ignoring a few other oddball possibilities, all DVD's are encoded as MPEG-2, 720 x 480 encoded pixels (NTSC) or 720 x 576 pixels (PAL). That's called the frame size and their ratio is called FAR, so the FAR of DVD's is pretty much always 1.5 (NTSC) or 1.25 (PAL).

4. The MPEG-2 spec defines something they call "sample aspect ratio" or "SAR" and most other people call "pixel aspect ratio" or PAR. If the SDE values are not present, the PAR is defined, after flipping fractions to correspond to common usage and changing the word "SAR" to "PAR", as follows:

PAR = DAR/FAR

So there are really only four PAR values in common usage:

(4/3) / (720/480) = 0.8888 NTSC std
(16/9) / (720/480) = 1.1852 NTSC "anamorphic"

(4/3) / (720/576) = 1.0666 PAL std
(16/9) / (720/576) = 1.4222 PAL "anamorphic"

5: Here's where it gets interesting: If the SDE values are present, their ratio replaces "FAR" in the above equation. In other words, the numbers in the SDE replace the 720 & 480 (or 720 & 576 for PAL) in the four calculations above. You now have an infinite number of possible SAR's. However, it is interesting to note that the correct information for my Finding Nemo extra feature is:

4/3 x 480/540 = 1.1852

So they're using the same SAR that's usually used in a 16:9 anamorphic DVD, but using it to horizontally "stretch" the 480 active, non-black pixels to perfectly fit on a 3:2 screen.

Now, argue whether that should be called "anamorphic"!
_______________________________
ref: ISO/IEC 13818-2 sec 6.3.3
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

Yes, I'm now convinced you (and HB) are correct. I found essentially the same info you just posted in a book I have, "Video Demystified" by Keith Jack (4th Ed., 2005). It even had the reversed horiz/vert ratios. It all seems needlessly complicated and obscure.

So OK, HB is technically correct, but is it practically correct? Recall the quote from DanR of VideoReDo above that they ignore the sequence_display_extension values when displaying videos in their program and have never had a problem from doing that! (And their product is used on a wide variety of MPEG source types -- not just TiVo files -- by people who value it enough to pay for it.)

So I wonder, are there examples of where doing it the "correct" way actually gives a correct display, but doing it the incorrect way doesn't? My TiVo and TiVo-derived MPEGs display with the correct AR in Windows Media Player and Real Player. They display skinny in VLC player, presumably because it uses the same ffmpeg code base as HB.

Interesting discussion anyway.....
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by jbrjake »

dlflannery wrote:So OK, HB is technically correct, but is it practically correct? Recall the quote from DanR of VideoReDo above that they ignore the sequence_display_extension values when displaying videos in their program and have never had a problem from doing that! (And their product is used on a wide variety of MPEG source types -- not just TiVo files -- by people who value it enough to pay for it.)
Sorry, but you're not going to convince me that HB is wrong to follow the spec because a commercial product exists that doesn't follow the spec. So his users haven't complained. So what? I'm supposed to care that people "value it enough to pay for it" ? Fools and their money....
So I wonder, are there examples of where doing it the "correct" way actually gives a correct display, but doing it the incorrect way doesn't?
I already gave you an example. Read the post from stegre that I linked to. Like he says in the part I quoted, proper display of one of the extras for Finding Nemo requires following the MPEG-2 spec.
My TiVo and TiVo-derived MPEGs display with the correct AR in Windows Media Player and Real Player. They display skinny in VLC player, presumably because it uses the same ffmpeg code base as HB.
Huh? FFmpeg? What are you talking about? As I've said again and again and again, this is libmpeg2. It's a separate project entirely.
dlflannery
Posts: 41
Joined: Sun Jan 27, 2008 2:43 am

Re: Aspect ratio/resolution differences with HB 0.9.3

Post by dlflannery »

jbrjake,

OK, you've finally beaten me into complete submission -- and using logic and facts of all things! :shock:

Thanks for the learning experience!

P.S. I looked at libmpeg2 and noticed that VideoLan is listed as one of the using projects.
Post Reply