Recherche avancée

Sur d’autres sites (7073)

• Fastest way to extract raw Y' plane data from Y'Cb'Cr encoded video ?

  20 février 2024, par memeko

  I have a use-case where I'm extracting I-Frames from videos and turning them into perceptual hashes for later analysis.

  


  ⠀

  


  I'm currently using ffmpeg to do this with a command akin to :

  


  ffmpeg -skip_frame nokey -i 'in%~1.mkv' -vsync vfr -frame_pts true -vf 'keyframes/_Y/out%~1/%%06d.bmp'

  


  and then reading in the data from the resulting images.

  


  ⠀

  


  This is a bit wasteful as, to my understanding, ffmpeg does implicit YUV -> RGB colour-space conversion and I'm also needlessly saving intermediate data to disk.

  


  Most modern video codecs utilise chroma subsampling and have frames encoded in a Y'C_bC_r colour-space, where Y' is the luma component, and Cb Cr are the blue-difference, red-difference chroma components.

  


  Which in something like YUV420p used in h.264/h.265 video codecs is encoded as such :

  


  

  


  Where each Y' value is 8 bits long and corresponds to a pixel.

  


  ⠀

  


  As I use gray-scale data for generating the perceptual hashes anyway, I was wondering if there is a way to simply grab just the raw Y' values from any given I-Frame into an array and skip all of the unnecessary conversions and extra steps ?

  


  (as the luma component is essentially equivalent to the grayscale data i need for generating hashes)

  


  I came across the -vf 'extractplanes=y' filter in ffmpeg that seems like it might do just that, but according to source :

  


  


  "...what is extracted by 'extractplanes' is not raw data of the (for example) Y plane. Each extracted is converted to grayscale. That is, the converted video data has YUV (or RGB) which is different from the input."

  


  


  which makes it seem like it's touching chroma components and doing some conversion anyway, in testing applying this filter didn't affect the processing time of the I-Frame extraction either.

  


  ⠀

  


  My script is currently written in Python, but I am in the process of migrating it to C++, so I would prefer any solutions pertaining to the latter.

  


  ffmpeg seems like the ideal candidate for this task, but I really am looking for whatever solution that would ingest the data fastest, preferably saving directly to RAM, as I'll be processing a large number of video files and discarding I-Frame luma pixel data once a hash has been generated.

  


  I would also like to associate each I-Frame with its corresponding frame number in the video.

  


• Android Video color effect issue using FFMPEG [on hold]

  8 juin 2016, par umesh mishra

  I m facing one problem. when we use library for effect that i have mentioned below video is created only 1/3 of actual video size. please tell me what is issue. and also doesn’t work on marshmallow.
  https://github.com/krazykira/VidEffects/wiki/Permanent-video-effects

• Why do I get different codecs on Windows and Linux with same code ?

  27 janvier 2016, par user3277340

  I am using the API version of FFMPEG to generate a MP4 file from a series of images. I specify the output by calling

  AVFormatContext *oc = NULL ;
  avformat_alloc_output_context2 (&oc,NULL,"mp4",NULL) ;

  Running the exact same code on Windows and Linux I get different codecs assigned. On Windows, the value of oc->oformat->video_code is AV_CODEC_ID_H264 (28), but on Linux I get AV_CODEC_ID_MPEG4.

  I tracked this down because on Windows my calls to avcodec_encode_video2(.,.,.,&got_packet) were always returning got_packet=0 so I never called av_interleaved_write_frame. I added a NULL AVFrame at the end to flush the video. But it was very small and did not contain the images I expected to see there.

  But on Linux everything worked just fine. So I went ahead and manually changed the value of oc->oformat->video_code and I got the expected results.

  My questions :

  1) Why do I get different codec types on different platforms with the same code ? Is there a parameter I need to set to force MPEG4 ?

  2) Is it "legal" to change this parameter after the call to avformat_alloc_output_context2 ? My concern is that "oc" has been properly initialized and, with the change, something may be inconsistent.

  3) Is there a way to force the MPEG4 codec on any machine ?

  Thanks.