Given a frame of 8-bit 4:2:2 YUV pixels, does anyone have some code that would read the Y, U and V components of the individual pixels?
Thank you.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays!
+ Reply to Thread
Results 1 to 30 of 67
Thread
-
-
Perhaps this one? https://github.com/IENT/YUView
Last edited by pandy; 6th Nov 2018 at 12:41.
-
I can't get this to work:
Code:indx = 0 For ycoord = 0 To #HEIGHT - 1 For x = 0 To #WIDTH - 1 y = frame(indx) ;// y is an unsigned 8-bit byte Plot (x, ycoord, RGB(y,y,y)); DRAW BLACK & WHITE MONITOR indx + 2
https://docs.microsoft.com/en-us/previous-versions/aa904813(v=vs.80)#yuvformats_2
I see an image but it is misframed. The video was encoded at 4:2:2 using ffmpeg's pix_fmt yuv422p. The frame is read in using ffmpeg.
I got similar code to work in 4:2:0.
What am I doing wrong? -
yuv422p is a planar format. That is, all the Y samples in one array, all the U samples in another array, and all the V samples in a third array.
That code is for displaying the greyscale portion of interleaved YUV 4:2:2 formats like yuyv422, YUY2. -
I recoded it as follows to read consecutive planar pixels and no joy:
Code:indx = 0 For ycoord = 0 To #HEIGHT - 1 For x = 0 To #WIDTH - 1 y = frame(indx) ;// y is an unsigned 8-bit byte Plot (x, ycoord, RGB(y,y,y)); DRAW BLACK & WHITE MONITOR indx + 1
According to the Microsoft page I linked to, YUY2 is the preferred format.
https://docs.microsoft.com/en-us/previous-versions/aa904813(v=vs.80)#yuvformats_2
There is no YUY2 in ffmpeg's list of pixel formats:
Code:Pixel formats: I.... = Supported Input format for conversion .O... = Supported Output format for conversion ..H.. = Hardware accelerated format ...P. = Paletted format ....B = Bitstream format FLAGS NAME NB_COMPONENTS BITS_PER_PIXEL ----- IO... yuv420p 3 12 IO... yuyv422 3 16 IO... rgb24 3 24 IO... bgr24 3 24 IO... yuv422p 3 16 IO... yuv444p 3 24 IO... yuv410p 3 9 IO... yuv411p 3 12 IO... gray 1 8 IO..B monow 1 1 IO..B monob 1 1 I..P. pal8 1 8 IO... yuvj420p 3 12 IO... yuvj422p 3 16 IO... yuvj444p 3 24 IO... uyvy422 3 16 ..... uyyvyy411 3 12 IO... bgr8 3 8 .O..B bgr4 3 4 IO... bgr4_byte 3 4 IO... rgb8 3 8 .O..B rgb4 3 4 IO... rgb4_byte 3 4 IO... nv12 3 12 IO... nv21 3 12 IO... argb 4 32 IO... rgba 4 32 IO... abgr 4 32 IO... bgra 4 32 IO... gray16be 1 16 IO... gray16le 1 16 IO... yuv440p 3 16 IO... yuvj440p 3 16 IO... yuva420p 4 20 IO... rgb48be 3 48 IO... rgb48le 3 48 IO... rgb565be 3 16 IO... rgb565le 3 16 IO... rgb555be 3 15 IO... rgb555le 3 15 IO... bgr565be 3 16 IO... bgr565le 3 16 IO... bgr555be 3 15 IO... bgr555le 3 15 ..H.. vaapi_moco 0 0 ..H.. vaapi_idct 0 0 ..H.. vaapi_vld 0 0 IO... yuv420p16le 3 24 IO... yuv420p16be 3 24 IO... yuv422p16le 3 32 IO... yuv422p16be 3 32 IO... yuv444p16le 3 48 IO... yuv444p16be 3 48 ..H.. dxva2_vld 0 0 IO... rgb444le 3 12 IO... rgb444be 3 12 IO... bgr444le 3 12 IO... bgr444be 3 12 IO... ya8 2 16 IO... bgr48be 3 48 IO... bgr48le 3 48 IO... yuv420p9be 3 13 IO... yuv420p9le 3 13 IO... yuv420p10be 3 15 IO... yuv420p10le 3 15 IO... yuv422p10be 3 20 IO... yuv422p10le 3 20 IO... yuv444p9be 3 27 IO... yuv444p9le 3 27 IO... yuv444p10be 3 30 IO... yuv444p10le 3 30 IO... yuv422p9be 3 18 IO... yuv422p9le 3 18 IO... gbrp 3 24 IO... gbrp9be 3 27 IO... gbrp9le 3 27 IO... gbrp10be 3 30 IO... gbrp10le 3 30 IO... gbrp16be 3 48 IO... gbrp16le 3 48 IO... yuva422p 4 24 IO... yuva444p 4 32 IO... yuva420p9be 4 22 IO... yuva420p9le 4 22 IO... yuva422p9be 4 27 IO... yuva422p9le 4 27 IO... yuva444p9be 4 36 IO... yuva444p9le 4 36 IO... yuva420p10be 4 25 IO... yuva420p10le 4 25 IO... yuva422p10be 4 30 IO... yuva422p10le 4 30 IO... yuva444p10be 4 40 IO... yuva444p10le 4 40 IO... yuva420p16be 4 40 IO... yuva420p16le 4 40 IO... yuva422p16be 4 48 IO... yuva422p16le 4 48 IO... yuva444p16be 4 64 IO... yuva444p16le 4 64 ..H.. vdpau 0 0 IO... xyz12le 3 36 IO... xyz12be 3 36 ..... nv16 3 16 ..... nv20le 3 20 ..... nv20be 3 20 IO... rgba64be 4 64 IO... rgba64le 4 64 IO... bgra64be 4 64 IO... bgra64le 4 64 IO... yvyu422 3 16 I.... ya16be 2 32 I.... ya16le 2 32 IO... gbrap 4 32 IO... gbrap16be 4 64 IO... gbrap16le 4 64 ..H.. qsv 0 0 ..H.. mmal 0 0 ..H.. d3d11va_vld 0 0 ..H.. cuda 0 0 IO... 0rgb 3 24 IO... rgb0 3 24 IO... 0bgr 3 24 IO... bgr0 3 24 IO... yuv420p12be 3 18 IO... yuv420p12le 3 18 IO... yuv420p14be 3 21 IO... yuv420p14le 3 21 IO... yuv422p12be 3 24 IO... yuv422p12le 3 24 IO... yuv422p14be 3 28 IO... yuv422p14le 3 28 IO... yuv444p12be 3 36 IO... yuv444p12le 3 36 IO... yuv444p14be 3 42 IO... yuv444p14le 3 42 IO... gbrp12be 3 36 IO... gbrp12le 3 36 IO... gbrp14be 3 42 IO... gbrp14le 3 42 IO... yuvj411p 3 12 I.... bayer_bggr8 3 8 I.... bayer_rggb8 3 8 I.... bayer_gbrg8 3 8 I.... bayer_grbg8 3 8 I.... bayer_bggr16le 3 16 I.... bayer_bggr16be 3 16 I.... bayer_rggb16le 3 16 I.... bayer_rggb16be 3 16 I.... bayer_gbrg16le 3 16 I.... bayer_gbrg16be 3 16 I.... bayer_grbg16le 3 16 I.... bayer_grbg16be 3 16 ..H.. xvmc 0 0 IO... yuv440p10le 3 20 IO... yuv440p10be 3 20 IO... yuv440p12le 3 24 IO... yuv440p12be 3 24 IO... ayuv64le 4 64 ..... ayuv64be 4 64 ..H.. videotoolbox_vld 0 0 IO... p010le 3 15 IO... p010be 3 15 IO... gbrap12be 4 48 IO... gbrap12le 4 48 IO... gbrap10be 4 40 IO... gbrap10le 4 40 ..H.. mediacodec 0 0 IO... gray12be 1 12 IO... gray12le 1 12 IO... gray10be 1 10 IO... gray10le 1 10 IO... p016le 3 24 IO... p016be 3 24 ..H.. d3d11 0 0 IO... gray9be 1 9 IO... gray9le 1 9 ..... gbrpf32be 3 96 ..... gbrpf32le 3 96 ..... gbrapf32be 4 128 ..... gbrapf32le 4 128 ..H.. drm_prime 0 0 ..H.. opencl 0 0
-
FFmpeg pixel format constants with exhaustive explanations.
https://ffmpeg.org/doxygen/trunk/pixfmt_8h_source.html -
Thanks fellas, but no improvement with YUYV422.
The image should fill the window in the upper left corner of the screen as it does in my 4:2:0 version.
Here is the complete code:
Code:D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y -i "D:\Videos\Trains\December_6_2018_San_Jose\C0061.MP4" -c:v utvideo -colorspace 1 -pix_fmt yuyv422 -r 59.94 -vf scale=1280x720:flags=lanczos,eq=gamma=0.76,lutyuv=y='clip((val*(255-%LIFT%)/255)+%LIFT%,0,235)' -c:a pcm_s16le "processed.mkv"
-
The upper half is chroma samples. The lower half is lum samples, but half the image is shifted over.
-
Look at the lower half of the image. Half of the image is duplicated to the right.
-
Eye bulbs? Check if there is difference in fields and if there is no any problem. Normally for 4:2:0 overall amount of bits should be 1.5 of Luminance resolution. if there is more then something is NOK (not 4:2:0 etc).
btw camera sensors to read faster from sensor can provide interleaved samples... check this if there is no vertical/horizontal interleaving. -
What are eye bulbs, Pandy?
Here, you tell me if it's interlaced.
Code:ffprobe version 4.1 Copyright (c) 2007-2018 the FFmpeg developers built with gcc 8.2.1 (GCC) 20181017 configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth libavutil 56. 22.100 / 56. 22.100 libavcodec 58. 35.100 / 58. 35.100 libavformat 58. 20.100 / 58. 20.100 libavdevice 58. 5.100 / 58. 5.100 libavfilter 7. 40.101 / 7. 40.101 libswscale 5. 3.100 / 5. 3.100 libswresample 3. 3.100 / 3. 3.100 libpostproc 55. 3.100 / 55. 3.100 Input #0, avi, from '12M.avi': Metadata: encoder : Lavf58.12.100 Duration: 00:00:59.06, start: 0.000000, bitrate: 335746 kb/s Stream #0:0: Video: utvideo (ULH2 / 0x32484C55), yuv422p(bt709/unknown/unknown), 1280x720, 333514 kb/s, SAR 1:1 DAR 16:9, 59.94 fps, 59.94 tbr, 59.94 tbn, 59.94 tbc Stream #0:1: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s32 (24 bit), 2304 kb/s
-
How reliable is header information? Who is header creator? RAW information is headerless thus you can't say if video is progressive based on header information.
You need to analyse motion (difference between fields over time) to say if this is interlace or progressive. It can be progressive but interleaved then you need to deinterleave RAW video. Sensor may read values as ODD/EVEN in Horizontal and ODD/EVEN in Vertical direction.
you should have detailed information from camera sensor vendor - it is called datasheet - for example https://www.onsemi.com/pub/Collateral/MT9P031-D.PDF
And eye bulbs are your own eyes - this is final judge so analyse few frames even manually for dependencies... -
-
The video is being resized by ffmpeg to 1280 x 720. Here is the ffmpeg command:
ffmpeg -y -i C0061.MP4 -c:v utvideo -colorspace 1 -pix_fmt yuyv422 -r 59.94 -vf scale=1280x720:flags=lanczos,eq=gamma=0.76,lutyuv= y='clip((val*(255-%LIFT%)/255)+%LIFT%,0,235)' -c:a pcm_s16le "processed.mkv"
Take note of the -r 59.94. Does that mean 59.94 fields (interlaced) or frames (progressive)?
Would a video player need to know if interlaced or not to play back correct images, unlike the ones I'm getting? A video player can't determine this by staring with its eye bulbs. -
What does the image look like when viewed in a media player or other editor?
I'm still not sure what that image is supposed to be showing. I originally thought it was two videos viewed side by side, like a before and after comparison (with chroma channels at the top, luma below). But now I think you're saying it's just one video. But why is the greyscale area 32:9, not 16:9 like source your video?
I checked ffmpeg's yuyv422 output and it is indeed the same as YUY2. At least when I exported as AVI. Even if the video was interlaced it would not show up as two videos side by side. You would just see comb artifacts when viewing at full scale.
Maybe you should upload a raw source clip and your ffmpeg conversion. -
-
What does the image look like when viewed in a media player or other editor?
http://www.chrisnology.info/videos/processed.mkv
My program scans the bitmap from y = 0 to 719 and from x = 0 to 1279. It then draws to the screen at y/2 and x/2 to fit in the upper quadrant of the screen (360 x 640) and that's what you're seeing. This technique works wonderfully well if the pixels are 4:2:0, so it's not the way I'm drawing to screen.
I posted my code previously. -
Robots eyes made from light bulbs...
https://en.wikipedia.org/wiki/The_Cyberiad
Your feedback made me laugh as i realised how hilarious this may look for English speaker.
Apologies for being OT - sorry chris319 -
The code in post #3 plots at x,y, not y/2,y/2.
A possible issue is that your source is compressed with UT. What comes out of the decompressor may not be YUY2, even if that's what went in. Attached a raw 1280x720 YUY2 file (the first frame of processed.mkv) and an AviSynth that reads it with RawSource(). See if you can render that raw YUY2 data correctly. -
The code in post #3 plots at x,y, not y/2,y/2.
A possible issue is that your source is compressed with UT. What comes out of the decompressor may not be YUY2, even if that's what went in.
Attached a raw 1280x720 YUY2 file (the first frame of processed.mkv) and an AviSynth that reads it with RawSource(). See if you can render that raw YUY2 data correctly. -
Similar program with 4:2:0 pixels in full color, what it's supposed to look like when finished.
Right now I can't even get the black-and-white pixels to render properly.
http://www.chrisnology.info/videos/Capture.JPG -
Oops, got distracted and forgot the attachment.
Also verified with a quick and dirty C program:
Code:#include <stdio.h> #include <stdlib.h> #define IMAGE_WIDTH 1280 #define IMAGE_HEIGHT 720 unsigned char YUY2[IMAGE_HEIGHT][IMAGE_WIDTH*2]; unsigned char Y8[IMAGE_HEIGHT][IMAGE_WIDTH]; int main(void) { FILE *infd, *outfd; infd = fopen("1280x720yuy2.raw", "rb"); outfd = fopen("1280x720y8.raw", "wb"); fread(YUY2, 1, IMAGE_HEIGHT*IMAGE_WIDTH*2, infd); for (int y=0; y<IMAGE_HEIGHT; y++) { for (int x=0; x<IMAGE_WIDTH; x++) { Y8[y][x] = YUY2[y][x*2]; } } fwrite(Y8, 1, IMAGE_WIDTH*IMAGE_HEIGHT, outfd); fclose(infd); fclose(outfd); }
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