VideoHelp Forum


Try NordVPN to access Netflix or other streaming services from any country and also surf safe!
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 35
Thread
  1. Am I losing much quality converting video:
    from YUV420 to YUV420P16
    and
    from RGB(some numbers) to YUV(some numbers)?
    Converting because have no other option than one proposed by h.264.
    Thanks.
    Quote Quote  
  2. There should be no losses with YUV420 to YUV420P16. What are you using to convert? What are you using to view the results?

    8 bit (per channel) RGB to 8 bit (per channel) YUV will lose a lot of precision. Because 8 bit limited range YUV has only about 1/6 as many colors that map to valid RGB values. So yes, you expect losses there -- smooth gradients will become posterized.
    Last edited by jagabo; 22nd May 2021 at 11:32.
    Quote Quote  
  3. You naturally will lose information when lowering the color sampling or bit depth (assuming there is information to lose).
    you might want to read https://en.wikipedia.org/wiki/Chroma_subsampling to understand what the sampling numbers in YUV mean,...
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  4. Originally Posted by jagabo View Post
    What are you using to convert? What are you using to view the results?
    Using VirtualDub2 h.264 for convert, VLC or MC(something) to view.
    Quote Quote  
  5. What are you doing in VirtualDub2? What codec are you saving with? You should upload a small sample of your source and the encoded video. So we can see the problem.
    Quote Quote  
  6. Originally Posted by jagabo View Post
    What are you doing in VirtualDub2? What codec are you saving with? You should upload a small sample of your source and the encoded video. So we can see the problem.
    Using AviSynth through VirtualDub, running some scripts, saving with h.264. Original was 8bit, I'm saving 10bit. There's no big issue with THIS process, there will be a question with another one.
    Last edited by taigi; 22nd May 2021 at 19:57.
    Quote Quote  
  7. Originally Posted by taigi View Post
    Using AviSynth through VirtualDub, running some scripts, saving with h.264. Original was 8bit, I'm saving 10bit. There's no big issue with THIS process, there will be a question with another one.
    Then why aren't you providing information about the process with the problem? How is anybody going to help you if you don't provide the right information?
    Quote Quote  
  8. yes, as was said, changing bitdepth should do nothing, IF there was no processing in between or something, look at some green YUV values for example and their rgb preview values, they are the same except rounding errors, YUV420P8 is changed to YUV420P16:
    Image Attached Thumbnails Click image for larger version

Name:	YUV420P8.PNG
Views:	17
Size:	40.9 KB
ID:	59078  

    Click image for larger version

Name:	YUV420P8 to YUV420P16.PNG
Views:	11
Size:	37.0 KB
ID:	59079  

    Quote Quote  
  9. Another process converts video from 8bit to 10bit, from RGBA32 to YUV420P16.
    Am I losing much this way?
    Converting to have some scripts used. AS through VD2, to h.264.
    Thanks.

    Originally Posted by jagabo View Post
    Then why aren't you providing information about the process with the problem?
    Because I have two of them running that are connected with this question.
    Last edited by taigi; 22nd May 2021 at 21:53.
    Quote Quote  
  10. --
    Last edited by taigi; 22nd May 2021 at 21:53.
    Quote Quote  
  11. Originally Posted by taigi View Post
    Another process converts video from 8bit to 10bit, from RGBA32 to YUV420P16.
    Am I losing much this way?
    P16 is 16bit not 10bit
    Not sure if it hurts an image, RGB cube is entirely within YUV cube. As long you do not convert down again to 8bit YUV. Rounding errors apply. But I assume you change syntax to 10bit (P10). Also not sure how you got that RGB in the first place. If from YUV then it is not optimal.

    You can compare 8bit PNGs made from RGB 8bit and converted YUV420P16:
    Image Attached Thumbnails Click image for larger version

Name:	RGB24.PNG
Views:	14
Size:	30.5 KB
ID:	59082  

    Click image for larger version

