Is 704x480 with a 16:9 DAR valid for DVD?

[jagabo]

it seems to go against actual examples of DVDs I have:

What's your view on the Goldeneye images I posted?

I agree with your observations of Goldeneye. But I have DVDs which show the opposite, they look more appropriate with the full 720x480 frame stretched to 16:9. Here's the MGM logo from the start of The Good, the Bad, and the Ugly:



If you stretch it to 853x480 (assuming the full 720x480 frame is the 16:9 picture) the circle is almost perfect. If you stretch it to 873x480 (assuming the inner 704x480 is the 16:9 picture) the circle is too wide.

A shot from the movie:



If you stretch to 853x480 and crop away the top and bottom letterbox bars you are left with 853x364, 2.34:1. If you stretch to 873x480 and crop you have 873x364, 2.40:1. IMDB shows the movie to be 2.35:1. The DVD box also says 2.35:1.

[intracube]

I agree with your observations of Goldeneye. But I have DVDs which show the opposite, they look more appropriate with the full 720x480 frame stretched to 16:9.

I've just created a DVD with some test cards formatted in various ways, and played it on a standalone player. The results point to the iso13818-2 pdf, and what you've been saying as correct. It looks as though Goldeneye has been produced incorrectly.

EDIT: I'm going to have to retract that last paragraph (for now). I totally screwed up the encoding of the testcards. Or ffmpeg did. Yes, that's it, I'll blame ffmpeg.

[intracube]

Hopefully, this test will show if DVD players use the whole 720x480/720x576 area or just the central 704x480(702x576) region when sequence_display_extension() is not present.

The test focuses on the 576 active line 'PAL' standard, but the same should apply to 480 line 'NTSC'.

Here's a 1280x720 testcard:

Now lets create 3 16:9 videos with it, where:
1) The image is scaled directly to 720x576
2) The image is scaled to 702x576 then padded to 704x576
3) The image is scaled to 702x576 then padded back to 720x576



*If the iso13818-2 standard is followed; when displayed on a TV, example 1 and 2 should appear the same - the DVD player should scale 1 and 2 internally so they both match the 52 microsecond active line width for pal. Example 3 should look narrower as it already includes some of the line blanking.

*If DVD players are based on the CCIR-601 standard then examples 2 and 3 should look the same, and example one should look wider.

Result: On all 4 DVD/TV sets that I have access too - examples 2 and 3 look the same. My players at least, match the spec explained in posts #9 and #18 and don't map the entire reconstruced frame to the entire active region of the display.

[jagabo]

As I reported earlier, using similar test patterns, my player displays the entire 720x480 frame scaled to 16:9. When the frame is 704x480 it adds 8 pixel wide pillarbox bars to the left and right edges then displays that 720x480 frame as 16:9. This is with the player upscaling to 1920x1080p60, viewed on a TV with no overscan (every pixel of the input is displayed pixel-for-pixel on the face of the LCD).

I'm not citing this as definitive proof, just giving it as one data point.

Result: On all 4 DVD/TV sets that I have access too - examples 2 and 3 look the same. My players at least, match the spec explained in posts #9 and #18 and don't map the entire reconstruced frame to the entire active region of the display.

This conclusion may not be correct -- your player could be doing what mine does: add pillarbox bars to the narrower frame before sending it to the TV. Can you see the edges of the frame? Or does your TV overscan?

[Anonymous344]

IMDB shows the movie to be 2.35:1. The DVD box also says 2.35:1.

I wouldn't set much store by either IMDb or the box. 2.35:1, 2.39:1 and 2.40:1 are all just approximations. There was supposed to be a transition from 2.35:1 to 2.39:1 after about 1970, but post-1970 films are still routinely labelled 2.35:1 because of convention. Moreover, I have seen notable differences in cropping on different transfers of the same film. There really is no consistency as to how studios crop transfers.

[edDV]

Picture 1 shows incorrect PAR (1.420) and hence incorrect aspect ratio.

Pictures 2 and 3 show ~correct PAR (1.4568) in the 704x576 area. Picture 3 shows additional information wider than 16:9 in the outer left/right 8 pixels.

I'm curious to test how the TV sets display charts 2 and 3 (704x480/576 vs 720x480/576) in "just scan" mode. Most TV sets will overscan hiding the difference. The TV's ATSC/DVB tuner will be feeding 704.

Ref
http://www.dvddemystified.com/dvdfaq.html#3.5

[jagabo]

I'm curious to test how the TV sets display charts 2 and 3 (702x480/576 vs 720x480/576) in "just scan" mode.

