Sur d’autres sites (4793)

• Capture raw video byte stream for real time transcoding

  9 septembre 2012, par user1145905

  I would like to achieve the following :

  Set up a proxy server to handle video requests by clients (for now, say all video requests from any Android video client) from a remote video server like YouTube, Vimeo, etc. I don't have access to the video files being requested, hence the need for a proxy server. I have settled for Squid. This proxy should process the video signal/stream being passed from the remote server before relaying it back to the requesting client.

  To achieve the above, I would either

  1. Need to figure out the precise location (URL) of the video resource being requested, download it really fast, and modify it as I want before HTTP streaming it back to the client as the transcoding continues (simultaneously, with some latency)

  2. Access the raw byte stream, pipe it into a transcoder (I'm thinking ffmpeg) and proceed with the streaming to client (also with some expected latency).

  Option #2 seems tricky to do but lends more flexibility to the kind of transcoding I would like to perform. I would have to actually handle raw data/packets, but I don't know if ffmpeg takes such input.

  In short, I'm looking for a solution to implement real-time transcoding of videos that I do not have direct access to from my proxy. Any suggestions on the tools or approaches I could use ? I have also read about Gstreamer (but could not tell if it's applicable to my situation), and MPlayer/MEncoder.

  And finally, a rather specific question : Are there any tools out there that, given a YouTube video URL, can download the byte stream for further processing ? That is, something similar to the Chrome YouTube downloader but one that can be integrated with a server-side script ?

  Thanks for any pointers/suggestions !

• error in hls play video streaming with ffmpeg real time manipulation

  4 août 2019, par Mohsen Rahnamaei

  I am using fluent ffmpeg to write something on video streaming real-time
  means that I am using this tool to write text on every ts file which server wants to serve in order to response the hls request from client :
  in server iam using this code :

  res.setHeader('Content-Type', CONTENT_TYPE.SEGMENT)
  
  res.statusCode = 200
  
  var proc = ffmpeg(req.filePath).videoFilters({
  
        filter: 'drawtext',
  
        options: {
  
          text: 'VERY LONG TEXT VERY VERY VERY VERY LOL!!!',
  
          fontsize: 36,
  
          fontcolor: 'white',
  
          x: '(main_w/2-text_w/2)',
  
          y: '(text_h/2)+15',
  
          shadowcolor: 'black',
  
          shadowx: 2,
  
          shadowy: 2
  
        }
  
      }
  
  
  
    )
  
  
  
  
  
    .videoCodec('libx264')
  
  
  
    .audioCodec('aac')
  
  
  
  
  
    .format('mpegts')
  
  
  
    .on('end', function (stdout, stderr) {
  
  
  
      console.log('Transcoding succeeded !', req.filePath);
  
  
  
    })
  
  
  
    .on('error', function (err) {
  
      console.log('an error happened: ' + err.message);
  
    }).pipe(res, {
  
      end: true
  
    })

  but in client just play first ts file and after that, I get this log in the console :

  [log] > AVC:6798 ms overlapping between fragments detected
  
  blob:http://demo.jwp…a8dc-56b513684988:1 
  
  [log] > Video/PTS/DTS adjusted: 6798/6798,delta:-6798 ms
  
  blob:http://demo.jwp…a8dc-56b513684988:1 

  and a bunch of this log :

  [warn] > Dropping 1 audio frame @ 6.805s due to 6797 ms overlap.

  what should I do ?????

• Revision 46ea9ec719 : Enable real-time version reference motion vector search This commit enables a f

  24 juin 2014, par Jingning Han

  Changed Paths :
   Modify /vp9/common/vp9_mvref_common.c

  
   Modify /vp9/common/vp9_mvref_common.h

  
   Modify /vp9/encoder/vp9_pickmode.c

  
  
  Enable real-time version reference motion vector search

  This commit enables a fast reference motion vector search scheme.
  It checks the nearest top and left neighboring blocks to decide the
  most probable predicted motion vector. If it finds the two have
  the same motion vectors, it then skip finding exterior range for
  the second most probable motion vector, and correspondingly skips
  the check for NEARMV.

  The runtime of speed -5 goes down
  pedestrian at 1080p 29377 ms -> 27783 ms
  vidyo at 720p 11830 ms -> 10990 ms
  i.e., 6%-8% speed-up.

  For rtc set, the compression performance
  goes down by about -1.3% for both speed -5 and -6.

  Change-Id : I2a7794fa99734f739f8b30519ad4dfd511ab91a5