VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or try DVDFab Passkey and copy Blu-ray and DVDs! :)
+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 48 of 48
Thread
  1. It worked for me when I used ConvertToXX for YV16, YUY2 (compare the same either YV16 vs. YV16 or YUY2 vs. YUY2 within avisynth) . I verified with other tests outside avisynth too , and all 3 ffms2 , lsmash, avisource (with drastic) matched up. I never tested directshow

    Maybe something different with your test video ?
    Quote Quote  
  2. e.g

    Code:
    A=AVISource("UYVY.avi",pixel_type="YUY2")
    
    F=FFVideoSource("UYVY.avi").ConvertToYUY2()
    L=LWLibavVideoSource("UYVY.avi", format="YUV422P8").ConvertToYUY2()
    
    Overlay(F,L, mode="Difference", pc_range=true)
    #Overlay(A,L, mode="Difference", pc_range=true)
    #Overlay(A,F, mode="Difference", pc_range=true)
    Levels(127, 1, 129, 0, 255, false)
    And I just change the F,L,A in the overlay to compare , or remove the ConvertToYUY2() if comparing as YV16 (and adding ConvertToYV16 to the AviSource line) . Basically compare YV16 to YV16 ; or YUY2 to YUY2 .

    I think that's the difference you're seeing

    My understanding is planar is preferred to packed, and faster to process . So all newer plugins, filters tend to output planar by default .

    It might be .dll version related too - Maybe some behaviour differences
    Quote Quote  
  3. I can see the 1 value off by lsmash , in default mode, when you do not specify format = "YUV422P8" . Even though it's supposed to be returning YUY2 when you don't specify format, the values are off . Not sure why, but it's definitely wrong looking at Y,U,V color picker
    Quote Quote  
  4. The problem with LWlibavVideoSource appears to be its YUY2 output:
    Code:
    LWlibavVideoSource("8-bit uncompressed 422 UYVY .avi", format="YUY2")
    LWlibavVideoSource("8-bit uncompressed 422 UYVY .avi", format="YUV422P8").ConvertToYUY2()
    These two lines give different results. The former gives the problems I described earlier, the latter doesn't. So this appears to be a bug on the part of LSMASH. <edit> I see we've cross posted and you've come to the same conclusion </edit>

    I notice I made a mistake in post #30 (I've corrected the post). I specified colorspace="YUY2" in ffVideoSource() but neglected to include that in the posted script (I think I copied/pasted/changed the LSMASH script when I posted). The actual source command I used was:
    Code:
    ffVideoSource("8-bit uncompressed 422 UYVY .avi", colorspace="YUY2")
    And your
    Code:
    ffVideoSource("8-bit uncompressed 422 UYVY .avi").ConvertToYUY2()
    continues to give the same problem: the very first frame is wrong (all green) upon opening the AVS script in VirtualDub. I've done this with both 32 bit AviSynth with VirtualDub 2, and 64 bit AviSynth with VirtualDub64.
    Quote Quote  
  5. Is "8-bit uncompressed 422 UYVY .avi" his video in post #15 ?

    I can't even open it with the ffms2 I had - access violation . It looks like a ffms2 version issue here. But lsmash and avisource (drastic) matched with the script I posted above . I'll play with some other ffms2 versions
    Quote Quote  
  6. I was debugging another problem and I forgot to swap . Everything matches here now with the compare script I posted above, on all frames, including ffms2 for his video in post #15

    ffms2 is version hell incarnate. Some might have some codecs/decoders missing, but others have and vice-versa. Some of them have several libraries missing, some some things differently , it's a mess. I always keep like 6 versions on each computer so I have easy access to swap

    One frame wrong seems weird . Maybe download issue ? If you can't debug it, can you stream copy that frame, zip it up, upload it and I'll see if I get the same ?
    Quote Quote  
  7. Yes, the video I was testing with was the one in post #15. I downloaded the file again and did a binary compare -- exactly the same. I get the same empty first frame with ffVideoSource() -- opening the script with VirtualDub and the x264 CLI encoder. I hardly ever use ffms2 anymore and I don't normally deal with uncompressed UYVY. So I'm not going to bother pursuing this.
    Quote Quote  
  8. I suspect it's a ffms2.dll version issue , just like I had an access violation error with another ffms2 version

    For completeness, the ffms2 version I'm using is FFMS2 C-plugin 1327+119 . It's the most recent of all ffms2 branches, and even has AV1 support .

    https://forum.doom9.org/showthread.php?p=1829061#post1829061
    Quote Quote  
  9. I tried that version of ffmes -- the blank first frame problem has gone away. All three videos match though I still have to use format="YUV422P8" and ConvertToYUY2() workaround with LWlibavVideoSource().
    Quote Quote  
  10. Originally Posted by clashradio View Post
    I downloaded AVISynth & VirtualDub (both 32-bit) and did a very simple test which worked and I was able to play the file in VirtualDub (see script below).

    AVISource("raw YUV 8-bit uncompressed.avi")

    So for another easy test I wanted to remove the 3:2 pull-down and get back to 23.97fps (original source is 24fps film on NTSC laserdisc 29.97fps) (see script below).

    AviSource("YUV 8-bit uncompressed LFF.avi")
    TFM()
    TDecimate()

    I get an error message of:

    AVIsynth open failure:
    TFM: YV12 and YUY2 data only! Pinterest Tumblr imo
    (Z:\laserdisc capture tests\raw tests\703\THX 1138 test.AVS, line 2)

    Sure, this file is YUV, but so was that first one I tested with and that opened & played fine.

    I downloaded: avisynth.nl/index.php/TIVTC & dragged it into the AVISynth plug-in folder.
    That new content worked! In any case, shouldn't the left-see be the crude and right-see prepared? I don't perceive any join issues with the left picture.
    Last edited by firarottico; 12th Oct 2018 at 12:52.
    Quote Quote  
  11. Originally Posted by firarottico View Post
    In any case, shouldn't the left-see be the crude and right-see prepared?
    AviSynth processes the video before VirtualDub sees it. So both windows in VirtualDub will look the same unless you use VirtualDub's filtering.
    Quote Quote  
  12. Member
    Join Date
    Nov 2006
    Location
    United States
    Search Comp PM
    I'm going to try Osprey's 827e pci/e card which will work with VirtualDub for capturing. Now maybe I can capture at YUY2.

    poisondeathray: Just curious; You mentioned it's converted to RGB in order to view in VirtualDub. If I'm not previewing anything in VirtualDub, just opening the AVS script and letting AVISynth work its magic, does that RBG conversion process still have to happen?
    Quote Quote  
  13. Everything you see on the screen is RGB. If you are using VirtualDub to view the results of your script VirtualDub is converting the YVU video to RGB (only for the display, not necessarily for filtering or encoding).
    Quote Quote  
  14. Member
    Join Date
    May 2014
    Location
    Memphis TN, US
    Search PM
    If you are viewing the output of an avs script in VirtualDub and using VDub's "full processing mode", the video output is converted by default to uncompressed RGB when you save the new AVI. Most of the time, most users save intermediate AVI working files as lossless compression, not as uncompressed. To prevent an unwanted RGB conversion, click "Video.." -> "color depth...." and set the colorspace you want for output. Then click "Video..."-> "compression..." and set the compression you want for output. Click "Video" again, scroll down the VDub dropdown menu, and select "fast recompress". Then save your Avisynth output to a new AVI.

    If you are applying VirtualDub filters to the output of an Avisynth script, your only choice for VDub's mode is "full processing mode". Otherwise, your VDub filters won't be applied. But you can always save your output as any other colorspace and compressor. I usually save a final-stage Avisynth output as lossless Lagarith YV12, since the next step would be MPEG or h.264 encoding. Your work flow might differ.
    - My sister Ann's brother
    Quote Quote  
  15. Originally Posted by LMotlow View Post
    If you are viewing the output of an avs script in VirtualDub and using VDub's "full processing mode", the video output is converted by default to uncompressed RGB when you save the new AVI.
    That behavior changed several years ago. VirtualDub in full processing mode now only converts to RGB when actually filtering. And even then only if using a filter that doesn't support the incoming color format.

    Click image for larger version

