Sur d’autres sites (6563)

• fate/iamf : add a demux text

  24 avril 2024, par James Almer

  fate/iamf : add a demux text
  Using the same input sample as iamf-5_1-copy, in order to compare both test's output
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] tests/fate/iamf.mak
  • [DH] tests/ref/fate/iamf-5_1-demux

• How to get video pixel location from screen pixel location ?

  22 février 2024, par AmLearning

  Wall of Text so I tried breaking it up into sections to make it better sorry in advance

  


  The problem

  


  I have some video files that I am reading with ffmpeg to get the colors at specific pixels, and all seems well, but I just ran into a problem with finding the right pixel to input. I realized (or mistakingly believe) that the pixel location (x,y) on the screen will be different than the local pixel location so to speak of the video (ie. If I want to get pixel 50,0 of the video that will be different than my screen's pixel 50,0 because the resolutions don't match). I was trying to think of a way to convert my screen's pixel location into the "local pixel location", and I have two ideas but I am not sure if any of them is any good. Note I am currently using cmd+shift+4 on macos to get the screen coordinates and the video is playing fullscreen like in the screenshot below.

  


  Ideas

  


  


  1. If I manually measure and account for this vertical offset, would it effectively convert the screen coordinate into the "local" one ?

     


  


  2. If I instead adjust my SwsContext to put the destination height and width as that of my screen, will it effectively replace the need to convert screen coordinates to the video coordinates ?

     


  


  


  Problems with the Ideas

  


  The problems I see with the first solution are that I am assuming there is no hidden horizontal offset (or conversely that all of the width of the video is actually renderable on the screen). Additionally, this solution would only get an approximate result as I would need to manually measure the offsets, screen width, and screen height using the method I currently am using to get the screen coordinates.

  


  With the second solution, aside from the question of if it will even work, the problem becomes that I can no longer measure what the screen coordinates I want are because I can't seem to get rid of those black bars in VLC.

  


  Some Testing I did

  


  Given that if the black bars are part of the video itself, my entire problem would be fixed (maybe ?) I tried seeing if the black bars were part of the video, and when I looked at the frame data's first pixel, it was black. The problem then is that if the black bars are entirely part of the video, then why are the colors I get for some pixels slightly off (I am checking with ColorSync Utility). These colors aren't just slightly off as in wrong but it seems more that they belong to a slightly offset region of the video.

  


  However, this may be somewhat explained if ffmpeg reads right to left. When I put the top left corner of the video into the program and looked again at the pixel data in the frame for that location (location again was calculated by assuming the video location would be the same as the screen location) instead of getting white, I got a bluish color much like the glove in the top right corner.

  


  The Watered Down Code

  


      struct SwsContext *rescaler = NULL;
    rescaler = sws_getContext(codec_context->width, codec_context->height, codec_context->pix_fmt, codec_context->width, codec_context->height, AV_PIX_FMT_RGB0, SWS_FAST_BILINEAR, NULL, NULL, 0);

// Get Packets (containers for frames but not guaranteed to have a full frame) and Frames
    while (av_read_frame(avformatcontext, packet) >= 0)
    {
        
        // determine if packet is video packet
        if (packet->stream_index != video_index)
        {
            continue;
        }
        
        // send packet to decoder
        if (avcodec_send_packet(codec_context, packet) < 0)
        {
            perror("Failed to decode packet");
        }
        
        // get frame from decoder
        int response = avcodec_receive_frame(codec_context, frame);
        if (response == AVERROR(EAGAIN))
        {
            continue;
        }
        else if (response < 0)
        {
            perror("Failed to get frame");
        }
        
        // convert frame to RGB0 colorspace 4 bytes per pixel 1 per channel
        response = sws_scale_frame(rescaler, scaled_frame, frame);
        if(response < 0){
            perror("Failed to change colorspace");
        }
        // get data and write it
        int pixel_number = y*(scaled_frame->linesize[0]/4)+x; // divide by four gets pixel linesize (4 byte per pixel)
        int byte_number = 4*(pixel_number-1); // position of pixel in array
        // start of debugging things
        int temp = scaled_frame->data[0][byte_number]; // R
        int one_after = scaled_frame->data[0][byte_number+1]; // G
        int two_after = scaled_frame->data[0][byte_number+2]; // B
        int als; // where i put the breakpoint
        // end of debugging things
    }


  


  In Summary

  


  I have no idea what is happening.

  


  I take the data for a pixel and compare it to what colorsync utility says should be there, but it is always slightly off as though the pixel I was actually reading was offset from what I thought I was reading. Therefore, I want to find a way to get the pixel location in a video given a screen coordinate when the video is in fullscreen, but I have no idea how to (aside from a few ideas that are probably bad at best).

  


  Also does FFMPEG put the frame data right to left ?

  


  A Video Better Showing My Problem

  


  https://www.youtube.com/watch?v=NSEErs2lC3A

  


• Python OpenCV VideoCapture Color Differs from ffmpeg and Other Media Players

  17 avril 2024, par cliffsu

  I’m working on video processing in Python and have noticed a slight color difference when using cv2.VideoCapture to read videos compared to other media players.

  


  

  


  I then attempted to read the video frames directly using ffmpeg, and despite using the ffmpeg backend in OpenCV, there are still differences between OpenCV’s and ffmpeg’s output. The frames read by ffmpeg match those from other media players.

  


  

  


  Below are the videos I’m using for testing :

  


  test3.webm

  


  test.avi

  


  Here is my code :

  


  import cv2
import numpy as np
import subprocess

def read_frames(path, res):
    """Read numpy arrays of video frames. Path is the file path
       and res is the resolution as a tuple."""
    args = [
        "ffmpeg",
        "-i",
        path,
        "-f",
        "image2pipe",
        "-pix_fmt",
        "rgb24",
        "-vcodec",
        "rawvideo",
        "-",
    ]

    pipe = subprocess.Popen(
        args,
        stdout=subprocess.PIPE,
        stderr=subprocess.DEVNULL,
        bufsize=res[0] * res[1] * 3,
    )

    while pipe.poll() is None:
        frame = pipe.stdout.read(res[0] * res[1] * 3)
        if len(frame) > 0:
            array = np.frombuffer(frame, dtype="uint8")
            break

    pipe.stdout.close()
    pipe.wait()
    array = array.reshape((res[1], res[0], 3))
    array = cv2.cvtColor(array, cv2.COLOR_RGB2BGR)
    return array

ORIGINAL_VIDEO = 'test3.webm'

array = read_frames(ORIGINAL_VIDEO, (1280, 720))

cap = cv2.VideoCapture(ORIGINAL_VIDEO, cv2.CAP_FFMPEG)
while cap.isOpened():
    ret, frame = cap.read()
    if not ret:
        break
    print(frame.shape)
    cv2.imshow("Opencv Read", frame)
    cv2.imshow("FFmpeg Direct Read", array)
    cv2.waitKeyEx()
    cv2.waitKeyEx()
    break
cap.release()


  


  I’ve attempted to use different media players to compare cv2.VideoCapture and ffmpeg’s frame reading, to confirm that the issue lies with opencv. I’m looking to determine whether it’s a bug in OpenCV or if there are issues in my code.

  


  EDIT :

  


  Just use the following code to check the difference between opencv read and ffmpeg read.

  


  cv2.imshow('test', cv2.absdiff(array, frame)*10)
cv2.waitKey(0)


  


  Here is the result :