Mini DV to Digital Transfer Dissatisfaction

[Bernix]

Solved

[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 .....

[lollo]

Why so few :

https://web.archive.org/web/20140816103129/http:/lipas.uwasa.fi/~f76998/video/conversion/

https://encodingwissen.de/hintergrund/videobild/anamorph/itu-r-bt601/

https://forum.doom9.org/showthread.php?p=1058927#post1058927

[SF01]

Why so few :

https://web.archive.org/web/20140816103129/http:/lipas.uwasa.fi/~f76998/video/conversion/

https://encodingwissen.de/hintergrund/videobild/anamorph/itu-r-bt601/

https://forum.doom9.org/showthread.php?p=1058927#post1058927

Precisely, I did not pull 128/117 out of my bottom.
This is what DV, DVD, etc use:

[Attachment 84960 - Click to enlarge]
Also, this is the standard that software uses to work with ITU-R REC.601 compliant files.

[Attachment 84959 - Click to enlarge]

The problem with the German source is that it uses 575 for calculations, which is technically how much lines there are, but there are 2 half-lines one on top and one on the bottom, which effectively gives us 576 lines for which the uwasa table applies.

MPEG-4 PAR assumes PAL is encoded into 704 samples, which should not be the case, when using 704 samples the active image should still be in the REC.601-compliant 702 samples, which returns us back to 128:117.

Generic PAR 16:15 is an abomination, that is sadly used in modern DVDs and is completely non-compliant with REC.601 and when displayed through REC.601 compliant equipment it will be distorted.

Bottom line is, when converting full 720 DV to square pixels the precise number is not a natural number, in m yscripts I use 788 and 1050 for 4:3 and 16:9 respectively. For analog video transfers I trim to 702 first then expand to 768 and 1024.

[lollo]

From time to time, we often enter this endless SAR/PAR/DAR topic. The missing line (or the 2 half line) sub topic in PAL land is also very fascinating.

[SF01]

From time to time, we often enter this endless SAR/PAR/DAR topic. The missing line (or the 2 half line) sub topic in PAL land is also very fascinating.

That's because some people still refuse to accept the reality that DV despite recording all 720 samples with image is still REC.601 compliant. And now knowing simple math. 52 µ times 13,5 MHz equals 702. 576 times 4 by 3 is 768. 768 by 702 is 128:117, or ~1,094. End of story. No need to complicate with REC.470 divagations about the height of that half line, the fact that lines are slightly tilted, etc.

The half lines are clearly visible in the digitised frame as the top one starting from more or less half and the bottom one, if not lost in the headswitching noise is shorter.

We should do that circle shooting thing with analog and digital camcorders and pin it on the homepage.

[lollo]

That's because some people still refuse to accept the reality that DV despite recording all 720 samples with image is still REC.601 compliant.

OK, but Rec 601 is a specification for the digitization of an Analog signal. DV is digtal (just to clarify)

[SF01]

That's because some people still refuse to accept the reality that DV despite recording all 720 samples with image is still REC.601 compliant.

OK, but Rec 601 is a specification for the digitization of an Analog signal. DV is digtal (just to clarify)

Correct, but since it is capable of digitisation of analog signal and the resulting file is 601-compliant, it is completely reasonable to assume that DV is also compliant, especially that it was in the era where you would output the video through analog output to record to VHS, at least people did that, so it had to be backwards compatible. I've heard rumours of early camcorders only recording in the true active image area, but I don't recall details, so it might be a legend only.

[rgr]

ITU-R Recommendation BT.601, more commonly known by the abbreviations Rec. 601 or BT.601 (or its former name CCIR 601), is a standard originally issued in 1982 by the CCIR (an organization, which has since been renamed as the International Telecommunication Union – Radiocommunication sector) for encoding interlaced analog video signals in digital video form

[rgr]

Also, this is the standard that software uses to work with ITU-R REC.601 compliant files.

[Attachment 84959 - Click to enlarge]

And the same Vegas, when capturing 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

[SF01]

ITU-R Recommendation BT.601, more commonly known by the abbreviations Rec. 601 or BT.601 (or its former name CCIR 601), is a standard originally issued in 1982 by the CCIR (an organization, which has since been renamed as the International Telecommunication Union – Radiocommunication sector) for encoding interlaced analog video signals in digital video form

In case anyone did not already know what. And digitising analog signal to DV tape, or file does exactly that, and to keep backwards compatibility camera image recorded to DV has the same 601-comliant properties, after all wouldn't it be extra hassle just to make DV reciording from CCD with different Sample Aspect Ratio than when using the device as digitisation converter.

[SF01]

Also, this is the standard that software uses to work with ITU-R REC.601 compliant files.

[Attachment 84959 - Click to enlarge]

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

Exactly where?

[Attachment 84961 - Click to enlarge]

[poisondeathray]

And the same Vegas, when reading a file from a DV camera, claims that the PAR is 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 properties

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

[Sharc]

... I did not pull 128/117 out of my bottom....

No, you pulled it out of Jukka Aho's article.

.....And now knowing simple math. 52 µ times 13,5 MHz equals 702. 576 times 4 by 3 is 768. 768 by 702 is 128:117, or ~1,094. End of story.

End of story? Well well, this often quoted and copied article by Jukka Aho does not consider the 2 halflines correctly, but conveniently treats these as 2 full lines. The PAL height is actually 574 full-lines plus 2 halflines = 575 lines vertically rather than 576. 13.5 MHz luma sampling rate (acc. Rec.601) x 52us = 702 pixel horizontally, so we end up with 702x575 pixels resolution. Hence the Pixel Aspect Ratio (PAR) for a 4:3 Display Aspect Ratio then becomes 575x4:3/702 = 1150:1053 ~ 1.092118. That's where the 1150:1053 PAR comes from, as opposed to the 128:117 ~ 1.094017. The difference of ~0.174% should not cause sleepless nights though
MPEG4 eventually adopted mod16 compliant 704x576 "PAL" frame sizes with a PAR of 12:11=1.0909... for 4:3 DAR.
DVD never specified a PAR explicitely, but specified the DAR (4:3, 16:9) instead.
The original DVCAM specification references Rec.601 for the sampling raster, but it was later often violated by camera manufacturers following the DVD practice.

[SF01]

... I did not pull 128/117 out of my bottom....

No, you pulled it out of Jukka Aho's article.

.....And now knowing simple math. 52 µ times 13,5 MHz equals 702. 576 times 4 by 3 is 768. 768 by 702 is 128:117, or ~1,094. End of story.

End of story? Well well, this often quoted and copied article by Jukka Aho does not consider the 2 halflines correctly, but conveniently treats these as 2 full lines. The PAL height is actually 574 full-lines plus 2 halflines = 575 lines vertically rather than 576. 13.5 MHz luma sampling rate (acc. Rec.601) x 52us = 702 pixel horizontally, so we end up with 702x575 pixels resolution. Hence the Pixel Aspect Ratio (PAR) for a 4:3 Display Aspect Ratio then becomes 575x4:3/702 = 1150:1053 ~ 1.092118. That's where the 1150:1053 PAR comes from, as opposed to the 128:117 ~ 1.094017. The difference of ~0.174% should not cause sleepless nights though
MPEG4 eventually adopted mod16 compliant 704x576 "PAL" frame sizes with a PAR of 12:11=1.0909... for 4:3 DAR.
DVD never specified a PAR explicitely, but specified the DAR (4:3, 16:9) instead.
The original DVCAM specification references Rec.601 for the sampling raster, but it was later often violated by camera manufacturers following the DVD practice.

Which camera manufacturers and which models? DVD camcorders?
As for the article by Jukka Aho I see that Vegas uses the first line from the table, rather than 128:117, which comes from the mathematical solution when considering 576 lines, PAL does not have 575 lines, but 574 and 2 halves, these 2 halves do not add up to a full line. And are digitised into separate "full-length" lines.

In practive it basically comes down to a difference of 786 vs 787 vs 788 when expansing 720x576 video to square pixels. Certainly less noticable difference than expansing 720 to 768, because the difference between 768 and 788 is clearly visible to the naked eye when I manually adjust the aspect ratio on VLC. Even more in widescreen.

[Sharc]

As for the article by Jukka Aho I see that Vegas uses the first line from the table, rather than 128:117, which comes from the mathematical solution when considering 576 lines, PAL does not have 575 lines, but 574 and 2 halves, these 2 halves do not add up to a full line.

They actually add to a full line when one takes the slightly tilted shape of the analog scanlines of the 4:3 PAL frame into account. So it depends on how one looks at it. Not to argue, just to explain where the 1080:1053 originated from.

The 59:54 - as also used by some like Vdub for example - are based on the ratio of Rec.601 luma sampling rate of 13.5 MHz vs "industry standard" sampling rate for square pixels of 14.75 MHz, means 14.75/13.5 = 59:54 ~ 1.092593.

One has the choice.

[SF01]

As for the article by Jukka Aho I see that Vegas uses the first line from the table, rather than 128:117, which comes from the mathematical solution when considering 576 lines, PAL does not have 575 lines, but 574 and 2 halves, these 2 halves do not add up to a full line.

They actually add to a full line when one takes the slightly tilted shape of the analog scanlines of the 4:3 PAL frame into account. So it depends on how one looks at it. Not to argue, just to explain where the 1080:1053 originated from.

The 59:54 - as also used by some like Vdub for example - are based on the ratio of Rec.601 luma sampling rate of 13.5 MHz vs "industry standard" sampling rate for square pixels of 14.75 MHz, means 14.75/13.5 = 59:54 ~ 1.092593.

One has the choice.

Theoretically, but they are different parts of the image, thus can only be reproduced as separate lines in digitised image, hence 576 lines total. If you have two halves of a stick, each of them still has 2 ends.

Indeed and 59:54 still does not provide a natural number of pixels after expansion, but it's the standard and at least the sampling frequency is a finite number, so it's the closest there is.

I use both, Vegas for editing, and 128:117 for square pixel export in ffmpeg.

[Sharc]

Which camera manufacturers and which models? DVD camcorders?

DV camcorders. The issue has been discussed some time ago at videohelp.com with examples. I don't have the link ready. The conclusion was that earlier DV cameras sticked to Rec.601, while later models which allowed 16:9 and 4:3 takes used the full 720x576 frame for the active picture, adopting the "generic" pixel aspect ratio, actually violating Rec.601.

[lollo]

Theoretically, but they are different parts of the image, thus can only be reproduced as separate lines in digitised image, hence 576 lines total. If you have two halves of a stick, each of them still has 2 ends.

I told you that the half line topic was fascinating!

You are both rigth: the frame is built by 574 lines + 1/2 line on the top + 1/2 line on the bottom. But for the aspect ratio related aspects we consider that as 1, hence 575 lines.

And the 2 half lines are also the reason why we do not use 702, which is corresponding to 13.5 MHz * 52 usec, but 704: 702x575 upscaled to 576 lines gives 576 * 702 / 575 = 703.23, closer to 704 than 702

[SF01]

Which camera manufacturers and which models? DVD camcorders?

DV camcorders. The issue has been discussed some time ago at videohelp.com with examples. I don't have the link ready. The conclusion was that earlier DV cameras sticked to Rec.601, while later models which allowed 16:9 and 4:3 takes used the full 720x576 frame for the active picture, adopting the "generic" pixel aspect ratio.

I remember this topic, was it that conclusive though with model examples?

Earlier models also were using full 720 samples and yet still conformed to the 601.
What's more when analog signal was input it was processed accordingly with 601, so it's totally counterintuitive they would use 2 different methods for recording analog and digital signal. And using the incorrect standard would make them not backwards compatibler with analog displays and analog copies.

[SF01]

Theoretically, but they are different parts of the image, thus can only be reproduced as separate lines in digitised image, hence 576 lines total. If you have two halves of a stick, each of them still has 2 ends.

I told you that the half line topic was fascinating!

You are both rigth: the frame is built by 574 lines + 1/2 line on the top + 1/2 line on the bottom. But for the aspect ratio related aspects we consider that as 1, hence 575 lines.

And the 2 half lines are also the reason why we do not use 702, which is corresponding to 13.5 MHz * 52 usec, but 704: 702x575 upscaled to 576 lines gives 576 * 702 / 575 = 703.23, closer to 704 than 702

That actually makes sense.

[Sharc]

Earlier models also were using full 720 samples and yet still conformed to the 601.

Yes, just padding the left and right sides with picture material to fill the 720 width, causing additional confusion about the PAR actually used.

[SF01]

Earlier models also were using full 720 samples and yet still conformed to the 601.

Yes, just padding the left and right sides with picture material to fill the 720 width, causing additional confusion about the PAR actually used.

Instead of just using blanking. While there shouldn't e any confusion if people just knew about 601 and continued using it, just as it was in use on the analog-to-digital conversion of these camcorders.

[Sharc]

And the 2 half lines are also the reason why we do not use 702, which is corresponding to 13.5 MHz * 52 usec, but 704: 702x575 upscaled to 576 lines gives 576 * 702 / 575 = 703.23, closer to 704 than 702

Good point, yes, taking the upscaling from the 575 to the standard 576 into account. Circle closed

[SF01]

And the 2 half lines are also the reason why we do not use 702, which is corresponding to 13.5 MHz * 52 usec, but 704: 702x575 upscaled to 576 lines gives 576 * 702 / 575 = 703.23, closer to 704 than 702

Good point, yes, taking the upscaling from the 575 to the standard 576 into account. Circle closed

Well, if only DVD authoring companies could settle on one standard workflow, at least nowadays most if not all DVDs are released in the 16:15, or the corresponding 16:9 version without side blanking that the older DVDs had.

[lollo]

And the 2 half lines are also the reason why we do not use 702, which is corresponding to 13.5 MHz * 52 usec, but 704: 702x575 upscaled to 576 lines gives 576 * 702 / 575 = 703.23, closer to 704 than 702

Good point, yes, taking the upscaling from the 575 to the standard 576 into account. Circle closed

Not at all. Be sure than in a couple of days/weeks we'll come back on the subject

[SF01]

And the 2 half lines are also the reason why we do not use 702, which is corresponding to 13.5 MHz * 52 usec, but 704: 702x575 upscaled to 576 lines gives 576 * 702 / 575 = 703.23, closer to 704 than 702

Good point, yes, taking the upscaling from the 575 to the standard 576 into account. Circle closed

Not at all. Be sure than in a couple of days/weeks we'll come back on the subject

With a new user asking about it.
There should be a mandatory FAQ regarding DV to read when new users are registering with a quiz at the end asking "which is the correct way then".

[rgr]

And the same Vegas, when reading a file from a DV camera, claims that the PAR is 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 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.

[poisondeathray]

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

[SF01]

And the same Vegas, when reading a file from a DV camera, claims that the PAR is 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 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.

This is why I never do that, the only program for DV transfer from tape is ScenalyzerLive, this is not up for debate.
But I will look into the Vegas situation.