I've already stated how my TV displays them. They both look the same because the player adds 8 pixel thick pillarbox bars to the 704 frame before upscaling to 16:9 and sending it to the TV. I see the pillarbox bars in both.

[intracube]

As I reported earlier, using similar test patterns, my player displays the entire 720x480 frame scaled to 16:9. When the frame is 704x480 it adds 8 pixel wide pillarbox bars to the left and right edges then displays that 720x480 frame as 16:9.

What DVD are you playing that you know to be 704 pixels wide? Could you try the standard def video out on your player?

This conclusion may not be correct -- your player could be doing what mine does: add pillarbox bars to the narrower frame before sending it to the TV. Can you see the edges of the frame? Or does your TV overscan?

I might not have explained well - my point was that when switching between examples 1 and 2, the displayed images should look identical *if* the player is mapping the 720 wide video and 704 wide video to fit 52 microsecond active line width.

It isn't - the 702 area of the 704 wide image, and the 702 area of the padded 720 wide image (example 2 and 3) are being mapped to the 52 microsecond active line - therefore no jump in picture width when I switch back and forth.

I've tried on 5 DVD players in 4 separate TVs:
2 Sony DVD players (1 from 2000, the other 2005), a Samsung, a Sony PS2 Slim and a Pioneer. All show consistent output.

Someone will have to get an oscilloscope on the line out from a player and read off the line width. Assuming it's accurate enough, that should be definitive.

[intracube]

Picture 1 shows incorrect PAR (1.420) and hence incorrect aspect ratio.

I agree. But the values you quote are based on Rec. 601/BT.601/CCIR 601. I did that example deliberately to show that the paragraph in iso13818-2 - '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' is in conflict with (from the dvddemystified link) '720-pixel and 704-pixel sizes have the same aspect ratio because the first includes overscan'.

Pictures 2 and 3 show ~correct PAR (1.4568) in the 704x576 area. Picture 3 shows additional information wider than 16:9 in the outer left/right 8 pixels.

So, are you agreeing that that 2 and 3 are properly formatted?

If I'm not explaining well, I'll try and do a diagram to clarify.

[edDV]

Pictures 2 and 3 show ~correct PAR (1.4568) in the 704x576 area. Picture 3 shows additional information wider than 16:9 in the outer left/right 8 pixels.

So, are you agreeing that that 2 and 3 are properly formatted?

If I'm not explaining well, I'll try and do a diagram to clarify.

Yes this is what I'd expect for 704 and 720 DVD player HDMI digital output*.

Analog out would replace the outer 16 pixels of 720 with blanking making both outputs the same.


*but it may be possible the DVD player pads 704 to 720 with 8 pixel side bars over HDMI. The main point is the 16:9 picture is contained in 704x480/576.

[jagabo]

What DVD are you playing that you know to be 704 pixels wide?

Test charts similar to yours. I made them from BMP images with HcEnc (no sequence_display_extension).

I might not have explained well - my point was that when switching between examples 1 and 2, the displayed images should look identical *if* the player is mapping the 720 wide video and 704 wide video to fit 52 microsecond active line width.

I agree.

It isn't - the 702 area of the 704 wide image, and the 702 area of the padded 720 wide image (example 2 and 3) are being mapped to the 52 microsecond active line - therefore no jump in picture width when I switch back and forth.

Unless you can see the entire frame you can't say whether the the 704 pixel wide frame is filling the 52 us active line width, or whether the player is padding the 704 pixel wide frame to 720 pixels wide then using all 720 pixels to fill the 52 us active line width.

[jagabo]

The main point is the 16:9 picture is contained in 704x480/576.

That is true of the CCIR-601 spec, not the MPEG spec. The MPEG spec clearly states the full frame is to be scaled to the indicated DAR. PAR is not explicitly defined in an MPEG stream, only implied by the frame size and DAR.

[edDV]

The main point is the 16:9 picture is contained in 704x480/576.

That is true of the CCIR-601 spec, not the MPEG spec. The MPEG spec clearly states the full frame is to be scaled to the indicated DAR. PAR is not explicitly defined in an MPEG stream, only implied by the frame size and DAR.

But DVD, DV and ATSC/DVB all reference ITU-Rec-601 with same PAR's for 704 and 720. Other MPeg2 applications may deviate but the "TV" space is consistent. Digital broadcasting space is all 704. DV and DVD add 720 as an alternative but the 16:9 active image is still defined as 704.

[jagabo]