Name:	YUV420P16.PNG
Views:	11
Size:	31.9 KB
ID:	59083  

    Quote Quote  
  12. Those difference are probably due to the way the YUV data was converted to RGB to make the images. If you convert the 16 bit YUV back to 8 bit YUV you'll probably exactly the same values back.
    Quote Quote  
  13. Originally Posted by _Al_ View Post
    P16 is 16bit not 10bit:
    I mean Bit depth - converting from 8 bits to 10 bit. Not sure is this gonna affect color questions.
    Quote Quote  
  14. RGBA32 to YUV420P16
    the conversion from 8bit to a higher bit depth should not cause information loss.
    When going from RGBA to YUV obviously, you will lose the complete alpha channel.
    When going from RGB to 4:2:0 you also lose information due to the sampling. Read the link I posted before.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  15. Can conversion from 8bit to 10bit compensate RGBA32 to YUV420P16?
    Quote Quote  
  16. Can conversion from 8bit to 10bit compensate RGBA32 to YUV420P16?
    "RGBA32 to YUV420P16" is a conversion from 8bit RGB+Alpha to 16bit YUV 4:2:0.
    Additional precision (8->16) has nothing to do with the alpha channel or the color sampling.
    And instead of using 16bit using 10bit will not change anything regarding the alpha channel or the color sampling either.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  17. I am doing this because I'm fighting overly dark footage with this great script provided by themaster1:

    Code:
    AVISource("snippetOfDark.avi")
    hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadow s=true,corrector=0.8,reducer=1.6)
    ConvertToYV16(interlaced=true)
    SpotLessUV()
    ConverttoRGB32(matrix="rec709",interlaced=false)

    Is it logical what I do?
    Video original: https://forum.videohelp.com/attachments/58884-1621050046/snippetOfDark.avi
    Quote Quote  
  18. That file uses 10bit 4:2:0 and is progressive.
    Looking at the script,..

    Code:
    AVISource("snippetOfDark.avi")
    Not sure why you would use AviSource, personally I would use:
    Code:
    LWLibavVideoSource("snippetOfDark.avi",cache=false,format="YUV420P16", prefer_hw=0)
    to avoid the dependency to vfw decoders.

    Code:
    hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadows=true,corrector=0.8,reducer=1.6)
    changes the color, okay.

    Code:
    ConvertToYV16(interlaced=true) <- Makes no sense to me at all.
    a. why use interlaced = true when your source is progressive?
    b. why convert to YV16 to begin with, SpotLessUV works fine on YV12 content

    Code:
    ConverttoRGB32(matrix="rec709",interlaced=false)
    Why convert to RGB32 ? Why convert to RGB and why add an empty alpha channel?

    -> Assuming that is the whole script, the whole color conversion make no sense to me.
    So I would answer "Is it logical what I do?" with "No, not to me."


    Cu Selur
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  19. Thanks, good analysis.
    Quote Quote  
  20. Originally Posted by taigi View Post
    I mean Bit depth
    10bit is bit depth P8 is 8bit, P10 is 10 bit, P16 is 16bits vapoursynth marks it that way even 8bit video for example YUV420P8. Avisytnh just uses YV12 but you do not know how many bits it is, it is assumed 8bit, because that what Avisynth is using. YV16 is 422 subsampling but not necessarily 16 bits, it could be 8 to 16 bits. Latest Avisynth+ , that should be used by now I guess instead of older Avisynth, picks up new format explicitly mentioning subpsampling and bitdepth, but not for all, old YV12 stays I guess, it is wide spread in scripts, so back compatibility must be preserved.

    Comparison of Avisynth, Avisynth+ and Vapoursynth formats where you can find what bitdepth it has is here:
    http://avisynth.nl/index.php/VapourSource
    Quote Quote  
  21. @Selur exactly now fighting to install LWLibavVideoSource.
    Any help of what driver I would need?
    Went through finding/installing libvlccore.dll, libavcodec_plugin.dll...
    Still "There is no function named "LWLibavVideoSource".
    Running this one on 32 system.
    Thank you.
    Last edited by taigi; 23rd May 2021 at 19:03.
    Quote Quote  
  22. Originally Posted by jagabo View Post
    Already have this one, the error message is still the same.
    Quote Quote  
  23. Originally Posted by taigi View Post
    Originally Posted by jagabo View Post
    Already have this one, the error message is still the same.
    You probably installed the wrong one (64 bit vs. 32 bit). Try loading it manually -- you will get an error message telling you what's wrong.

    Code:
    LoadPlugin("C:\Path\to\LSMASHSource.dll")
    Quote Quote  
  24. Originally Posted by jagabo View Post
    Code:
    LoadPlugin("C:\Path\to\LSMASHSource.dll")
    Now error message reads: "Platform returned code 127"
    Quote Quote  
  25. Post your entire script.
    Quote Quote  
  26. Script would be like this:

    FFmpegSource2("00014.MTS", atrack=1)
    hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadow s=true,corrector=0.8,reducer=1.6)
    SpotLessUV()
    Quote Quote  
  27. Why are you posting a script using FFmpegSource2 when you said you were trying to use LWlibavVideoSource?
    Quote Quote  
  28. Sorry. This one:

    LWLibavVideoSource("00014.MTS",cache=false,format= "YUV420P16",prefer_hw=0)
    hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadow s=true,corrector=0.8,reducer=1.6)
    SpotLessUV()
    Quote Quote  
  29. Why aren't you loading the dll file as I suggested? What program are you using to open the AVS script? 32 bit or 64 bit? Try using VirtualDub2. It will probably give you more informative error messages.
    Quote Quote  



Similar Threads