Recherche avancée

Sur d’autres sites (11574)

• Adding a background to an in-video visual progress bar with FFMPEG ?

  22 septembre 2023, par Alexei Dom

  Using the answer to Showing in-video visual progress bar with FFMPEG
  


  


  I'm trying to give the progress bar itself a background, so for e.g. the bar will be white and the red progress bar over time will cover it.

  


  My first decision was to apply a drawbox filter, so for my purposes the video is 1280 pixels wide and the duration is 6.027 seconds. I've tried

  


  ffmpeg -i uuid_nordvpn.mp4 -vf "color=c=red:s=1280x30[bar];[0][bar]overlay=-w+(w/6.072733)*t:H-h:shortest=1, drawbox=x=0:y=720-30:width=1280:height=30:thickness=fill:color=white" out.mp4

  


  But I got just the white drawbox filter that was drawn on top of the color filter.

  


  The obvious solution was to swap the color and drawbox filter, but that returns an error Too many inputs specified for the "color" filter, which I guess means you can only use the color filter at the beginning.

  


  I've also tried applying 2 color filters, the other color filter instead of filling up was going down, but you can't apply 2 color filters, again giving the reason Too many inputs specified for the "color" filter.

  


  I'm completely lost at this point, how would I give a background to this filter ?

  


• avformat/hlsenc : refine EXT-X-BYTERANGE support for segments

  19 septembre 2016, par Steven Liu

  avformat/hlsenc : refine EXT-X-BYTERANGE support for segments
  refine EXT-X-BYTERANGE tag,
  
  the spec link :
  
  https://tools.ietf.org/html/draft-pantos-http-live-streaming-19#section-4.3.2.2
  
  the apple doc :
  
  https://developer.apple.com/library/ios/technotes/tn2288/_index.html#
  
  //apple_ref/doc/uid/DTS40012238-CH1-BYTE_RANGE_SUPPORT_FOR_SEGMENTS
  command line :
  
  ./ffmpeg -i /Movies/objectC/a.mp4 -c copy -f hls -hls_time 7
  
   -hls_list_size 0 -hls_segment_size 2500000 -t 40 output-test.m3u8
  
  output :
  
  localhost:ffmpeg liuqi$ ll *.ts ;cat output-test.m3u8
  
   -rw-r—r—  1 liuqi  staff  2792176  9 12 14:44 output-test0.ts
  
   -rw-r—r—  1 liuqi  staff  3112528  9 12 14:44 output-test3.ts
  
   -rw-r—r—  1 liuqi  staff  3377420  9 12 14:44 output-test6.ts
  
   -rw-r—r—  1 liuqi  staff  1228016  9 12 14:44 output-test7.ts
  
   #EXTM3U
  
   #EXT-X-VERSION:4
  
   #EXT-X-TARGETDURATION:10
  
   #EXT-X-MEDIA-SEQUENCE:0
  
   #EXTINF:9.021000,
  
   #EXT-X-BYTERANGE:1334988@0
  
   output-test0.ts
  
   #EXTINF:3.000000,
  
   #EXT-X-BYTERANGE:721356@1334988
  
   output-test0.ts
  
   #EXTINF:3.000000,
  
   #EXT-X-BYTERANGE:735832@2056344
  
   output-test0.ts
  
   #EXTINF:6.000000,
  
   #EXT-X-BYTERANGE:1645940@0
  
   output-test3.ts
  
   #EXTINF:3.000000,
  
   #EXT-X-BYTERANGE:715152@1645940
  
   output-test3.ts
  
   #EXTINF:3.000000,
  
   #EXT-X-BYTERANGE:751436@2361092
  
   output-test3.ts
  
   #EXTINF:9.000000,
  
   #EXT-X-BYTERANGE:3377420@0
  
   output-test6.ts
  
   #EXTINF:3.960000,
  
   #EXT-X-BYTERANGE:1228016@0
  
   output-test7.ts
  
   #EXT-X-ENDLIST
  
   localhost:ffmpeg liuqi$
   ticket-id : #5839
  Signed-off-by : Steven Liu <lingjiujianke@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/hlsenc.c

• ffmpeg udp/tcp stream receive frame not same as sent

  21 novembre 2013, par vivienlwt

  I am streaming a video on raspberrypi using command :

  ffmpeg -re -threads 2 -i sample_video.m2v -f mpegts - | \
  
  ffmpeg -f mpegts -i - -c copy -f mpegts udp://192.168.1.100:12345

  The remote PC with 192.168.1.100 uses ffmpeg library to listen to the input stream. For example :

  informat = ffmpeg::av_find_input_format("mpegts");
  
  avformat_open_input(&pFormatCtx, "udp://192.168.1.100:12345", informat, options);

  However, when I compute the hash value of each decoded frame on two sides (i.e. raspberrypi and PC), they DON'T MATCH at all. A weird thing is, among 2000 frames, there are in total 10 frames whose hash value are the same on the sender and receiver side. The match result look like this :

  00000....00011000...00011110000...000

  where 0 indicates non-match and 1 indicates match. The matched frame appeared 2 6 in sequence and appeared rarely while most of the other frames has different hash value.

  The hash is computed on the frame data buffer extracted using avpicture_layout(). On the Pi side, I just stream the video to a local port and there's a local process using the same code to decode and hash the frames :

  ffmpeg -re -threads 2 -i sample_video.m2v -f mpegts - | \
  
  ffmpeg -f mpegts -i - -c copy -f mpegts udp://localhost:12345
  
  ...

  The streaming source raspberry pi, is connected directly to the PC using cable. I don't think it is a packet loss problem. Because, first, I rerun the same process several times and the hash value of the received frames are the same (otherwise the result should be different because packet loss is probabilistic). Secondly, I even try to stream on tcp ://192.168.1.100:12345 (and "tcp ://192.168.1.100:12345 ?listen" on PC), and the received frame hash are still the same - different than the hash result on the Pi.

  So, does anyone know why the streaming to a remote address will yield different decoded frames ? Maybe I am missing some details.

  Thanks in advance !!