Re: [Mjpeg-users] More weirdness between beta2 and current CVS

[Jens B. J. <jb...@ul...>]

Aaron,

A couple of curious things here as near as I can tell:

 o The absense of display size in the second mpginfo printout. The display 
sequence extension structure that includes this info must be present since 
other data (such as "NTSC") is there. I suspect the values are the same (720 
x 480) and it just doesn't print them if they are identical to the horiz. and 
vert. size.

 o Display size is 540 x 480 in the working video streams. According to the 
definitions in the standard I would think this would cause your image to get 
cropped and you'd be missing 180 columns of pixels from your video (see 
below).

 o Your player interpretting display size to indicate whether or not 
to "stretch" the image. The standard seems to indicate that display size are 
to be used to tell the display process either that only a portion of the 
image needs to be displayed or that the image in the frame is only a portion 
of the intended screen size. In any case I can't see why it would stretch one 
image and not the other.

In any case if it is indeed the display size that is causing the problems it 
would not be too hard to write a tiny program that would fix your existing 
files (in-place in fact, as long as they are on r/w media) and set the 
display size to the 540 x 480 values. You'd just need to scan through the 
file looking for the display sequence extension block, then fix the bits for 
the display size horizontal and display size vertical and write them back 
out. You shouldn't need to re-encode or anything like that so your video is 
safe. However, even though this seems to be the apparent difference I'm 
surprised that this would cause such behavior. 

That said I should like to offer a very loud disclaimer that I am not an mpeg 
expert such as Andrew Stevens or others on this list apparently are and I 
could be grossly misinterpreting what display size is meant for. Perhaps one 
of them could weigh in?

Aaron Newsome <ane...@an...> said: 

> First, thanks everyone for for helping me out with my 30% larger files 
> sizes since -n 2 was removed from lav2yuv. The recommended fixes did 
> just the right thing.
> 
> Now I have a new problem, not sure what is happening but here are the 
> symptoms. While watching some videos on my flat screen gas plasma TV, I 
> noticed that some files would play with what looked like a correct 4:3 
> aspect, and some would not and they would stretch to fill the entire 
> screen, which is 16:9.
> 
> Of course a 4:3 picture stretched to a 16:9 aspect looks funny. As I 
> tested a few files it became apparent that the files that would display 
> correctly were encoded with beta2 mpeg2enc and the files that would fill 
> the screen were encoded with the CVS latest (as of about a week and a 
> half ago).
> 
> I ran mpginfo on two of the files and here is what I got,..
> 
> on a file that DOES display properly I get this:
> 
>   Mpeg 2 Video File
>   Estimated Duration: 03:14.13s
>   Aspect ratio 4/3 (TV)
>   Interlaced, chroma format: 4:2:0
>   Video Format: NTSC
>   Display Size [540 x 480]
>   Size [720 x 480]     29.97 fps    7.00 Mbps
> 
> on a file that DOES NOT display properly I get this:
> 
>   Mpeg 2 Video File
>   Estimated Duration: 03:45.86s
>   Aspect ratio 4/3 (TV)
>   Interlaced, chroma format: 4:2:0
>   Video Format: NTSC
>   Size [720 x 480]     29.97 fps    7.00 Mbps
> 
> Notice the file that display properly has "Display Size [540 x 480]". 
> Not sure if this was encoded into the file  by default on beta2, but my 
> encoding scripts have not changed so I assume the encoder default 
> behavoir *has* changed. I looked at the man page for mpeg2enc and I only 
> found the "aspect ratio" switch, which is in fact correct in the file 
> that does not work (according to the mpginfo command). What I did not 
> find was any kind of switch to adjust this "Display Size" which no 
> longer seems to be encoded into the file.
> 
> I'm sure everyone can start to understand my long standing reluctance to 
> ever upgrade mjpegtools. Now I have 60 or so files that I have encoded 
> that do not display properly on my TV and I no longer have the original 
> DV files. It is frustrating beyond belief,... a word to the wise: "read 
> those change logs carefully". I only upgraded a few weeks ago and I have 
> already found two cripling and extremely frustrating differences in the 
> releases.
> 
> Thanks, Aaron Newsome
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber Inc.
> Don't miss the IM event of the season | Special offer for OSDN members! 
> JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
> _______________________________________________
> Mjpeg-users mailing list
> Mjp...@li...
> https://lists.sourceforge.net/lists/listinfo/mjpeg-users
>