NTSC DV->NTSC DVD (4:1:1->4:2:0, Rec601->Rec709, PAR->PAR)

[jmac698]

What is the proper way to convert interlaced NTSC DV with 4:1:1 to 4:2:0?
I'm only in avisynth 2.58 right now but I think there's some chroma_placement commands in 2.6.

I think my steps would be,
-upscale chroma?
-fix chroma placement, dv->mpg yv12 ready
-deinterlace : does qtgmc support yuy2?
-converttoyv12

There'll also be some issues with which dv codec I'm using. I dunno what I'm using right now, I don't see an ffdshow video icon, but let's say I use ffms2, then does that decoder return the raw chroma without any smoothing?

Let's hope Gavino is around, I'm sure he'll have a very precise answer!

[jmac698]

I'm working with Avisynth2.6a3 now, and using ffms2 to open.

A = FFAudioSource(dir+fn)
V = FFVideoSource(dir+fn, resizer="POINT")#attempt to avoid touching chroma in 4:1:1 -> 4:2:2
AudioDub(V, A)
ConvertToYV411(chromaresample="point")#convert from YUY2->YV411
ConvertToYV12(ChromaOutPlacement="MPEG2", interlaced=true)#upsample from YV411->YV12
AssumeFPS("ntsc_video")#Fix incoming framerate
FFCOLOR_SPACE >= 5 ? ColorMatrix(mode="Rec.601->Rec.709", interlaced=true) : last#Change 601->709

[jmac698]

I've found out that I need a different build of FFMS2. The C version will properly export into Avisynth 2.6's YV411 colorspace.
That solves the first few lines.

[Wilbert]

Select the appropriate stuff in this decoder (YV12 mpeg2 as output): http://forum.doom9.org/showthread.php?t=94458

[jmac698]

That sounds good! Saves a lot of thought in the scripting, however I just realized there's still one more factor in simply opening a file; I have to set the proper resizing conversion. Do you happen to know the par of ntsc dv? Also the par for dvd compliant mpeg2. Their ratio should get me a resize to convert.

Things change a bit with the C version of ffms2:

plugindir="M:\Program Files\AviSynth 2.5\plugins\"
pluginfn="ffms2.dll"
loadcplugin(plugindir+pluginfn)
A = FFAudioSource(dir+fn)
V = FFVideoSource(dir+fn, resizer="POINT")#attempt to avoid touching chroma in 4:1:1 -> 4:2:2
AudioDub(V, A)
ConvertToYV12(ChromaOutPlacement="MPEG2", interlaced=true)#upsample from YV411->YV12
AssumeFPS("ntsc_video")#Fix incoming framerate
FFCOLOR_SPACE >= 5 ? ColorMatrix(mode="Rec.601->Rec.709", interlaced=true) : last#Change 601->709
#Now resize aspect of NTSC DV to aspect of NTSC MPEG2/DVD

[TheSkiller]

I have to set the proper resizing conversion. Do you happen to know the par of ntsc dv? Also the par for dvd compliant mpeg2. Their ratio should get me a resize to convert.The PAR of NTSC DV and a NTSC DVD is of course the same, 10/11 or 40/33. Why do you even think it would not be the same? :)
No resizing required. Also, DV is fixed to 720x480/576.

[TheFluff]

what in the name of the everloving christ are you even doing

your entire script can be reduced to
ffmpegsource2("derp.avi", colorspace="YV12", atrack=-1)

ntsc on dv has the exact same semantics as ntsc on dvd, there's no need to convert anything whatsoever except downsampling the chroma vertically, and ffms2 will do that internally via libswscale.

dv has the same chroma siting as mpeg2 does (left) so there's absolutely nothing to hurf a durf about there either.

and why are you trying to change the color matrix from rec.601 to rec.709?

[jmac698]

Thanks for the suggestion.

My references disagree with you on the differences between the two formats. At least one of your statements is incorrect. Can you provide alternative references?

DV: https://en.wikipedia.org/wiki/Dv#DV_Compression
States that Rec.601 is used.

MPEG-2/DVD: http://avisynth.org/mediawiki/Colorimetry#DVD.2FMPEG-2
States that Rec.709 is used, without further specification.

I also had to verify that both use BFF.

The PAR is not the same. This practical test of actual equipment, showed defacto values of 8/9 and 10/11:
http://renomath.org/video/linux/aspect/
This reference also agrees with the 10/11 figure:
https://en.wikipedia.org/wiki/Pixel_aspect_ratio

