Recherche avancée

Sur d’autres sites (6235)

• Streaming a video to multiple end users with node.js and ffmpeg

  9 juin 2023, par Nick Knapp

  I'm designed an API endpoint with node.js and express which will accept a url from a different part of the application, convert it into a webm stream, and allow multiple different end users to receive the end result without too much backend processing.

  


  I'd like to have the process running once and pipe the resulting stream to n endpoint calls without using temp files to hold it. So far, all of my attempts to store the output in a temporary object have failed.

  


  What would be the best method of going about doing this ?

  


  The following does not work, but is an example of what I've been trying to do.

  


  import express from 'express';
import cors from 'cors';
import FfmpegCommand from 'fluent-ffmpeg';
import stream from 'stream';

const app = express();
const port = 3002;
const activeStreams = {};

app.use(cors());

app.get('/video/stream', (req, res) => {

  var streamUrl = new URL(req.query.streamurl);
  var protocol = streamUrl.protocol;

  if (activeStreams[streamUrl] === undefined) {
    activeStreams[streamUrl] = new stream.Duplex();
    if (['udp:', 'rtmp:', 'rtsp:'].includes(protocol)) {
      FfmpegCommand(path)
      .toFormat('webm')
      .on('error', function(err, stdout, stderr) {
          console.log('an error occurred', err.message);
          console.log("stdout:\n" + stdout);
          console.log("stderr:\n" + stderr);
      })
      .pipe(activeStreams[streamUrl], {end: true});
    }
    activeStreams[streamUrl].read().pipe(res);
  } else {
    activeStreams[streamUrl].read().pipe(res);   
  }
});


  


• How can I allow my users to combine audio and video tracks for downloading a youtube video ? [closed]

  1er décembre 2023, par Faizan Ahanger

  I have a website which, along a bunch a text, has a embedded youtube videos to play. I want to allow my users to also a be able to download those videos. There are too many videos there to store on my own server and I know that there are already website like y2mate.com and savefrom.net which do this.

  


  I used yt-dlp and using the --print-json parameter I can get the urls for downloading the files but the audio and video tracks are not combined for higher videos. Using ffmpeg seems to be the obvious solution but I don't understand where the videos should be combined. Should I download both needed tracks on my server and combine them before serving it to users ? This seems very inefficient as it take a lot of bandwidth for handling all download requests. There is also this library ffmpeg.wasm which according to them is "a pure WebAssembly / JavaScript port of FFmpeg enabling video & audio record, convert and stream right inside browsers !"

  


  This should work but it will require the users to download a 30MB webapp before they can download any video. This is also not very efficient, especially if they are downloading a video which is only a few MBs in size.

  


  Are these the only two options that I have or is there a better way to do this ?

  


• On WebP and Academic Exercises

  2 octobre 2010, par Multimedia Mike — General

  Yesterday, Google released a new still image format called WebP. To those skilled in the art, this new format will be recognizable as a single VP8 golden frame with a 20-byte header slapped on the front (and maybe a little metadata thrown in for good measure). We have a MultimediaWiki page and a sample ready to go.

  Further, I submitted a patch to ffmpeg-devel for FFmpeg’s img2 handling system to decode these files. FFmpeg should support processing these files soon… if anyone cares. This leads into…

  The Point, or Lack Thereof
  Since yesterday’s release, I have read a whirlwind of commentary about this format, much of it critical and of the “what’s the point ?” variety. For my part, I can respect academic exercises, a.k.a., just trying random stuff to see if you can make it work. That’s pretty much this blog’s entire raison d’être. But WebP transcends mere academic exercise ; Google seems to be trying to push it as a new web standard. I don’t see how the format can go anywhere based on criticisms raised elsewhere — e.g., see Dark Shikari’s thoughtful write-up — which basically boil down to WebP not solving any real problems, technical, legal, or otherwise.

  How did WebP come to be ? I strongly suspect some engineers noticed that JPEG is roughly the same as an MPEG-1 intraframe, so why not create a new still frame format based on VP8 intraframes ? Again, I can respect that thinking– I have pondered how a still image format would perform if based on VP3/Theora or Sorenson Video 1.

  Technically
  Google claims a significant size savings for WebP vs. standard JPEG. Assuming that’s true (and there will be no shortage of blog posts to the contrary), it will still be some time before WebP support will find its way into the majority of the web browser population.

  But this got me thinking about possible interim solutions. A website could store images compressed in both formats if it so chose. Then it could serve up a WebM image if the browser could support it, as indicated by the ‘Accept’ header in the HTTP request. It seems that a website might have to reference a generic image name such as <img src="some-picture.image"> ; the web server would have to recognize the .image extension and map it to either a .jpg or a .webp image depending on what the browser claims it is capable of displaying.

  Leftovers
  I appreciate that Dark Shikari has once again stuck his neck out and made a valiant — though often futile — effort to educate the internet’s masses. I long ago resigned myself to the fact that many people aren’t going to understand many of the most basic issues surrounding multimedia technology (i.e., moving pictures synchronized with audio). But apparently, this extends to still image formats as well. It was simultaneously humorous and disheartening to see commenters who don’t even understand the application of, e.g., PNG vs. JPEG : Ahem, “We already have a great replacement for jpg : .PNG”. Coupled with the typical accusations of MPEG tribalism, I remain impressed D. Shikari finds the will to bother.

  Still, I appreciate that the discussion has introduced me to some new image formats of which I was previously unaware, such as PGF and JPEG XR.