Mini DV to Digital Transfer Dissatisfaction

[SF01]

And the same Vegas, when reading a file from a DV camera, claims that the PAR is 16:15

  Duration: 01:00:56.88, start: 0.000000, bitrate: 29917 kb/s
  Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28800 kb/s, 25 fps, 25 tbr, 25 tbn
  Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 32000 Hz, stereo, s16, 1024 kb/s

PAL 4:3 DV (a native DV imported file) is read as Pixel Apsect 1.0926 (PAL DV) in (both Sony and Magix) Vegas Pro - the same as the project properties

In Premiere Pro, PAL 4:3 DV is interpreted as 1.0940 from a native import

Yes, on import Vegas changes the PAR (and even project settings!), but when importing the file from camera it saves it to the file as 16:15.

Vegas does not "change" the PAR, that's what PAL DV 4:3 is interpreted as to begin with in vegas .

When you export DV, it is still interpreted 1.0926. Re-import the exported PAL DV file back into vegas

What you read as 16:15 looks like ffmpeg console, not Vegas. ffmpeg interprets the file's SAR as 16:15, not vegas. The native camera file is interpreted in ffmpeg as 16:15 as well, regardless of vegas. That is ffmpeg's intepretation error, not vegas' error

That makes sense, I tried overriding that error in ffmpeg several times.

[poisondeathray]

That makes sense, I tried overriding that error in ffmpeg several times.

You can use -vf setsar

https://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar

[SF01]

That makes sense, I tried overriding that error in ffmpeg several times.

You can use -vf setsar

https://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar

I experimented with that too, I only use ffmpeg to expand to "square" pixels upon compression to mp4.

[rgr]

This is why I never do that, the only program for DV transfer from tape is ScenalyzerLive, this is not up for debate.

And why?
The previous "not up for discussion" didn't work well.

[SF01]

This is why I never do that, the only program for DV transfer from tape is ScenalyzerLive, this is not up for debate.

And why?
The previous "not up for discussion" didn't work well.

Why it's the only suitable program, or why is it not for debate?

[rgr]

What you read as 16:15 looks like ffmpeg console, not Vegas. ffmpeg interprets the file's SAR as 16:15, not vegas. The native camera file is interpreted in ffmpeg as 16:15 as well, regardless of vegas. That is ffmpeg's intepretation error, not vegas' error

This is not an "interpretation" error, PAR 16:15 is explicitly written in every frame of the film.

[FRAME]
media_type=video
stream_index=0
key_frame=1
pts=9
pts_time=0.360000
pkt_dts=9
pkt_dts_time=0.360000
best_effort_timestamp=9
best_effort_timestamp_time=0.360000
duration=1
duration_time=0.040000
pkt_pos=1504264
pkt_size=144000
width=720
height=576
crop_top=0
crop_bottom=0
crop_left=0
crop_right=0
pix_fmt=yuv420p
sample_aspect_ratio=16:15
pict_type=I
interlaced_frame=1
top_field_first=0
lossless=0
repeat_pict=0
color_range=unknown
color_space=unknown
color_primaries=unknown
color_transfer=unknown
chroma_location=topleft
[/FRAME]

[SF01]

What you read as 16:15 looks like ffmpeg console, not Vegas. ffmpeg interprets the file's SAR as 16:15, not vegas. The native camera file is interpreted in ffmpeg as 16:15 as well, regardless of vegas. That is ffmpeg's intepretation error, not vegas' error

This is not an "interpretation" error, PAR 16:15 is explicitly written in every frame of the film.

[FRAME]
media_type=video
stream_index=0
key_frame=1
pts=9
pts_time=0.360000
pkt_dts=9
pkt_dts_time=0.360000
best_effort_timestamp=9
best_effort_timestamp_time=0.360000
duration=1
duration_time=0.040000
pkt_pos=1504264
pkt_size=144000
width=720
height=576
crop_top=0
crop_bottom=0
crop_left=0
crop_right=0
pix_fmt=yuv420p
sample_aspect_ratio=16:15
pict_type=I
interlaced_frame=1
top_field_first=0
lossless=0
repeat_pict=0
color_range=unknown
color_space=unknown
color_primaries=unknown
color_transfer=unknown
chroma_location=topleft
[/FRAME]