Name:	filtering.jpg
Views:	10
Size:	90.4 KB
ID:	46889

    If it receives YUY2 from an AviSynth script and you save as uncompressed you will get uncompressed YUY2 in the AVI file. If you select a compression codec that supports the YUY2 that's what the codec gets. It's the same for YV12.
    Quote Quote  
  16. Member
    Join Date
    May 2014
    Location
    Memphis TN, US
    Search PM
    Changed when? To what? Not in VirtualDub 1.9.1.1. The default is uncompressed RGB24. If you changed the default the changes stay as-is forever until you change them again. If you changed the default to "same as decompression format", that isn't the default when VirtualDub is first installed. And I think you encountered this same discussion earlier in this forum with sanlyn.

    If you're using another version of VirtualDub, what are the installed defaults?
    - My sister Ann's brother
    Quote Quote  
  17. Originally Posted by LMotlow View Post
    Changed when? To what? Not in VirtualDub 1.9.1.1. The default is uncompressed RGB24. If you changed the default the changes stay as-is forever until you change them again. If you changed the default to "same as decompression format", that isn't the default when VirtualDub is first installed. And I think you encountered this same discussion earlier in this forum with sanlyn.
    Maybe you are right. I'm using VirtualDub 1.10.4. Video -> Color Depth -> Decompression format is set to Autoselect. Output format is set to Same As Decompression Format. I don't remember if those are the defaults.
    Quote Quote  
  18. Member
    Join Date
    May 2014
    Location
    Memphis TN, US
    Search PM
    I tried 1.10.4 but found it buggy in some respects so didn't keep it long enough to notice the defaults.
    - My sister Ann's brother
    Quote Quote  



Similar Threads