DVD add 720 as an alternative but the 16:9 active image is still defined as 704.

Not according to the MPEG 2 spec. The spec provides a mechanism to signal that the 704x480 portion of a 720x480 frame is the 16:9 picture -- the sequence_display_extension. And it clearly states that in the absence of a sequence_display_extension the entire frame is the 16:9 picture. I didn't see any exceptions for 720 pixel wide frames in the iso13818-2 or iso13818-1 documents. Apparently none of us has access to the DVD spec so we can't say if there is an exception there. Or you can argue that the producers of DVDs ignore the MPEG 2 spec and assume the inner 704x480 (or 704x576) encodes the DAR. But we have seen evidence here both ways.

[edDV]

DVD add 720 as an alternative but the 16:9 active image is still defined as 704.

Not according to the MPEG 2 spec. The spec provides a mechanism to signal that the 704x480 portion of a 720x480 frame is the 16:9 picture -- the sequence_display_extension. And it clearly states that in the absence of a sequence_display_extension the entire frame is the 16:9 picture. I didn't see any exceptions for 720 pixel wide frames in the iso13818-2 or iso13818-1 documents. Apparently none of us has access to the DVD spec so we can't say if there is an exception there. Or you can argue that the producers of DVDs ignore the MPEG 2 spec and assume the inner 704x480 (or 704x576) encodes the DAR. But we have seen evidence here both ways.

Those are the two options but the TV industry is all about interoperability. Constant PAR for 704 and 720 was specifically implemented so that 720 to 704 could be done with a crop, not a horizontal rescale. Analog conversion crops 720 to 52 usec with blanking insertion.

[edDV]

DVD add 720 as an alternative but the 16:9 active image is still defined as 704.

Not according to the MPEG 2 spec. The spec provides a mechanism to signal that the 704x480 portion of a 720x480 frame is the 16:9 picture -- the sequence_display_extension. And it clearly states that in the absence of a sequence_display_extension the entire frame is the 16:9 picture. I didn't see any exceptions for 720 pixel wide frames in the iso13818-2 or iso13818-1 documents. Apparently none of us has access to the DVD spec so we can't say if there is an exception there. Or you can argue that the producers of DVDs ignore the MPEG 2 spec and assume the inner 704x480 (or 704x576) encodes the DAR. But we have seen evidence here both ways.

Those are the two options but the constant PAR for 704 and 720 was specifically implemented in the TV industry for interoperability. A 720 source could be converted to 704 digital or analog with a simple crop instead of a horizontal rescale. MPeg2 is more general but the DVD spec continues constant PAR for 720 and 704.

That isn't to say the DVD authors couldn't take creative freedom with how they defined 16:9, how they cropped the transfer and whether video extended out to 720 when viewed digitally.

[intracube]

Test charts similar to yours. I made them from BMP images with HcEnc (no sequence_display_extension).

I assume you've checked the resolution of the encoded videos with something like mediainfo? Initially, ffmpeg converted my 704x576 example to 720x576 during encoding, rather than leaving the dimensions alone.

Unless you can see the entire frame you can't say whether the the 704 pixel wide frame is filling the 52 us active line width, or whether the player is padding the 704 pixel wide frame to 720 pixels wide then using all 720 pixels to fill the 52 us active line width.

I can see what you're saying. But if the player were to do that to the 704x576 example, it wouldn't be following the iso13818-2 standard '...the entire reconstructed frame is intended to be mapped to the entire active region of the display' - I take the 'entire reconstructed frame' to mean the decoded 704x576 video, the active region of the display must equate to 52 microseconds line width.

Here's a diagram of what I think is happening. The purple lines represent 1 row of pixels and how they fit to the PAL signal:
The bottom two are how I think my DVD players are formatting the image and correspond to edDV's description. The top line is in conflict with the bottom:

I'll try and do a modified diagram to match what you're saying.

[jagabo]

I assume you've checked the resolution of the encoded videos

Yes.

The bottom two are how I think my DVD players are formatting the image and correspond to edDV's description. The top line is in conflict with the bottom:

Yes, I know you think that. But since you can't see the edges of the picture, and you don't have an oscilloscope to measure it, you can't say for sure that is what's happening.

Did you measure the square box on your TV? I wouldn't trust a CRT but an LCD or plasma should (?) be accurate.

<edit>...

