Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 31 to 60 of 67
Thread
-
-
Gimp isn't reading the .raw file created by your program.
What exactly are we trying to accomplish here? -
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).
-
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
-
I opened it with my "scope" program and I got a screen full of black.
Windows Movie Maker opened it; screen full of black. -
-
-
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 -
Code:
pipeIn$ = " -f image2pipe -s 1280x720 -pix_fmt yuv422p -vcodec rawvideo - " + "-i " + filename$
-
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?
[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)
Code:UUUU... (a total of 640x720 bytes) VVVV... (a total of 640x720 bytes) YYYYYYYY... (a total of 1280x720 bytes)
-
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 -"
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.
-
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
Code:For ct = 0 To 60 ;READ FIRST 60 FRAMES ReadProgramData(readFrame, @frame(0), #H * #W * 4) Next
https://www.linuxtv.org/downloads/v4l-dvb-apis-old/V4L2-PIX-FMT-YUYV.htmlLast edited by chris319; 21st Jan 2019 at 08:09.
-
-
-
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 . -
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
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. -
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 -
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 goodLast edited by chris319; 22nd Jan 2019 at 16:28.
-
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 ? -
-
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.
-
-
Similar Threads
-
Confused about the pixels
By patrick in forum Newbie / General discussionsReplies: 36Last Post: 13th Feb 2017, 17:32 -
Game lag pixels.
By Jappyanime in forum ComputerReplies: 13Last Post: 20th Nov 2015, 13:04 -
Block of pixels!
By alkoon in forum CapturingReplies: 3Last Post: 12th Aug 2015, 21:22 -
Twinkling pixels - 59iHz vs 59pHz
By VFRBoy in forum ComputerReplies: 2Last Post: 11th Jul 2015, 03:38