Recherche avancée

Sur d’autres sites (7972)

• 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

  


• swscale/aarch64 : add hscale specializations

  26 mai 2022, par Swinney, Jonathan

  swscale/aarch64 : add hscale specializations
  This patch adds code to support specializations of the hscale function
  
  and adds a specialization for filterSize == 4.
  ff_hscale8to15_4_neon is a complete rewrite. Since the main bottleneck
  
  here is loading the data from src, this data is loaded a whole block
  
  ahead and stored back to the stack to be loaded again with ld4. This
  
  arranges the data for most efficient use of the vector instructions and
  
  removes the need for completion adds at the end. The number of
  
  iterations of the C per iteration of the assembly is increased from 4 to
  
  8, but because of the prefetching, there must be a special section
  
  without prefetching when dstW < 16.
  This improves speed on Graviton 2 (Neoverse N1) dramatically in the case
  
  where previously fs=8 would have been required.
  before : hscale_8_to_15__fs_8_dstW_512_neon : 1962.8
  
  after : hscale_8_to_15__fs_4_dstW_512_neon : 1220.9
  Signed-off-by : Jonathan Swinney <jswinney@amazon.com>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libswscale/aarch64/hscale.S
  • [DH] libswscale/aarch64/swscale.c
  • [DH] libswscale/utils.c

• what codec to specify to accessing my HDMI-to-USB adaptor, under Linux ? [closed]

  14 mai 2022, par David

  A week or so ago,I bought a HDMI-to-USB adapter, to use to capture video
TV content from my TV's set-top box. (Xfinity, if it matters. Box generically is :
"XiD X1"...I have both the Pace and the Cisco models available here in this house.)

  


  Specifically, here's the adapter I bought,from Amazon :
https://www.amazon.com/gp/product/B09FLN63B3

  


  So, I'm fluent in both Windows (Win-11) and Linux (Debian 'Bullseye', on my chromebook).

  


  The adapter does not come with any recommendations for what software/drivers to (try to) use, but I was prepared for that.
After some google searches, I decided to first try using the cmd-line
'ffmpeg' program, because I'm
quite familiar with that (excellent !) piece of open-source software !

  


  So, after a day or two of (mostly) success recordings under Win-11, using
ffmpeg's Microsoft-based 'dshow' (aka 'DirectShow'), I decided to attempt to get
up to the same level of accomplishment on my Chromebook, under Linux, also
using 'ffmpeg'.

  


  [Ok...a very brief explanation of 'mostly' successful. I'll
post another separate question here, about the specifics of my glitches,
using 'dshow' on Windows. But, essentially, when I try to record to a MP4
file, I get 2 scenarios of glitch : #1 : Suddenly, dropped packets surges up,
and I get "1000 dropped' yellow msg #2 : On other trials, I get '...contains
no image...'.) So, I figured I should first give a Linux a chance,
before spending more effort trying to resolve the glitches on Windows.]

  


  My first snag, was learning that 'dshow' seems to be specific to 'Windows',
and thus ffmpeg is getting 'unknown' for my reference to 'dshow'. After more hours of 'guessing', I've finally learned/concluded that there are other things
(something call "DeckLink" is one such alternative ?) for Linux, but I'm unclear
what extra Linux packages might exist for ffmpeg support, or whether I will need to built a more complete 'ffmpeg' (e.g. from source code), to get things going under Linux ?

  


  Is my device able to be accessed from some tools other than 'ffmpeg' ?
(e.g. VLC or Handbrake or whatever ?) more easily, on the Linux platform ?

  


  [If I had to, I'd probably invest another $20-$50 in some other hardware
device that goes from HDMI-to-USB (USB-A/B), if it were ]

  


  All ideas are welcome...(TIA)

  


  — Dave