This reference shows them the same in the standards, but a different value:
http://lipas.uwasa.fi/~f76998/video/conversion/

You also want to upsample the chroma, for better quality and also for chroma keying. A test of an upsampling algorithm, Nicer G, is shown here at the bottom:
http://www.nattress.com/Chroma_Investigation/chromasampling.htm

For this reason I prefer to keep control within the Avisynth script.

Also, I've seen reports of bugs in swscale.
http://devel.mplayer2.org/ticket/140
http://www.cccp-project.net/forums/index.php?topic=5852.30
Though I don't think applies here, but I haven't thoroughly tracked down the reports.

[mp3dom]

DV is generally BFF while DVD is generally TFF. However this is only a matter of flags and field order. You can have DVD encoded as BFF, and the playback is just fine. About the Rec used... Rec.709 was standardized for HiDef formats. Rec.601 is used for StdDef formats. MPEG-2 encoders almost always leaves blank the color information in sequence_display_extension, so the colorimetry can almost be anything but in those case Rec.601 (or ITU-R BT.470-2) is assumed for SD, and Rec.709 for HD.

[Ghitulescu]

There is a whole debate concerning the PAR of DV (both NTSC and PAL) somewhere here in this forum. Part of it derives from the actual image size which is 704x576/480 and padded with 16 black pixels to 720. Anyway, regardless of PAR, the differences/errors are small, smaller than one can notice without test patterns (sort of ITU vs non-ITU controversy). Like with DVD recorders, one should also double-check the camcorder, to see whether those 16 pixels are added (so one crops them then resizes to 720) or just blacked.
And the colorimetry is 601. It was never 709. I think that even HDV is 601 (or at least some implementations thereof).
A bit of experimentation is required.

[TheSkiller]

jmac698, this whole ITU vs. non-ITU PAR debate (or in numbers: 10/11 vs. 8/9) is a different question. It does not change the fact that both DV and DVD share the same sampling characteristics in terms of aspect ratio. At least, it wouldn't make sense if you assume ITU for one and non-ITU for the other.
Both formats were invented to store video that is compatible with analog SD. So maybe if you look at it from that point of view, it is a natural conclusion that both are essentially the same, the only real difference is the codec, DV vs MPEG2 and the color subsampling. Both use Rec.601 color coefficients. DV is always BFF, DVD can be either.


As a side note, a DV video recorded with a plain SD DV camcorder is very likely to be ITU compliant, 10/11. Also it is very likely that all 720 pixels are filled with active picture, this is simply because there's no need for the camcorder to cut off the excess pixels as for storage in DV the frame is forced to be 720 pixels wide anyway. If you play that back via the camcorders analog outputs the excess pixels will be blanked in the analog signal. The only DV camcorder I know of that doesn't record 720 active pixels to DV is the Sony DCR-VX1000 from 1995.

[2Bdecided]

one should also double-check the camcorder, to see whether those 16 pixels are added (so one crops them then resizes to 720)You wouldn't seriously do that, would you?! I wouldn't! resizing 704 to 720 by resampling is the strangest thing I can think of.

Not that it's needed (NOTHING is needed here - just use Cedocida's output with MPEG-DVD YV12 chroma sampling selected, and you're set), but even if something was "needed", I wouldn't rescale SD like that.

Cheers,
David.

[jmac698]

I checked a commercial DVD and it was BFF and SMPTE 170M.

I'll accept that dv/dvd are the same aspect. Also that dv is 601 and bff. The dvd authoring application I'm using is setting colorimetry to bt-470, this is the same as rec601.

I take it the field order of the source should match the destination, as long as it's in order, say as from separatefields?
Does ffms2 do proper conversion from 4:1:1 to interlaced 4:2:0?

[TheFluff]

My references disagree with you on the differences between the two formats. At least one of your statements is incorrect. Can you provide alternative references?

"The internet" is not a reference and I would appreciate it if you would stop thinking everything you read there is true. Also, you're wildly misinterpreting or misunderstanding half of your "references".

MPEG-2/DVD: http://avisynth.org/mediawiki/Colorimetry#DVD.2FMPEG-2
States that Rec.709 is used, without further specification.
Incorrect. It states that if no metadata is present, rec.709 should be assumed. But it's irrelevant, because it's the MPEG2 specification and not the DVD specification, nor the NTSC specification. NTSC DVD's follow the rules of NTSC, and that means Rec. 601, just as all other analog-based SDTV.

