Recherche avancée

Sur d’autres sites (16004)

• How to interpret ffmpeg recording options available for a webcam (directshow) ?

  5 janvier 2023, par Jones659

  I am trying to create a GUI for personal use, that allows someone to customise recording and converting options of ffmpeg, without directly using the command line. At the moment, I am learning about different parameters and flags in ffmpeg.

  


  Apologies in advance if I end up asking some stupid questions, I am on a learning journey at the moment, unfortunately not all of this info is available online in an easily understandable way.

  


  I have a USB webcam which reported having the following options available to it :

  


  [dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=640x480 fps=5 max s=640x480 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=640x480 fps=5 max s=640x480 fps=30 (tv, bt470bg/bt709/unknown, topleft) chroma_location=topleft
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=352x288 fps=5 max s=352x288 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=352x288 fps=5 max s=352x288 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=320x240 fps=5 max s=320x240 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=320x240 fps=5 max s=320x240 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=176x144 fps=5 max s=176x144 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=176x144 fps=5 max s=176x144 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=160x120 fps=5 max s=160x120 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=160x120 fps=5 max s=160x120 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=1280x1024 fps=5 max s=1280x1024 fps=9
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=1280x1024 fps=5 max s=1280x1024 fps=9 (tv, bt470bg/bt709/unknown, topleft)


  


  I just want to get to the bottom of how I should interpret this, apologies that I will ask multiple questions :

  


  


  1. The fact that both resolution and fps have a min and max value (for every option) seems to imply that these two parameters are supposably uncontrollably variable, right ? In practice, the fps has been variable depending on brightness, however the resolution has not been - is it safe to assume that video imaging devices (especially such as a webcam) do not have variable resolution ?

     


  


  2. Secondly, why is it that every option is listed twice, except half of them specify extra info, such as color_range, color_space, and chroma_location ? Is this just a quirk ? Surely those extra parameter options should not be discarded ?

     


  


  3. It's hard to know how to make sense of this, but or example : the fact that only "tv" is ever shown, does that impliy that the webcam can only ever do limited color range, and there is no point trying to get full 0,255 out of it ? I read somewhere that "pc" implies full range of 0-255, whereas "tv" implies a range of 16-235

     


  


  4. With regards to color space, is it acceptable to record the webcam as raw (un-encoded), and then later convert to a different color space later down the line ? Which approach to dealing with the color-space yields the least amount of lost color ? My only previous experience with color spaces is in the realm of images - where for example, it makes no sense to convert sRGB to ROMM16 RGB, because you're going to a color space which has wider coverage, and extra colors won't be created out of thin air, you'd want to go once from raw to a color space, and avoid converting between color spaces afterwards. Also, what does "unknown" mean in the color space options ?

     


  


  


  Here's the culmination of some research/testing i've done, is there anything correct, or seriously wrong, in the conclusions and assumptions I've made below ?

  


  My understanding of pixel_format is as follows : when you're recording, (even to raw), you specify the pixel format using something like "-pixel_format yuyv422", this is a "packed", not "planar" format, which is produced by the webcam. When you convert from raw to something like mkv using libx264, you can't specify a "packed" pixel format such as "yuyv422", but must instead use an appropriate planar counterpart, such as "yuv422p", which would be specified using "-pix_fmt yuv422p".

  


  I did a raw recording of the webcam (in which I recorded a bright light, in the dark), I didn't set any of the options in the brackets above. I then converted this video using libx264 with the flags "-dst_range 1 -color_range 2" which I saw elsewhere on the internet.

  


  Taking a screenshot of this video using vlc, and putting it through imagemagick identify -verbose, shows that the color range of the screenshot is 0,255, as for the video itself, "MediaInfo" reports "color range:Full", VLC's codec info says "Decoded format : Planar 4:2:2 YUV full scale - is this info worth anything, or is it just meta-data that the video got tagged with ?

  


  At first I was happy about imagemagick's color range reporting, but I am thinking now, the 0, 255 range could be a result of "overshoot" values produced by the camera, which aren't actually supposed to be mapped linearly.

  


  I appreciate that this probably feels like some school-kiddy offloading their homework assignment to avoid doing work, but I hope it can be seen that I've looked into these things prior to putting this post together.

  


  Thanks in advance, if anyone takes the time to answer anything.

  


• ffmpeg app using node occasionally crashes as file doesn't appear to be read correctly

  31 mai 2022, par Zabs

  I have an simple Node application that allows me to pass an AWS S3 URL link to a file (in this case video files). It uses the FFMPEG library to read the video file and return data like codecs, duration, bitrate etc..

  


  The script is called from PHP script which in turn send the data to the Node endpoint and passes the Amazon S3 URL to node. Sometimes for no obvious reasons the video file fails to return the expected values regarding container, codec, duration etc... and just returns '0'. But when I try the exact same file/request again it returns this data correctly e.g container:mp4

  


  I'm not sure but I think the script somehow needs the createWriteStream to be closed but I cannot be sure, the problem is the issue I have found doesn't happen all the time but sporadically so its hard to get to the issue when its difficult to replicate it.

  


  Any ideas ?

  


  router.post('/', async function(req, res) {
  const fileURL = new URL(req.body.file);
  var path = fileURL.pathname;
  path = 'tmp/'+path.substring(1);    // removes the initial / from the path

  let file = fs.createWriteStream(path);  // create the file locally
  const request = https.get(fileURL, function(response) {
    response.pipe(file);
  });
  
  // after file has saved
  file.on('finish', function () {
    var process = new ffmpeg(path);
    process.then(function (video) {
      let metadata = formatMetadata(video.metadata);

      res.send ({
        status: '200',
        data: metadata,
        errors: errors,
        response: 'success'
      });

    }, function (err) {
      console.warn('Error: ' + err);

      res.send ({
        status: '400',
        data: 'Something went wrong processing this video',
        response: 'fail',
      });
    });
  });

  file.on('error', function (err) {
    console.warn(err);
  });

});

function formatMetadata(metadata) {
  const data = {
    'video' : metadata.video,
    'audio' : metadata.audio,
    'duration' : metadata.duration
  };
  return data;
}


  


  // Expected output

  


  {"data":{"video":{"container":"mov","bitrate":400,"stream":0,"codec":"h264","resolution":{"w":1280,"h":720},"resolutionSquare":{"w":1280,"h":720},"aspect":{"x":16,"y":9,"string":"16:9","value":1.7777777777777777},"rotate":0,"fps":25,"pixelString":"1:1","pixel":1},"audio":{"codec":"aac","bitrate":"127","sample_rate":44100,"stream":0,"channels":{"raw":"stereo","value":2}},"duration":{"raw":"00:00:25.68","seconds":25}}


  


  // Actual output

  


  {"data":{"video":{"container":"","bitrate":0,"stream":0,"codec":"","resolution":{"w":0,"h":0},"resolutionSquare":{"w":0,"h":null},"aspect":{},"rotate":0,"fps":0,"pixelString":"","pixel":0},"audio":{"codec":"","bitrate":"","sample_rate":0,"stream":0,"channels":{"raw":"","value":""}},"duration":{"raw":"","seconds":0}}


  


  Note - this happens sporadically

  


• lavc/aarch64 : motion estimation functions in neon

  26 juin 2022, par Swinney, Jonathan

  lavc/aarch64 : motion estimation functions in neon
   - ff_pix_abs16_neon
  
   - ff_pix_abs16_xy2_neon
  In direct micro benchmarks of these ff functions verses their C implementations,
  
  these functions performed as follows on AWS Graviton 3.
  ff_pix_abs16_neon :
  
  pix_abs_0_0_c : 141.1
  
  pix_abs_0_0_neon : 19.6
  ff_pix_abs16_xy2_neon :
  
  pix_abs_0_3_c : 269.1
  
  pix_abs_0_3_neon : 39.3
  Tested with :
  
  ./tests/checkasm/checkasm —test=motion —bench —disable-linux-perf
  Signed-off-by : Jonathan Swinney <jswinney@amazon.com>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/aarch64/Makefile
  • [DH] libavcodec/aarch64/me_cmp_init_aarch64.c
  • [DH] libavcodec/aarch64/me_cmp_neon.S
  • [DH] libavcodec/me_cmp.c
  • [DH] libavcodec/me_cmp.h
  • [DH] tests/checkasm/Makefile
  • [DH] tests/checkasm/checkasm.c
  • [DH] tests/checkasm/checkasm.h
  • [DH] tests/checkasm/motion.c
  • [DH] tests/fate/checkasm.mak