Recherche avancée

Sur d’autres sites (3841)

• 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

  


• FFmpeg playable MP4 segmented video from RTSP

  5 février 2021, par Michael Novotný

  I have problem with creating playable uncomplete MP4 file created from FFMPEG. In my case I have some infinite RTSP stream (h.264) from IP camera.
My target is record this stream to MP4 files for playback. If i use FFMPEG mp4 muxer, work correctly.

  


  /usr/bin/ffmpeg -progress pipe:5 -use_wallclock_as_timestamps 1 -analyzeduration 10000000 -probesize 10000000 -fflags +igndts -rtsp_transport tcp -hwaccel auto -loglevel warning -i rtsp://****:****@*******:****/ -y -an -vcodec copy -strict experimental -movflags frag_keyframe+empty_moov -f segment -segment_format mp4 -segment_format_options movflags=+faststart -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 -segment_time 15 /Shinobi/videos/bWkwjTWdRt/Rm67cYyq50/test-%S.mp4


  


  FFMPEG will create one MP4 file which still increasing its size. If I try copy or simply open this (uncomplete, still increased ... of course :) ) file, it's correcly play. But it's still only one file ... still bigger and bigger. For long-term recording cam (few weeks) it's not good.
I want segment this stream to multiple smaller MP4 files (as you knows from another typical NVR systems). For example : segment for 30minutes.
I used "segment" muxer.

  


  /usr/bin/ffmpeg -progress pipe:5 -use_wallclock_as_timestamps 1 -analyzeduration 10000000 -probesize 10000000 -fflags +igndts -rtsp_transport tcp -hwaccel auto -loglevel warning -i rtsp://*****:****@*********:****/ -y -an -vcodec copy -strict -2 -movflags frag_keyframe+empty_moov -f mp4 -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 -segment_list pipe:8 -segment_time 15 /Shinobi/videos/bWkwjTWdRt/Rm67cYyq50/test-%S.mp4


  


  It looks like work correctly. New file with defined mask is created every 30 minutes. If I try copy or simply open(and play) anyone "completed 30min segment file" it"s works correctly. Problem is with last file (more precisely : newest, still uncompleted last segment file) - it's not playable (moov atom not found).

  


  I Googled my problem many time with another keywords. I was try many my wonders. I readed FFMPEG documentation maybe 5times.

  


  Problem is with second passthroug which "segment muxer" do (which do -movflags +faststart .. for example). It's logicaly, second passthroug not be did in last(newest) file yet.

  


  Is there way to make it work ? If I want see time for 2-3 mins ago it's no possible wait up to 30minutes for "complete segment" ... and at the same time it is not possible to have a billion files with 2-3sec segments.
How did other NVR systems solve this ? Synology, Hikvision and more has in their file system recorded MP4 soubory which one of them is still uncompleted, still growing, but normaly PLAYABLE.

  


  A few last days I tried this with no success. I'am absolutely angry and sad. I hope that my text is understandable

  


  Thank you

  


  This options has no effect in my case (tried) :

  


  -movflags frag_keyframe+empty_moov

  


  -movflags faststart

  


  -movflags separate_moof

  


  -fragsize *** / -fragtime ***

  


  -strict -2 / -strict experimental

  


• avutil/mips : refactor msa SLDI_Bn_0 and SLDI_Bn macros.

  6 août 2019, par gxw

  avutil/mips : refactor msa SLDI_Bn_0 and SLDI_Bn macros.
  Changing details as following :
  
  1. The previous order of parameters are irregular and difficult to
  
     understand. Adjust the order of the parameters according to the
  
     rule : (RTYPE, input registers, input mask/input index/..., output registers).
  
     Most of the existing msa macros follow the rule.
  
  2. Remove the redundant macro SLDI_Bn_0 and use SLDI_Bn instead.
  Reviewed-by : Shiyou Yin <yinshiyou-hf@loongson.cn>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/mips/h264dsp_msa.c
  • [DH] libavcodec/mips/h264qpel_msa.c
  • [DH] libavcodec/mips/hevc_lpf_sao_msa.c
  • [DH] libavcodec/mips/hevcpred_msa.c
  • [DH] libavcodec/mips/hpeldsp_msa.c
  • [DH] libavcodec/mips/me_cmp_msa.c
  • [DH] libavcodec/mips/qpeldsp_msa.c
  • [DH] libavcodec/mips/vp8_mc_msa.c
  • [DH] libavcodec/mips/vp9_idct_msa.c
  • [DH] libavcodec/mips/vp9_lpf_msa.c
  • [DH] libavcodec/mips/vp9_mc_msa.c
  • [DH] libavutil/mips/generic_macros_msa.h