Recherche avancée

Sur d’autres sites (11937)

• Revision 36317 : Il y a certains cas où l’on ne peut pas passer par revision_mot notamment ...

  16 mars 2010, par kent1@… — Log

  Il y a certains cas où l’on ne peut pas passer par revision_mot notamment si on s’insère dans un formulaire d’édition d’article dans un pipeline pre_edition ... On ne passe pas la gestion des conflits dans ce cas là

• avformat/matroskaenc : Don't waste bytes on BlockGroup length fields

  16 janvier 2022, par Andreas Rheinhardt

  avformat/matroskaenc : Don't waste bytes on BlockGroup length fields
  This commit uses the new EbmlWriter API to write the length fields
  
  of the BlockGroup and its descendants that are themselves Master
  
  elements (namely BlockAdditions and BlockMore) on the least amount of
  
  bytes.
  This fixes regressions introduced when the special code for writing
  
  general subtitles was removed. Accordingly, the binsub-mksenc and
  
  matroska-zero-length-block FATE-tests have now been reverted back
  
  to their old state again ; the advantages of this approach are evident
  
  with the matroska-vp8-alpha-remux test which up until now wrote
  
  all the length fields of all BlockGroups, BlockAdditions and BlockMore
  
  on eight bytes.
  Using the EbmlWriter API also allowed to improve locality in
  
  mkv_write_block() : E.g. both DiscardPadding as well as the
  
  BlockAdditional side-data are now directly used to add elements
  
  to the writer whereas the earlier code had to first check
  
  for whether a BlockGroup should be used and then check again
  
  (after the place where a BlockGroup would be opened if one were
  
  used) for whether there is DiscardPadding or BlockAdditional
  
  side-data to write.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/matroskaenc.c
  • [DH] tests/ref/fate/binsub-mksenc
  • [DH] tests/ref/fate/matroska-vp8-alpha-remux
  • [DH] tests/ref/fate/matroska-zero-length-block
  • [DH] tests/ref/fate/webm-dash-chapters

• How to stop ffmpeg when there's no incoming rtmp stream

  5 juillet 2016, par M. Irich

  I use ffmpeg together with nginx-rtmp.
  The thing is ffmpeg doesn’t finish the process when the stream’s finished

  I use the following command :

  ffmpeg  -i 'rtmp://localhost:443/live/test' -loglevel debug  -c:a libfdk_aac -b:a 192k -c:v libx264 -profile baseline -preset superfast -tune zerolatency -b:v 2500k -maxrate 4500k -minrate 1500k -bufsize 9000k -keyint_min 15 -g 15 -f dash -use_timeline 1 -use_template 1 -min_seg_duration 5000 -y /tmp/dash/test/test.mpd

  but even the stream’s not running ffmpeg still can’t finish the process and is waiting for the rtmp stream

  Successfully parsed a group of options.
  
  Opening an input file: rtmp://localhost:443/live/test.
  
  [rtmp @ 0x2ba2160] No default whitelist set
  
  [tcp @ 0x2ba2720] No default whitelist set
  
  [rtmp @ 0x2ba2160] Handshaking...
  
  [rtmp @ 0x2ba2160] Type answer 3
  
  [rtmp @ 0x2ba2160] Server version 13.14.10.13
  
  [rtmp @ 0x2ba2160] Proto = rtmp, path = /live/test, app = live, fname = test
  
  [rtmp @ 0x2ba2160] Server bandwidth = 5000000
  
  [rtmp @ 0x2ba2160] Client bandwidth = 5000000
  
  [rtmp @ 0x2ba2160] New incoming chunk size = 4096
  
  [rtmp @ 0x2ba2160] Creating stream...
  
  [rtmp @ 0x2ba2160] Sending play command for 'test'

  Is it possible to limit the latency time to several seconds ?

  Sorry for any possible mistakes - English’s not my native language.