The PAR is not the same. This practical test of actual equipment, showed defacto values of 8/9 and 10/11:
http://renomath.org/video/linux/aspect/
that test is completely retarded and wrong and must be disregarded; it seems neither the tester nor you understand what PAR means

This reference shows them the same in the standards, but a different value:
http://lipas.uwasa.fi/~f76998/video/conversion/
this source is correct, but can be hard to interpret.

You also want to upsample the chroma, for better quality and also for chroma keying. A test of an upsampling algorithm, Nicer G, is shown here at the bottom:
http://www.nattress.com/Chroma_Investigation/chromasampling.htm
converting 4:1:1 to 4:2:0 by definition means downscaling the chroma. you have control over which scaling algorithm should be used to do that if you use ffms2, but not if you use converttoyv12() like you did in your script, so I really don't your point.

Also, I've seen reports of bugs in swscale.
http://devel.mplayer2.org/ticket/140
http://www.cccp-project.net/forums/index.php?topic=5852.30
Though I don't think applies here, but I haven't thoroughly tracked down the reports.
OFFICER! THERE ARE BUGS IN THIS SOFTWARE! ARREST IT AT ONCE!

Seriously, this paragraph is so stupid I don't even know where to begin. The first bug report isn't even a report about bugs in swscale, it's someone complaining that mplayer isn't using the correct swscale settings. The second link goes to a forum thread from over a year ago where people discuss various 10-bit resizing issues (i.e. not relevant to this at all) that have since been fixed.

I have absolutely no idea why you would bring this up, other than to try to create a smokescreen of links nobody is going to click. None of the reports are even remotely related to the topic we're discussing. All software has bugs, and you pointing to this obvious fact as some kind of argument in favor of I-don't-even-know-what really doesn't win you any points at all.

[jmac698]

I'm satisfied that your original suggestion is correct. I apologize if i didn't believe it at first, but it's because I agree with you - you can't trust everything you see on the internet. It does take a lot of research. Please don't take it personally if I disagree with you from time to time, I will eventually reach my own conclusion.

As for the swscale, I did recall reading about some kind of problem with it, which was enough for me to investigate the issue. I admitted that I didn't have time to investigate it thoroughly. I didn't offer those links as proof; my intention was to do a brain-dump of things to follow-up upon. What I've received, and was hoping for, was some kind of reassurance that the issue wouldn't affect my application.

Thanks for your input.

[Ghitulescu]

jmac698, this whole ITU vs. non-ITU PAR debate (or in numbers: 10/11 vs. 8/9) is a different question. It does not change the fact that both DV and DVD share the same sampling characteristics in terms of aspect ratio. At least, it wouldn't make sense if you assume ITU for one and non-ITU for the other.
Both formats were invented to store video that is compatible with analog SD. So maybe if you look at it from that point of view, it is a natural conclusion that both are essentially the same, the only real difference is the codec, DV vs MPEG2 and the color subsampling. Both use Rec.601 color coefficients. DV is always BFF, DVD can be either.


As a side note, a DV video recorded with a plain SD DV camcorder is very likely to be ITU compliant, 10/11. Also it is very likely that all 720 pixels are filled with active picture, this is simply because there's no need for the camcorder to cut off the excess pixels as for storage in DV the frame is forced to be 720 pixels wide anyway. If you play that back via the camcorders analog outputs the excess pixels will be blanked in the analog signal. The only DV camcorder I know of that doesn't record 720 active pixels to DV is the Sony DCR-VX1000 from 1995.

None of my camcorders, of all major manufacturers (JVC, Sony, Canon, Panasonic and Sharp), provides a full 720 active pixels per line, all of them have only non-black 704 pixels.

You wouldn't seriously do that, would you?! I wouldn't! resizing 704 to 720 by resampling is the strangest thing I can think of.

I wouldn't rescale SD like that.

I never saw myself a difference in PAR between the original DV and the resulted DVD (PC or DVD-recorders) on my TVs - I did not crop myself the 16 pixels as I didn't care because they are anyway covered by the overscan, but people kept saying there is one. The only difference could only be the active (non-black) pixels, as all other parameters are identical.

[TheSkiller]

