DirectShowSource() reliability problems for DV decoding in AviSynth().

[towtruck]

Hello

I used DirectShowSource() in a *.avs for frameserving to HCenc. The source file is a type-1 NTSC DV avi. After all was encoded, authored (GFD), and burned (ImgBurn) to DVD, I found that while the first of the 2 movies played fine (on TV), the second one hung up, that it, got to a certain point and began repeating about a 5 second cycle. The only cure was to re-encode the second movie using AviSource(). Both movies had only cut and paste editing and some titles inserted before each scene (WMM). The only difference that I can think of was that the movie in question started with a more dynamic title than the others (it hung up right about where it should have transitioned to the actual video).

The script looked pretty much like this:

AviSource("source.avi")

#Convert from RGB to YV12 colorspace.
ConvertToYV12()

Can anyone tell me what went wrong? Is DirectShowSource() simply unreliable??

I tried DirectShowSource() as opposed to AviSource because of a suggestion by Scott in a
previous thread (https://forum.videohelp.com/topic329440.html) that this would allow me to avoid the 'white-clip' problem of using the Panasonic Dv decoder with AviSource. (thanks for
enlightening me about that, edDV).

I have also tried the Canopus DV decoder (using Avisource(source.avi, fourcc="CDVC") ), but I
have found conflicting information regarding an apparent "chroma upsampling bug". If anyone can give me a definitive answer on that bug and how to get around it, I would appreciate that as well.

Thanks for everyones help. I am producing good DVD's, but that pesky German nature of mine
won't let me rest until its da*m near perfect.

[jagabo]

I don't know why AVISource() would cause white clipping where DirectShowSource() would not. Try adding Info() right after the xSource() line and look at the colorspace of the video. I suspect both will be YUY2.

The Panasonic DV Codec itself does not cause white clipping in VirtualDub. It outputs YUY2 to VirtualDub. ViritualDub then converts to RGB for filtering using the standard CCIR Rec.601 matrix -- that's where the clipping occurs. If you use VirtualDub in Fast Recompress mode (no filtering allowed of course) it will not convert to RGB and will pass the YUY2 video to the compression codec and no clipping will occur.

This is why it is preferable to perform your filtering in AVISynth. Most AVISynth filters will work in YUY2 or YV12 so you never have to convert to RGB. This prevents the white (and black) clipping problem as well as others.

The main difference between DirectShowSource() and AVISource() is who does the file parsing. DirectShowSource() will use Windows' DirectShow to parse the AVI file. AVISource() will use AVISynth's own AVI file parsing (code taken from VirtualDub).

[towtruck]

Thanks, Jugabo

My reason for trying DirectShowSource() was that then the MS DirectShow DV decoder would be used, which I had the impression did not have the white-clip problem.

No, AviSource itself would not cause white-clipping, but I do have the understanding that the Panasonic DV decoder, which would come into play, does. I hate to contradict you, especially as I really don't know what I'm talking about, but this is what I understand from the previously referenced thread.
https://forum.videohelp.com/topic329440.html
I've also seen similar information in other threads/articles relating to DV decoders. So now I really don't know what to think.

I tried your suggestion. When I used the Canopus decoder the colorspace was YUY2. Same for DirectShowSource(). However when I used the Panasonic decoder it was RGB24. I also found the FixBrokenChromaUpsampling() function on the AviSynth documentation. I understand that it compensates for, but does not 'fix' the bug. Maybe this is the way to go? The Canopus Codec has a Setting Group entitled "-YUV and RGB Conversions" with a checkbox entitled "Expand RGB range to 150%." I understand this tells the codec to map RGB to 16 black and 235 white instead of 0,255. However I wonder whether this is even relevant if I convert DV colorspace (YUV411) to YUY2 in the decoder to YV12 for HCenc & DVD without ever going through RGB? In any case, it seems from what you said that avoiding RGB is not a bad idea. Which leaves Canopus, as the MS decoder or something about DirectShowSource is unreliable. Then all I have to do is decide if the color bug and associated imperfect fix is less of an evil than the white clipping.

Maybe I just need to get less technical and burn a DVD with the same clip encoded both ways, and see which I like better, assuming I can even tell a difference.

Thanks again for all your help. This is good stuff!

[jagabo]

I tried your suggestion. When I used the Canopus decoder the colorspace was YUY2. Same for DirectShowSource(). However when I used the Panasonic decoder it was RGB24.

I was wrong about Panasonic DV codec. I think I figured out what's going on:

First, I was using a version of VirtualDub that has its internal DV decoder that decompresses to YUY2. So when I thought I was using Panasonic's decoder I was actually using VirtualDub's. When I used VirtualDubMod, based on an older version of VirtualDub without its own DV decoder, it used the Panasonic DV codec. Panasonic's DV decodery outputs RGB and clips blacks (Y<16) and whites (Y>235).

Second, I figured out why DirectShowSource() and AVISource() can give you different colorspaces. AVISource() is based on VirtualDub's AVI parser -- which is VFW based. DirectShowSource() obviosly uses DirectShow. So when you use AVISource() you end up using the Panasonic DV codec (which only uses VFW) which gives you RGB. When you use DirectShowSource() you are using Microsoft's DirectShow DV decoder (qdv.dll in your \Windows\System32 folder), or some other DirectShow DV decoder, which outputs YUY2.

As to your original problem I can only speculate that the DirectShow DV decoder simply got "stuck". Maybe there was a timecode break in the source?

[towtruck]

Thanks again.

That really makes sense now.

Interesting idea:

"As to your original problem I can only speculate that the DirectShow DV decoder simply got "stuck". Maybe there was a timecode break in the source?"

How can I check for that? Wouldn't a timecode break also give me a problem when using avisource() against DSSource()?