I just checked the analog composite output of my DVD player by capturing with an ATI 650 USB2. The capture card appears to follow the 601 spec -- capture as 720x480, including 8 pixels outside the active picture width at each edge. The 720x480 DVD frame filled the captured 720x480 frame. A 704x480 DVD frame had 8 pixels of black border added (by the player) at the left and right edges of the frame and the 720x480 cap clearly showed them. This indicates the composite output of the player matches the CCIR601 spec. But this is at odds with the upscaled HDMI output where the 720x480 frame fills the 1920x1080 frame, and a 704x480 frame is padded with 8 pixels left and right before upscaling. I'd be curious to see what other peoples upscaling DVD players do.

The above tests were performed from a DVD using your 1280x720 file scaled to 720x480 or 704x480. I measured the white box on the HDTV via the upscaled HDMI signal (both in "just scan" and 16:9 modes on the HDTV). The 720x480 frame gave the correct aspect ratio (the box was square). The 704x480 frame gave a box that was too narrow. The way my system is set up it's not easy to route the analog output from the DVD player to the TV. I'll try it tomorrow if I get the time.

Oh, I also tried the tests with 720x576 and 704x576 PAL DVDs. The behavior on my player was the same as with NTSC.

[intracube]

I've had a more thorough read through my copy of 'DVD Demystified' 2nd Edition...which I should have done in the first place...
It's a good book - got a copy for ~£8 inc p&p from the U.S as its been replaced by the 3rd Edition.

page 289 'DVD-Video is based on a subset of MPEG-2 (ISO/IEC13818)'
page 292-293 'The 720- and 704-pixel rasters produce identical pixel aspect ratios because the 720-pixel version includes more of the horizontal over-scan area (with a scanning line period of 53.33 microseconds),whereas the 704-pixel version is a tight scan (with a line period of 52.15 microseconds).'
page 528 'DVD is based on the ITU-R BT.601 formats that do not use square pixels'

There is a bit of inconsistency, (also on page 528) 'To account for pixel geometry differences, create 525-line (NTSC) video graphics at 720x540 and then scale them down to 720x480 before encoding.' - should be scaled to 704x480, then padded.

There is also a mention about encoder inconsistencies for NTSC users which could further affect the aspect ratio - on page 529 'Video from D1 tape has pixel dimensions of 720x486. To conform to MPEG-2 dimensions of 720x480, some encoders scale and some encoders crop the extra six lines; however no consistent approach exists. Some crop 3 from the top and 3 from the bottom, others crop 6 from the bottom...'
- 'cropping an odd number of lines is a bad thing for video, since it changes field dominance and can cause interlacing artifacts'

display_horizontal_size - which is an option within sequence_display_extension is mentioned on page 292: 'The MPEG-2 display_horizontal_size value is set to 720 for 16:9 display mode and 540 for 4:3 display mode'. sequence_display_extension is also mentioned in a Philips user manual, (which references parts of the DVD spec.) which I found online.

[jagabo]

page 292-293 'The 720- and 704-pixel rasters produce identical pixel aspect ratios because the 720-pixel version includes more of the horizontal over-scan area (with a scanning line period of 53.33 microseconds),whereas the 704-pixel version is a tight scan (with a line period of 52.15 microseconds).'

I suspect he just assumes MPEG 2 conforms to the 601 spec as far as the 704 vs 720 frames are concerned.

I think we've seen that the industry doesn't pay much attention to this. Some do it one way, some do it the other.

[Anonymous344]

May I check a few details? If the whole 720x480 is the 16:9 frame, the sequence_display_extension is not set, but if the 704x480 portion of a 720x480 image is the 16:9 frame, the sequence_display_extension should be set. As HC Enc does not set the sequence_display_extension, I would like to add it with Restream, so what should values should I input? I understand that the values should be binary.

If I author a 704x480 16:9 DVD, what should I input for the sequence_display_extension in that case? Thanks for any help. I almost have everything I need to know.

[intracube]

May I check a few details? If the whole 720x480 is the 16:9 frame, the sequence_display_extension is not set, but if the 704x480 portion of a 720x480 image is the 16:9 frame, the sequence_display_extension should be set. As HC Enc does not set the sequence_display_extension, I would like to add it with Restream, so what should values should I input? I understand that the values should be binary.

I haven't used Restream before, but from looking at the screenshot of the interface it looks like you enter a decimal value. As there seems to be conflicting information on this topic, I'm not sure what the value should be. I would guess 704, if you're following iso13818-2.

However, page 292 of DVD Demystified states 'The MPEG-2 display_horizontal_size value is set to 720 for 16:9 display mode and 540 for 4:3 display mode.'
I haven't figured out the meaning of that.
EDIT: I remember now - it was suggested earlier in this thread that this was related to pan-scanning.