It is an error indeed, same in VLC. ffmpeg natively thinks it's 16:15 (non-compliant with REC.601), Vegas will natively open it as 59:54.

[poisondeathray]

This is not an "interpretation" error, PAR 16:15 is explicitly written in every frame of the film.

Is it really "written" for DV ? Or is ffmpeg just making some guesses based on things like biWidth and BiHeight values?

Have you examined with RIFF or HEX editor ? Does it explicitly say 16:15 anywhere?

For h264, the SAR really is explicitly written into the video bitstream . This is well defined in the h264 specs. If the SAR value is absent or undef, then ffmpeg will guess the value based on other information. I'm not certain if DV writes the SAR value


Have you read any of the earlier posts ? Do you think 16:15 is the correct value for 4:3 PAL DV (whether or not it's written or "guessed") ? Or do you think Sony or Premiere or other NLE's are interpreting the value incorrectly? (or not reading what is "written", if it is "written"...)

[rgr]

This is not an "interpretation" error, PAR 16:15 is explicitly written in every frame of the film.

Is it really "written" for DV ? Or is ffmpeg just making some guesses based on things like biWidth and BiHeight values?

Yes, with the DV codec the PAR value is written.

[rgr]

This is why I never do that, the only program for DV transfer from tape is ScenalyzerLive, this is not up for debate.

And why?
The previous "not up for discussion" didn't work well.

Whyit's the only suitable program, or why is it not for debate?

1.

[SF01]

This is why I never do that, the only program for DV transfer from tape is ScenalyzerLive, this is not up for debate.

And why?
The previous "not up for discussion" didn't work well.

Whyit's the only suitable program, or why is it not for debate?

1.

Have you used it?

Here's a pretty detailed summary:
https://forum.videohelp.com/threads/407974-DVIO-vs-WinDV-vs-ScenalyzerLive-Which-one-to-use
In short SCLive offers the most functionalities.

[poisondeathray]

Yes, with the DV codec the PAR value is written.

Can you point out where the PAR is written for DV ? (Can you demonstrate with a hex editor or do you have specs that show where it is written ?)

How do you know that 16:15 is not being guessed or calculated from the DAR ? If you look at various DV encoders - they have 4:3 or 16:9 options. How do you know know that the PAR is actually being signalled, not the DAR ?

[poisondeathray]

According to this reference , for DV only "frame aspect ratio" of 4:3 , or 16:9 letter-boxed in 4:3, or 16:9 is signalled , not the PAR ; under the VAUX source control byte 2 , bits 0-2

https://web.archive.org/web/20100107032158/http://dvswitch.alioth.debian.org/wiki/DV_format/

VAUX source control (VSC)

Appears as pack 10 in VAUX block 2 (sequence block 5) in even sequences and pack 1 in VAUX block 0 (sequence block 3) in odd sequences.

    byte 0: pack type = 0x61
    byte 1:
        bits 6-7: copy protection = 0 (unrestricted)
    byte 2:
        bits 0-2: frame aspect ratio = 0 (4:3), 1 (16:9 letter-boxed in 4:3) or 2 (16:9)
        bits 3-7: reserved = 0x19
    byte 3:
        bits 0-3: reserved = 0xc
        bit 4: interlace flag
        bit 5: flag for frame differing from previous = 1 (usually)
        bit 6: flag for field 1 encoded before field 2 = 1 (usually)
        bit 7: flag for both fields present = 1 (usually)

That would imply that ffmpeg is indeed calculating the SAR, from the DAR and frame dimensions


16:15 is the value that solves the given vales of 4:3 DAR for a 720x576 frame.

4/3 = 16/15 x 720/576

[rgr]

[
Have you used it?

Here's a pretty detailed summary:
https://forum.videohelp.com/threads/407974-DVIO-vs-WinDV-vs-ScenalyzerLive-Which-one-to-use
In short SCLive offers the most functionalities.

I found absolutely nothing in which Scenalyzer would be better than, for example, the Vegas Capture (vidcap) I use.

[rgr]

Perhaps this is the explanation.

https://forum.doom9.org/showthread.php?p=1105162#post1105162

Let me compare between TV-Broadcast and DV home video

1.

ITU-BT-601 part A and EBU R92-1999 explicitly defines the number of samples of a line to be 864 in 50 field PAL systems.
The total time-length of a Gerber/PAL-norm line is 64µs, 12µs is the line-blanking time and 52µs the visible line. In the digital world line-blanking does not have importantance but the 52µs are the base for the actual SD-PAL system.

864 samples x 52µs/64µs = 702 samples (=> horizontal pixels).

Considering to 8 x 8 matrixes in encoders, the number is 704 samples per line
=> 52,14µs (within specs).

BT-601 specifies the duration of a digital active line as 720 samples (pixels). Therefore the 704 visible samples must be filled up with 16 (black) samples.

An ITU-BT-601/EBU complaining sample therefore is:

8 (black pixels) + 704 (52,14µs picture content) + 8(black pixels) = 720 pixels.

To show the 704 pixels on a PC in 4:3 there must be an upscaling by 768/704 = 1,091.
If the 16 additional rows have not been cropped before one gets 720 x 1,091 = 786 horizontal pixels where 786 - 768 = 18 pixel-rows are redundant in editing systems.

To show 16:9 there must be an upscaling with 1024/704 = 1,4545.
720 x 1,4545 = 1048 pixels, 1048 - 1024 = 24 redundant pixels, too.

Luminance signal uses 220 quantization levels, 16 for black and 235 for white.
Color-difference signal uses 225 qauntization levels.

2.

DV (is not a standard but Sony "house-norm" )

Instead of 704 it uses 720 active pixels in a line. The active time-length is 53,33µs.
and does not comply with the norm because only a maximun variation of +/-0,25%
is allowed (based on Gerber/PAL).
Because of the longer line-time-length, the upscaling factors 1,091 and 1,4545 are no
longer correct if we suppose, that both, a BT-601 and a DV camera, use a CCD-chip
with 768 row-pixels (4:3) or 1024 row-pixels (16:9).
The BT-601 camera delivers a 768/1024 full sampled row within 52,14 µs => 704 pixels
while the DV-camera needs 53,33µs = 720 pixels.
With other words, the BT-601 camera squeezes more than the DV-camera and therefore its correction factor (PAR) must be higher (1,091/1,4545 instead of 1,067/1,422).

[rgr]

of 4:3 PAL ITU-R REC.601 compliant video is 128:117.

So that this is still observed. I have to finally film the circle with my camera sometime. And I will know what the actual PAR is (at least according to Sony).

Good luck with your circle tests in finding out which of the commonly used ratios applies for your 4:3 video:
- 12:11 = 1.090909 acc. mpeg4 specs
- 1150:1053 = 1.092118 as can be derived from ITU-R BT.601-7
- 59:54 = 1.092593 (used by Vdub for example) as derived from sampling rate ratios of 13.5 MHz of Rec601 of and square pixel sampling rate of 14.75MHz
-128:117 = 1.094017 as postulated above by SF01 .....

Out of curiosity, I quickly measured it. The PAR came out at 1.423-1.428 for 16:9 and 1.072-1.079 for 4:3. Good luck with calculations

[Sharc]

of 4:3 PAL ITU-R REC.601 compliant video is 128:117.

So that this is still observed. I have to finally film the circle with my camera sometime. And I will know what the actual PAR is (at least according to Sony).

Good luck with your circle tests in finding out which of the commonly used ratios applies for your 4:3 video:
- 12:11 = 1.090909 acc. mpeg4 specs
- 1150:1053 = 1.092118 as can be derived from ITU-R BT.601-7
- 59:54 = 1.092593 (used by Vdub for example) as derived from sampling rate ratios of 13.5 MHz of Rec601 of and square pixel sampling rate of 14.75MHz
-128:117 = 1.094017 as postulated above by SF01 .....

Out of curiosity, I quickly measured it. The PAR came out at 1.423-1.428 for 16:9 and 1.072-1.079 for 4:3. Good luck with calculations

4:3 PAL DVDs are usually PAR 16:15 =1.067 (mpeg2), earlier ones with small black sidebars ~1.09 (ITU-R)
16:9 PAL DVDs are typically PAR 64:45=1.422 (mpeg2), exceptionally ~1.45 (ITU-R) depending how they were authored.
One does not know for certain how a DVD has been authored, and when played at exactly 4:3 or 16:9 the picture may be slightly distorted (~2.3%).