Recherche avancée

Sur d’autres sites (14999)

• VLC syntax to transcode and stream to stdout ?

  19 novembre 2016, par Will Tower

  Goal : I am trying to use VLC as a local server to expand the video capabilities of an app created with Adobe AIR, Flex and Actionscript. I am using VLC to stream to stdoutand reading that output from within my app.

  VLC Streaming capabilities
  VLC Flash Video
  Stream VLC to Website with asf and Flash

  Status : I am able to launch VLC as a background process and control it through its remote control interface (more detail). I can load, transcode and stream a local video file. The example app below is a barebones testbed demonstrating this.

  Issue : I am getting data in to my app but it is not rendering as video. I don’t know if it is a problem with my VLC commands or with writing to/reading from stdout. This technique of reading from stdout in AIR works (with ffmpeg for example).

  One of the various transcoding commands I have tried :

  -I rc  // remote control interface  
  
  -vvv   // verbose debuging  
  
  --sout  // transcode, stream to stdout 
  
  "#transcode{vcodec=FLV1}:std{access=file,mux=ffmpeg{mux=flv},dst=-}"

  This results in data coming into to my app but for some reason it is not rendering as video when using appendBytes with the NetStream instance.

  If instead I write the data to an .flv file, a valid file is created – so the broken part seems to be writing it to stdout. One thing I have noticed : I am not getting metadata through the stdout`method. If I play the file created with the command below, I do see metadata.

  // writing to a file
  
  var output:File = File.desktopDirectory.resolvePath("stream.flv");
  
  var outputPath:String = output.nativePath;
  
  "#transcode{vcodec=FLV1}:std{access=file,mux=ffmpeg{mux=flv},dst=" + outputPath + "}");

  ---

  Hoping someone sees where I am going wrong here.

  ---

  Update 1 : Just to add some more detail (!) – I took a look at the .flv file that is generated to examine the metadata. It appears at the head of the file as shown below. I have the correct onMetaData handler set up and see a trace of this data if I play the file from disk. I do not see this trace when reading from stdout and NetStream is in Data Generation mode. Is it possible that it isn’t getting sent to stdout for some reason ? I’ve tried generating my own header and appending that before the stream starts – I may not have the header format correct.

  

  ---

  Update 2 : So in my AIR app I was able to crudely parse the incoming stdout stream coming from VLC. I wanted to see if the FLV header data was being sent – and it appears that it is. I don’t know if it is in the correct format, etc. but as I mention above, if I write to an .flv file instead of stdout, a valid .flv file is created.

  Completely at a loss now – have tried everything I could think of and followed up every web link I could find on the issues involved. Alas – so close and it would have been so cool to leverage VLC from within AIR.

• Normalise video aspect ratio with ffmpeg

  4 juillet 2022, par Benjamin Tamasi

  I'm parsing a video stream from an application that receives an h264 stream and writes it to a file. (The frame data is an unencrypted depacketized H.264 elementary stream).

  


  I use ffmpeg to resize it to a fixed resolution. (I overlay it on a black canvas with -f lavfi -i color=c=black:s=1920x1080:r=30) and -filter_complex [1][0]scale2ref=w='if(gt(mdar\,dar),iw,oh*mdar)':h='if(gt(mdar\,dar),ow/mdar,ih)'[2mp4][base];[base][2mp4]overlay=x='(W-w)/2':y='(H-h)/2':eof_action=pass[vout]

  


  My issue is, that since this stream is coming from a phone's camera, whenever the orientation of the phone changes, the stream's aspect ratio changes. It can go from portrait to landscape, and back, in the same stream. When I open the file in vlc, it handles it quite nicely by resizing the window of the player to match the aspect ratio as it changes.

  


  How can I "normalise" the video, so it's always nicely overlayed on my black canvas as the aspect ratio changes ? Currently it's just using the initial aspect ratio, and if that changes mid stream, it will ignore the change, effectively distorting the stream by squishing or stretching it.

  


  Is there some way I can get ffmpeg to do this ?

  


• Rate-Control management in ffmpeg

  28 février 2014, par alexbuisson

  Hi I try to understand how ffmpeg wrap its rc_max_rate parameters to the x264 parameters
  and I'm wondering what the following code means ? It's a piece of code coming from ffmpeg/libavcodec/mpeg_video_enc.c but the commit log is not explicit and I don't know from where those Magic Number come from !

  So if you have an idea or an URL that can explain why those formula where implemented, it will be useful.

  if (avctx->rc_max_rate && !avctx->rc_buffer_size) {
  
          switch(avctx->codec_id) {
  
          case AV_CODEC_ID_MPEG1VIDEO:
  
          case AV_CODEC_ID_MPEG2VIDEO:
  
              avctx->rc_buffer_size = FFMAX(avctx->rc_max_rate, 15000000) * 112L / 15000000 * 16384;
  
              break;
  
          case AV_CODEC_ID_MPEG4:
  
          case AV_CODEC_ID_MSMPEG4V1:
  
          case AV_CODEC_ID_MSMPEG4V2:
  
          case AV_CODEC_ID_MSMPEG4V3:
  
              if       (avctx->rc_max_rate >= 15000000) {
  
                  avctx->rc_buffer_size = 320 + (avctx->rc_max_rate - 15000000L) * (760-320) / (38400000 - 15000000);
  
              } else if(avctx->rc_max_rate >=  2000000) {
  
                  avctx->rc_buffer_size =  80 + (avctx->rc_max_rate -  2000000L) * (320- 80) / (15000000 -  2000000);
  
              } else if(avctx->rc_max_rate >=   384000) {
  
                  avctx->rc_buffer_size =  40 + (avctx->rc_max_rate -   384000L) * ( 80- 40) / ( 2000000 -   384000);
  
              } else
  
                  avctx->rc_buffer_size = 40;
  
              avctx->rc_buffer_size *= 16384;
  
              break;
  
          }
  
          if (avctx->rc_buffer_size) {
  
              av_log(avctx, AV_LOG_INFO, "Automatically choosing VBV buffer size of %d kbyte\n", avctx->rc_buffer_size/8192);
  
          }
  
      }