Recherche avancée

Sur d’autres sites (10509)

• What does FFmpeg expect me to send to the first rawvideo input pipe ?

  23 octobre 2023, par Somebody

  I'm using two named pipes, in order :

  


  

  1. video_pipe


     -f rawvideo
-video_size 1x1
-pix_fmt gray
-r 1


     


  


  2. audio_pipe


     -f s16le
-ar 32000
-channels 1


     


  


  


  I thought FFmpeg needed to read individual frames from a rawvideo pipe but I must be mistaken cause it doesn't start reading from the second pipe until I feed 11 bytes to the first pipe although, in the example given, a grayscale frame of one pixel is exactly one byte. I have experimenting by increasing video_size and here's the table I could infer :

  


  





  


  


  


  


  



  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  Actual frame size in bytes	Bytes needed to be sent before to move on
  1	11
  2	17
  3	25
  4	33
  5	41
  6	49

  


  


  I can't just send multiple frames as I want to output a 1 second video.
I tested most of the parameters in this page : https://github.com/FFmpeg/FFmpeg/blob/ff5a3575fec2d49d5fae4ec1198a939e203314db/libavformat/options_table.h
but none of them solved it. (I also used "-re" with no luck).

  


  This is an example command in case you want to reproduce the issue :
ffmpeg -y -re -f rawvideo -video_size 1x1 -pixel_format gray -framerate 1 -i \\.\pipe\video_pipe -f s16le -ar 32000 -channels 1 -i \\.\pipe\audio_pipe -map 0:v:0 -map 1:a:0 out.mp4

  


  Any idea of how I could send the exact frame bytes amount instead of being forced to send way more bytes ?

  


• avutil/avstring : add a "ALL" entry and the possibility to negate matches to av_match_...

  11 février 2016, par Michael Niedermayer

  avutil/avstring : add a "ALL" entry and the possibility to negate matches to av_match_name()
  This will extend the whitelist features to allow blacklisting individual protocols and to
  
  explicitly force everything to be enabled.
  Reviewed-by : Stefano Sabatini <stefasab@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavutil/avstring.c
  • [DH] libavutil/avstring.h
  • [DH] libavutil/version.h

• movenc : Allow writing a DASH sidx atom at the start of files

  21 octobre 2014, par Martin Storsjö

  movenc : Allow writing a DASH sidx atom at the start of files
  This is mapped to the faststart flag (which in this case
  
  perhaps should be called "shift and write index at the
  
  start of the file"), which for fragmented files will
  
  write a sidx index at the start.
  When segmenting DASH into files, there’s usually one sidx
  
  at the start of each segment (although it’s not clear to me
  
  whether that actually is necessary). When storing all of it
  
  in one file, the MPD doesn’t necessarily need to describe
  
  the individual segments, but the offsets of the fragments can be
  
  fetched from one large sidx atom at the start of the file. This
  
  allows creating files for the DASH ISO BMFF on-demand profile.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/movenc.c
  • [DH] libavformat/movenc.h