VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 2 of 3
FirstFirst 1 2 3 LastLast
Results 31 to 60 of 67
Thread
  1. I can't open your .raw or .avs files in a video player in Windows 10 (SMPlayer or VLC).

    Tried renaming .avs as .avi, nothing.
    Quote Quote  
  2. Originally Posted by chris319 View Post
    I can't open your .raw or .avs files in a video player in Windows 10 (SMPlayer or VLC).
    Of course not. It's raw 8 bit YUY2 samples (the first frame of your sample video). There's no header to tell a media player what's in it. The AviSynth script can read it. The C program I provided can read it and convert it to raw Y8 data.
    Quote Quote  
  3. Gimp isn't reading the .raw file created by your program.

    What exactly are we trying to accomplish here?
    Quote Quote  
  4. I don't know about Gimp but most image editors let you import raw image data (I'm not talking about raw Beyer data from cameras but RGB or greyscale data in a binary file). You select the file, tell it the data format (8 bit greyscale), the frame dimensions (1280x720), and any header data to skip (0).
    Quote Quote  
  5. Whenever you have "rawvideo", you have to tell the recieving program what it is in terms of pixel format, dimensions, framerate

    Your program is expecting something different , so you need to either adjust your program, or place some conversion filter inbetween the output of utvideo decoder, and your program input.

    For example, if you wanted to "play" jagabo's 1280x720yuy2.raw with ffmpeg/ffplay .

    Code:
    ffplay -f rawvideo -video_size 1280x720 -pixel_format yuyv422 -framerate 59.94 -i 1280x720yuy2.raw
    Notice those parameters are specified as input options
    Quote Quote  
  6. I opened it with my "scope" program and I got a screen full of black.

    Windows Movie Maker opened it; screen full of black.
    Quote Quote  
  7. Originally Posted by chris319 View Post
    I opened it with my "scope" program and I got a screen full of black.

    Windows Movie Maker opened it; screen full of black.
    Because you didn't "tell" them what you have.

    Rawvideo has no identifying information . Absolutely no headers, no ID. Whereas yuv4mpeg specifies those things in the header, so the receiving program can parse that info
    Quote Quote  
  8. Originally Posted by poisondeathray View Post
    Whenever you have "rawvideo", you have to tell the recieving program what it is in terms of pixel format, dimensions, framerate

    Your program is expecting something different , so you need to either adjust your program, or place some conversion filter inbetween the output of utvideo decoder, and your program input.

    For example, if you wanted to "play" jagabo's 1280x720yuy2.raw with ffmpeg/ffplay .

    Code:
    ffplay -f rawvideo -video_size 1280x720 -pixel_format yuyv422 -framerate 59.94 -i 1280x720yuy2.raw
    Notice those parameters are specified as input options
    I take care of that in my "scope" program and get a screen full of black:

    Code:
    pipeIn$ = "-i " + filename$ + " -f image2pipe  -s 1280x720  -pix_fmt yuv422p  -r 59.94  -vf zscale=in_range=limited:out_range=limited  -vcodec rawvideo -"
    Quote Quote  
  9. Originally Posted by chris319 View Post

    I take care of that in my "scope" program and get a screen full of black:

    Code:
    pipeIn$ = "-i " + filename$ + " -f image2pipe  -s 1280x720  -pix_fmt yuv422p  -r 59.94  -vf zscale=in_range=limited:out_range=limited  -vcodec rawvideo -"
    In ffmpeg/ffplay you need to specify those parameters as input options. This means before the "-i" . The order matters. -f rawvideo as an input option too. Otherwise you're telling ffmpeg to convert to something else . Instead of telling it "this is what the input is"

    Also try taking out -vf zscale . Reduce it to the simplest before adding back things when debugging
    Quote Quote  
  10. The goal here isn't to make it play back in ffmpeg or ffplay; it's to get my program to reconstruct images properly which my 4:2:0 program does quite well when the pixels are 4:2:0.
    Quote Quote  
  11. Code:
    pipeIn$ = " -f image2pipe  -s 1280x720  -pix_fmt yuv422p  -vcodec rawvideo - " + "-i " + filename$
    It compiles and runs. Now it shows a screen full of green.
    Quote Quote  
  12. The point of providing a raw YUY2 file was for you to load that data into your program instead of whatever you're currently loading. The point of the C source was to show how to load the data into a 2D image array. And so that I could verify the greyscale data extraction worked properly.

    But I think I figured out what's wrong with your program. So you were expecting to see something like this?

    Image
    [Attachment 47864 - Click to enlarge]


    The problem is that you aren't getting YUY2 data from the decoder, you are getting a U plane, a V plane, and a Y plane. Ie, instead of:

    Code:
    YUYV... (a total of 1280x720x2 bytes)
    You're getting:

    Code:
    UUUU... (a total of 640x720 bytes)
    VVVV... (a total of 640x720 bytes)
    YYYYYYYY... (a total of 1280x720 bytes)
    It should now be obvious how to fix your code now.
    Quote Quote  
  13. Now it works. I changed the pixel format to yuyv422:

    Code:
    pipeIn$ = "-i " + filename$ + " -f image2pipe  -s 1280x720  -pix_fmt yuyv422  -r 59.94  -vf zscale=in_range=limited:out_range=limited  -vcodec rawvideo -"
    I had tried that before with no success, but it works now.

    We're only half way there. Next will be to deal with the chroma information.
    Last edited by chris319; 21st Jan 2019 at 08:08.
    Quote Quote  
  14. Here was part of the problem. It only worked on the very first frame of video. I had been doing:

    Code:
    For ct = 0 To 60 ;READ FIRST 60 FRAMES
     
    ReadProgramData(readFrame, @frame(0), #H * #W * 3)
    
    Next
    so I had to change it to

    Code:
    For ct = 0 To 60 ;READ FIRST 60 FRAMES
     
    ReadProgramData(readFrame, @frame(0), #H * #W * 4)
    
    Next
    after repurposing the 4:2:0 code.

    https://www.linuxtv.org/downloads/v4l-dvb-apis-old/V4L2-PIX-FMT-YUYV.html
    Last edited by chris319; 21st Jan 2019 at 08:09.
    Quote Quote  
  15. Originally Posted by chris319 View Post
    Now it works. I changed the pixel format to yuyv422:
    I told you that in post #4.
    Quote Quote  
  16. Originally Posted by jagabo View Post
    I told you that in post #4.
    I had tried that before with no success
    It had other problems as well.
    Quote Quote  
  17. Originally Posted by chris319 View Post
    Here was part of the problem. It only worked on the very first frame of video. I had been doing:

    Code:
    For ct = 0 To 60 ;READ FIRST 60 FRAMES
     
    ReadProgramData(readFrame, @frame(0), #H * #W * 3)
    
    Next
    so I had to change it to

    Code:
    For ct = 0 To 60 ;READ FIRST 60 FRAMES
     
    ReadProgramData(readFrame, @frame(0), #H * #W * 4)
    
    Next
    after repurposing the 4:2:0 code.

    https://www.linuxtv.org/downloads/v4l-dvb-apis-old/V4L2-PIX-FMT-YUYV.html
    Of course. 4:2:0 is 1.5 bytes per pixel. 4:2:2 is 2 bytes per pixel.
    Quote Quote  
  18. Color has now been added. Works great!

    Thanks to everyone who helped.
    Quote Quote  
  19. Further complication:

    ffmpeg introduces grievous color errors when encoding with yuyv422. Better to code with yuv422p and let this program convert to yuyv422 when loading video.
    Quote Quote  
  20. Originally Posted by chris319 View Post
    Further complication:

    ffmpeg introduces grievous color errors when encoding with yuyv422. Better to code with yuv422p and let this program convert to yuyv422 when loading video.

    Did you mean utvideo ?

    You can demonstrate that it's lossless to convert between different 4:2:2 fourcc arrangements in ffmpeg. It's all the same thing, just slightly different ways of storing the data and memory alignment. eg. Planar vs. packed, yuy2, yuyv, yv16, uyvy, 2vuy, yuyv, yunv, uynv, etc.. dozens more. They are mean 4:2:2 and are interconvertible losslessly in the uncompressed domain. The problem is when the receiving application or filter is not flexible enough to understand this or can only handle certain pixel types or fourcc's .
    Quote Quote  
  21. No, I mean yuyv2. I tested it with x.264, same thing.

    It's all the same thing, just slightly different ways of storing the data and memory alignment
    Right, so one has to ask why the yuv422p colors are accurate and the yuyv422 colors are not. My casual observation has been that anything greater than +/-3 is a serious error.

    I have to document this well enough to submit as an ffmpeg bug and hope they don't blow it off.
    Quote Quote  
  22. Originally Posted by chris319 View Post
    No, I mean yuyv2. I tested it with x.264, same thing.

    It's all the same thing, just slightly different ways of storing the data and memory alignment
    Right, so one has to ask why the yuv422p colors are accurate and the yuyv422 colors are not. My casual observation has been that anything greater than +/-3 is a serious error.

    I have to document this well enough to submit as an ffmpeg bug and hope they don't blow it off.

    Exactly what do you mean by "yuv422p colors" and "yuyv422 colors" are accurate ? . What are you transforming to what and how are you measuring whatever exactly ?

    In the uncompressed domain, there are inter convertible if performed properly . x264 isn't uncompressed. utvideo isn't uncompressed . Earlier when I mentioned converting inbetween - This is what I'm referring to. If your program, or some filter, or some encoder "expects" a specific fourcc or arrangement, and outputs some other specific fourcc, you might have to do some conversions inbetween or modify your program or filters so they accept it properly. For example, the output pin from utvideo might be a different arrangement than the next filter requires. For example, zscale requires planar formats and you get other errors otherwise

    It happens frequently, in professional programs too, like broadcast NLE's. UYVY is the most common uncompressed fourcc for 8bit 4:2:2 in windows programs. It gets "special" treatment. Other formats don't get treated correctly and get converted to other things like RGB. It's just not feasible to support dozens of different uncompressed 4:2:2 arrangements.
    Quote Quote  
  23. Am I right to assume C0061.MP4 is 4:2:0 ? -pix_fmt yuyv422 (or yuv422p or any 4:2:2 derivative) as an output option will use swscale to do the chroma upscaling

    So another potential source of error is your 4:2:0 source chroma upscaling . By default ffmpeg will use a bicubic kernal . So if you were comparing to a 4:2:0 "original" , that 4:2:0 => 4:2:2 => 4:2:0 is not going to be the same . But if you use "nearest neighbor" or "point" algorithm, the chroma samples are just duplicated and the same ones discarded when going back to 4:2:0 , so it will be bit identical . You'd have to change the swsflags for swscale to use "neighbor" , or if using zscale filter to use "point" for the chroma scaling steps
    Quote Quote  
  24. As usual, I start with a .bmp with the entire raster a known color, encode it to a 10-second loop using utvideo, x.264 or whatever.

    View this loop on WMP, VLC or SMPlayer. Use an eyedropper program to check the colors. Or, I can view a frame of the video on the program I've been working on the past few days.

    yuv420p encoding: colors good

    yuv422p: colors good

    yuyv2: colors not good
    Last edited by chris319; 22nd Jan 2019 at 16:28.
    Quote Quote  
  25. So as an input, rgb=> yuyv2 into utvideo, x264, whatever, produces "colors no good" when viewed with a media player ?

    But rgb=> yuv422p is ok ?

    So use yuv422p because that is what utvideo, x264 are "expecting" as input for 8bit 4:2:2
    .
    .
    .
    But your program has problems with yuv422p input (from the output of utvideo, x264, whatever ?)

    Or what am I missing ?
    Quote Quote  
  26. Originally Posted by chris319 View Post
    Further complication:

    ffmpeg introduces grievous color errors when encoding with yuyv422. Better to code with yuv422p and let this program convert to yuyv422 when loading video.
    Always use -report to check if ffmpeg doesn't use silently additional conversion.
    Quote Quote  
  27. Yes, on the input side, it converts yuyv422 to yuv422p automatically when using utvideo. And the outputs are bit identical. And looks correct with the expected +/- 3 values in a mpchc, ffplay, mpv (that is, in the middle of wide "solid" color bars, where you can ignore chroma subsampling errors )

    Incompatible pixel format 'yuyv422' for codec 'utvideo', auto-selecting format 'yuv422p'
    Last edited by poisondeathray; 22nd Jan 2019 at 17:21.
    Quote Quote  
  28. Incompatible pixel format 'yuyv422' for codec 'utvideo', auto-selecting format 'yuv422p'
    If it's auto selecting yuv422p then why is there a color error? There is no color error when yuv422p is given in the command line, but there is when yuyv422 is given in the command line.
    Quote Quote  
  29. Originally Posted by chris319 View Post
    Incompatible pixel format 'yuyv422' for codec 'utvideo', auto-selecting format 'yuv422p'
    If it's auto selecting yuv422p then why is there a color error? There is no color error when yuv422p is given in the command line, but there is when yuyv422 is given in the command line.
    I don't know. It works for me. Bit identical

    What kind of "color error" ?

    Maybe problem with your command line ?

    Or checking method ? Make sure you close all instances of players, they might be decoding or rendering through a different pathway
    Quote Quote  
  30. Are you using zscale

    That's probably why
    Originally Posted by poisondeathray View Post
    If your program, or some filter, or some encoder "expects" a specific fourcc or arrangement, and outputs some other specific fourcc, you might have to do some conversions inbetween or modify your program or filters so they accept it properly. For example, the output pin from utvideo might be a different arrangement than the next filter requires. For example, zscale requires planar formats and you get other errors otherwise
    yuv422p is planar 8bit 4:2:2

    yuvv422 is packed 8bit 4:2:2

    swscale will auto convert . zscale doesn't have that logic built it and the colors should be way off
    Quote Quote  



Similar Threads