None of my camcorders, of all major manufacturers (JVC, Sony, Canon, Panasonic and Sharp), provides a full 720 active pixels per line, all of them have only non-black 704 pixels.Odd, are we talking about the same thing: consumer SD MiniDV camcorders that record to MiniDV tape, transferred to the computer via firewire to DV AVI?

Also by "non-black 704 pixels" you mean they record a 704 pixels active image to DV tape with about 8 black pixels at each side?


I mean not that it really matters, but oh well, I'd like to know. :)

[Ghitulescu]

Also by "non-black 704 pixels" you mean they record a 704 pixels active image to DV tape with about 8 black pixels at each side?

My Sharp has them grouped at one side (I think at the right), I stopped using it in 2007. I don't recall the others because I stopped using DV some years ago, but I may try to see when I'll have some time. Why I remember this? because I stumbled upon the same information, about a possible different PAR value for DV, and the Sharp was my first DV-camcorder.

That was actually the point, I did not notice whether the image consisted of 720 pixels from which 16 pixels have been blacked out, or the whole CCD line has been fit into 704 pixels and 16 black ones have been added to fill in 720. It's anyway a ~2% error, so I safely ignored it and passed the whole frame to encoders.

[TheSkiller]

OK, but consider that many camcorders have so many pixels on their CCD(s) that they use only a smaller centered area from the CCD for the actual image they record. Some use this to stabilize the picture electronically. Anyway, what I'm trying to say is, if you imagine the camcorder takes the video frame it records from a smaller window of all the CCD pixels available, it seems natural that all 720 pixels will carry picture unless there is some mechanism that blanks these "excess pixels" on purpose afterwards.


Actually some time ago I did record a square sheet of paper frontal with one of my camcorders (with all 720 pixels appearing to carry picture) and as expected, I had to stretch the 720x576 DV image ITU compliant to 786x576 to make the square sheet of paper appear as a square (or alternatively crop to 704 first and then resize to 768). :)

[Ghitulescu]

OK, but consider that many camcorders have so many pixels on their CCD(s) that they use only a smaller centered area from the CCD for the actual image they record. Some use this to stabilize the picture electronically.

That's correct, so does my Sharp.

[jmac698]

I've noticed (for example when browsing www.dpreview.com), that the sensor pixel dimensions are always bigger than the highest resolution picture you can take. They may be reserved for brightness or focus measurements, but it seems standard.

I"ve thought about filming a square object. There's some assumptions here though, because of lens distortion. If you center the image, you're assuming that the disortion is centered with respect to the middle of the image sensor, and that the distortion is equal radially.

There is a model for lens distortion that's quite successful, and a lens calibration is the best way to determine aspect.

This is usually done by filming a checkerboard. The results can be accurate to the subpixel level. You should also be able to apply the technique to determine the aspect created by TV's and DVD players. In this case, most parameters will be 0/1 as appropriate as there's no distortion, but just an aspect ratio.

There's one case for distortion; pseudo-widescreen modes, where a 4:3 image is non-linearly stretched to be widescreen. The formula used for this type of distortion may not work with the formula used in the lens distortion model, so you may not be able to measure it directly this way.

I'd like to try this experiment sometime.

[jmac698]

Ok,
I'm having a bunch of problems.
FFMS2 is crashing.
Edit:
Posted to ffms thread.

[TheSkiller]

There's one case for distortion; pseudo-widescreen modes, where a 4:3 image is non-linearly stretched to be widescreen. The formula used for this type of distortion may not work with the formula used in the lens distortion model, so you may not be able to measure it directly this way.Such non-linear modes are for TVs only, it's sort of an attempt to fill a 16:9 screen with a 4:3 picture by leaving the center almost untouched and stretching the sides strongly.
Camcorders don't do this (I'm very sure about this). Any distortions are caused by the lens and those are usually very small, not worth bothering. Nobody will ever see them unless you record a wall with a checkerboard pattern frontally.

Camcorders that do not have suitable sensors for full resolution 16:9 video which yet still have a 16:9 record option simply crop the picture's top and bottom and stretch it back. It's therefore a bad thing to do and will result in inferior video quality.

[jmac698]

I agree, and it wasn't clear in my writing that I was referring to TV's. Also, by filming a checkerboard, I didn't mean to just count pixels by hand or something, there's a program that does this computation, and they use a checkboard because there's a an automated algorithm (Harris Corner Detector) to do subpixel registration on two lines joining.

I wish I had an old camcorder to try this method, I do have a calibrator program downloaded now.