mpeg file report wrong dimensions

If you are asking why avidemux doesn't understand how to correctly identify the size of an image then you've asked the wrong people. Maybe there's a setting that you're missing.

In general, a video will have a size like 704x576 but will also contain a separate aspect ratio which tells them how to stretch the video. This is how players like totem know how to render them.

Thanks,

Michael

Correct me if I misundersand something. Does My TV recieve a tv signal where the image is 1024 x 576, and then produce a mpeg file that identify itself as being 704 x 576, but also include information about how much to stretch it to get correct aspects? If this is true, I must say it sounds plain silly! But is it the case... ?

Thanks...

Thomas Jensen, Denmark

I can't really say I know much about the broadcasts in Denmark, but here in Australia most stations transmit a 720x576 image that is meant to be displayed with a 16:9 aspect ratio. 720x576 is the equivalent SD size. I'm sure that there's some reason for it but I don't know what it is.

Okay, I found out the problem IS the DVB-t driver (AF9015). If I use Totem to watch the tv signal from the USB DVB-T stick, it also say 704 x 576, so it is not just me-tv. Thanks for you answers! Now I will try to find a way to fix the real problem...

Over here in Europe, they typically broadcast DVB-T and DVB-S in the native PAL resolution(s) of 720 × 576 or 704 × 576. However, the pixels are not square and the desired on-screen aspect ratio is coded into the DVB transport stream (i.e. anamorphic coding is used). However, me-tv 0.7.5 on Ubuntu 8.04 seems to ignore the pixel aspect ratio, and the 12:11 pixel aspect ratio is used, resulting in a horizontally squeezed scene, as the second picture on

http://de.wikipedia.org/w/index.php?title=Bild:Illustration_anamorph_letterbox.jpg&filetimestamp=20050704133803

If the developers need help, I can also sort out some details - i.e. how this is implemented in the protocols, what part of the library stack should handle it etc.. However, I think the entire xine library machinary *should* automatically handle this, since for DVDs a similar anamorphic coding is used, and I am quite sure that anamorphic DVD playback works like a breeze (just a guess).

Exactly, xine should handle it. What happens when you record and play it back in xine? Have you told xine to use a fixed aspect ratio?

> Exactly, xine should handle it. What happens when you record and play it back in xine? Have you told xine to use a fixed aspect ratio?

I finally had time to do some tests with a small record [which is only 3 MB small].

mplayer and vlc play it correctly and without bailing in 16:9.

When using xine with any of its -r switches (auto, square, 4:3, anamorphic, dvb), it is never displayed in in the correct 16:9 aspect ratio but varying odd wrong ratios. However, if you explicitly set output.disable_scaling in the xine preferences, it will be correctly displayed in 16:9 when *directly* invoking xine (but not with the shell -widget mode used by me-tv). Maybe xine somehow ignores the stream's PAR (which according to mplayer is 1.78 ~= 16/9).

However, mpeg2dec was unable to decode the stream and tcscan (from the transcode package) did not recognize the contents [which seems to work nicely for other MPEG-2 files]. Maybe it lacks some required MPEG headers, and is actually some sort of DVB-TS rather than a valid MPEG-2 file?

Interesting. Good work. Which version were you testing?

I'm looking at implementing a VLC based renderer. Maybe that might help your situation.

Thanks,

Michael

> Interesting. Good work. Which version were you testing?

VLC media player 0.8.6e Janus
MPlayer 1.0rc2-4.2.3
xine v0.99.6cvs
mpeg2dec 0.4.1
transcode 1.0.2

All of them are from a [not fully up to date] Ubuntu 8.04 (Hardy) distribution.

> I'm looking at implementing a VLC based renderer. Maybe that might help your situation.

I just hit on [1], which suggests that you can configure your xorg.conf "Monitor" section to specify the desired pixel aspect ratio for GStreamer - it also seems to affect Xine. I can not test this in -widget shell mode until next week, but the "direct" xine invocation now has the correct PAR. Probably the issue is fixed for me now.

All of this seems to suggest that Xine and GStreamer completely ignore the stream's PAR, and instead let the PAR be defined by the fullscreen resolution of the monitor. This convention seems to be totally unintuitive, odd and wrong. Also because it imposes the fullscreen PAR to any window.

Why can't all media players

a) just use the stream's PAR
b) fit it to any window/monitor
b1) in a letterbox
b2) using pan&scan

That's how stand-alone video playback devices handle it - because it is the only reasonable playback mode preserving the correct aspect ratio (as decided by the stream provider).

[1] https://code.fluendo.com/elisa/trac/ticket/493

Ha, I was actually asking what version of Me TV you did your testing on because there have been a few version increments since your last report.

I can confirm that xine and GStreamer both apply the PAR correctly on my system.

Thanks,

Michael

> Ha, I was actually asking what version of Me TV you did your testing on because there have been a few version increments since your last report.

I use me-tv 0.7.6 and I didn't report it, because after analayzing the me-tv/xine interaction source code, I was convinced that the issue has nothing to do with me-tv.

With my up-to-date Ubuntu Hardy distribution I can still verify that xine and GStreamer only use the correct PAR iff the xorg.conf file contains a section like

Section "Monitor"
        Identifier "Standardbildschirm"
        Option "DPMS"
        DisplaySize width-of-monitor height-of-monitor
EndSection