If I author a 704x480 16:9 DVD, what should I input for the sequence_display_extension in that case? Thanks for any help. I almost have everything I need to know.

I wouldn't have thought you needed sequence_display_extension at all, as the 16:9 image will fill the entire area of the 704x480 frame. Nor would you need it if you scaled a 16:9 image to 720x480. It's only needed in your first example - 704x480 active area within 720x480.

I'm hoping to acquire a decent oscilloscope to measure the active line width from a selection of DVD players. This would confirm if the DVD players I have access to follow ITU-R BT.601, or not. I still think it's a real possibility. I'll revisit this topic if/when I have more info.

[Anonymous344]

I haven't used Restream before, but from looking at the screenshot of the interface it looks like you enter a decimal value. I would guess 704, if you're following iso13818-2.

Thanks, intracube.

I wouldn't have thought you needed sequence_display_extension at all, as the 16:9 image will fill the entire area of the 704x480 frame. It's only needed in your first example - 704x480 active area within 720x480.

Thanks again! I had hoped that this was the case, but I wanted to make sure.

I'm hoping to acquire a decent oscilloscope to measure the active line width from a selection of DVD players. This would confirm if the DVD players I have access to follow ITU-R BT.601, or not. I still think it's a real possibility. I'll revisit this topic if/when I have more info.

I'll look forward to it.

[edDV]

Keep in mind if you use Adobe Premiere, AVID, Final Cut Pro, Vegas, etc they encode 16:9 PAR as 1.212 (480 line) or 1.455 (576 line). That defines the 16:9 area as 704 pixels wide. 720 pixels provides additional width that gets cropped off for broadcast.

DVD authors are free to define 720 as the 16:9 area but that would alter aspect ratio and would play back side cropped to broadcast or many HDTV sets. If the source is wider than 16:9, aspect ratio can be preserved as the additional height is absorbed by the letterbox area.

[Anonymous344]

Are people sure that HCEnc does not set the sequence_display_extension? The files that I have encoded with HCEnc recently seem to show the sequence_display_extension in GSpot and Restream. Has there been a change of behavior in 0.25?

[jagabo]

I've really only used HC via HcGui. That adds a sequence_display_extension if you specify colorimetry. The GUI doesn't seem to allow specifying the frame parameters in the structure. I don't know if there's a command line argument for it.

[hank315]

HCenc only writes the Sequence Display Header if:
- the colorimetry has been defined using the *COLOUR command
- if pan scan is active, colorimetry will default to BT.470-2 System B,G

Otherwise the Sequence Display Header will not be written in the stream.

jagabo beats me by it

[intracube]

HCenc only writes the Sequence Display Header if:
- if pan scan is active

From reading DVD Demystified and what you're saying, is the display_horizontal_size within sequence_display_header used exclusively for the pan scan feature?

I can't see how display_horizontal_size can be used simultaneously for the pan scan feature and specifying the active frame area - 720x480 vs 704x480 (iso13818-2 vs Rec.601).

Hank, do you have access to the official 'DVD-Video Book'? Can you confirm whether DVD Demystified is right/wrong where it states - 'DVD is based on the ITU-R BT.601 formats that do not use square pixels'?

[Anonymous344]

@jagabo and hank315, thank you both. I was indeed setting colorimetry.

@intracube, I have looked at a few commercial discs that look to have the picture contained in the 704x480 picture area within a 720x480 frame -- thin black bars on the left and right are visible. They all have the sequence_display_extension set to 720x480. I am not sure that it is right to set it to 704, even though it would certainly make sense to do so. I think that with the sequence_display_extension it might be the case that if it is not set the entire frame is taken as the picture area -- we knew this for sure already -- but if it is set, then it is set to 720x480 (for NTSC widescreen). I haven't yet found a 720x480 disc that has a sequence_display_extension of 704x480. Would you let me know if you find one that does?

[lordsmurf]

Or you can argue that the producers of DVDs ignore the MPEG 2 spec

Yes.

Although 16x9 may be within the spec, the problem lies in devices and software that only work with a limited subset of the DVD-Video specs. My biggest rants in past years have been against software like Adobe Encore or Sonic DVDit!, which only chooses to accept limited interpretations of what should be allowed. MPEG chipsets tend to poorly support playback of non-standard sizes (i.e., 352/720x 4:3 + 720x 16:9). Everything else is random in how well it works.

Whether or not that should be how it goes is what I've long argued. But sadly, it is what is is.