That makes sense, I tried overriding that error in ffmpeg several times.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.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 propertiesAnd the same Vegas, when reading a file from a DV camera, claims that the PAR is 16:15
Code: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
In Premiere Pro, PAL 4:3 DV is interpreted as 1.0940 from a native import
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
+ Reply to Thread
Results 91 to 107 of 107
-
-
You can use -vf setsar
https://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar -
-
-
Last edited by SF01; 20th Jan 2025 at 14:49.
-
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] -
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"...) -
-
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. -
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 ? -
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/
Code: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 -
I found absolutely nothing in which Scenalyzer would be better than, for example, the Vegas Capture (vidcap) I use.
-
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). -
-
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%).
Similar Threads
-
Black screen when using WinDV to transfer mini tapes.
By winterhawk in forum Software PlayingReplies: 51Last Post: 12th Mar 2023, 18:42 -
VHS to digital file transfer issues
By Jeremy Smith in forum Newbie / General discussionsReplies: 3Last Post: 16th May 2021, 13:28 -
Transfer Mini DV alternative solution
By pchan in forum Capturing and VCRReplies: 1Last Post: 21st Aug 2020, 21:29 -
Using FireWire to transfer mini-DV tapes to digital files on a PC
By CaptainCatholic587 in forum Capturing and VCRReplies: 15Last Post: 23rd Apr 2020, 23:40 -
Transfer mini dv tapes to PC
By c-leigh in forum Capturing and VCRReplies: 2Last Post: 6th Apr 2020, 01:46