Something wrong with the video display width?

[BrainLai]

Compare to Quicktime7 when streaming/play MPEG4 video ES from an NTSC Camera:

If the video source width is QCIF(176 x 128), CIF(352 X 240), 4CIF(704 x 480), VLC always render them with a longer width except Full D1.

For example, VLC renders CIF(352 x 240) in 384 x 240 even if the source is from a recorded mp4 clip with correct dimension header 352x240 while Quicktime 7 doesn't.

Is it a bug or something else wrong?
All the settings are default.

Brain Lai

[DJ]

In your example you use NTSC 352 x 240 but the NTSC standard is 320 x 240 and is 4 x 3 or 1.33:1 (you do the math). Also all numbers should be divisible by 16 and in your example 384 is not, so it is unlikely this is a real circumstance. The only thing I could possibly think of is that SAR or DAR is improperly used in the encoding. To the best of my knowledge QT does NOT recognize these features.

[BrainLai]

In your example you use NTSC 352 x 240 but the NTSC standard is 320 x 240 and is 4 x 3 or 1.33:1 (you do the math). Also all numbers should be divisible by 16 and in your example 384 is not, so it is unlikely this is a real circumstance. The only thing I could possibly think of is that SAR or DAR is improperly used in the encoding. To the best of my knowledge QT does NOT recognize these features.

Thanks for your reply. However, after doing some study, I feel a little confused. Please refer to CIF definitions in the following sites:

Site1: Advantech0
Site2: PacketCine

It says that CIF is used to mean specific video resolution:
352x288 in PAL
352x240 in NTSC

And I grep the debug messages here for help:

Code: Select all

main debug: window size: 384x240 main debug: looking for video output module: 5 candidates vout_directx debug: creating DirectXEventThread main debug: waiting for thread completion vout_directx debug: DirectXCreateWindow vout_directx debug: created video sub-window main debug: thread 3984 (DirectX Events Thread) created at priority 0 (directx.c:263) vout_directx debug: DirectXEventThread running vout_directx debug: DirectXInitDDraw vout_directx debug: directx-device: vout_directx debug: vout_directx debug: screen dimensions (0x0,1024x768) vout_directx debug: DirectDraw Capabilities: overlay=1 yuvoverlay=1 can_deinterlace_overlay=1 colorkey=1 stretch=1 bltfourcc=0 vout_directx debug: End DirectXInitDDraw vout_directx debug: DirectXCreateDisplay vout_directx debug: DirectXCreateClipper vout_directx debug: disabling screen saver main debug: using video output module "vout_directx" vout_directx debug: NewPictureVec overlay:yes chroma:YV12 vout_directx debug: YUV overlay created successfully vout_directx debug: End NewPictureVec (succeeded) main debug: got 1 direct buffer(s) main debug: picture in 352x240 (0,0,352x240), chroma I420, ar 8:5, sar 12:11 main debug: picture user 352x240 (0,0,352x240), chroma I420, ar 8:5, sar 12:11 main debug: picture out 352x240 (0,0,352x240), chroma I420, ar 8:5, sar 12:11 main debug: direct render, mapping render pictures 0-6 to system pictures 1-7 main debug: waiting for thread completion

Does it seem that the CIF output video dimension is determined by the window size or affected by the wrong sar?

[DJ]

I had forgotten the VCD when I wrote my post. The same thing is true for the DVD today in that there is what is called the packed pixel and is expressed as DAR. I have no background in teleconferencing so I can't express its usage there. But DAR expands to the corrected aspect ratio. So in this case it would be:

VO: [directx] 352x288 => 376x288

As I recall this is also part of the D1 format specification. Its use in D2 and the DVD today corrects the divisible by 16 issue that caused some hardware problems.