Recherche avancée

Sur d’autres sites (2007)

• ffmpeg Windows stream desktop real time to web

  14 avril 2019, par ilapasle

  Hello i want to stream my Windows desktop in realtime with ffmpeg

  for capture desktop i use this code :

  ffmpeg.exe -f gdigrab -framerate 60 -i desktop output.mkv

  it’s work

  Now i not want to record video of my desktop but stream my desktop and view this in web browser.
  i need to export stream video in m3u8 file

  i have use this code :

  ffmpeg.exe -f gdigrab -framerate 60 -i desktop -c:v libx264 -crf 18 -maxrate 400k -bufsize 1835k -pix_fmt yuv420p -hls_time 10 -hls_wrap 6 output.m3u8

  in my current dir i have 6 ts file and output.m3u8 but i can not open output.m3u8 file, the file is empty why ?

  i want to read this file in web browser like this code :

      
  
  
  
  
  
  
  
  <div>
  
  <video autoplay="true" controls="controls" width="640" height="480">
  
  <source src="output.m3u8" type="application/x-mpegURL"></source>
  
  Your browser does not support HTML5 streaming!
  
  </video>
  
  </div>

  thanks for advance for your help

• avformat/mpegenc : Ensure packet queue stays valid

  15 février 2021, par Andreas Rheinhardt

  avformat/mpegenc : Ensure packet queue stays valid
  The MPEG-PS muxer uses a custom queue of custom packets. To keep track
  
  of it, it has a pointer (named predecode_packet) to the head of the
  
  queue and a pointer to where the next packet is to be added (it points
  
  to the next-pointer of the last element of the queue) ; furthermore,
  
  there is also a pointer that points into the queue (called premux_packet).
  The exact behaviour was as follows : If premux_packet was NULL when a
  
  packet is received, it is taken to mean that the old queue is empty and
  
  a new queue is started. premux_packet will point to the head of said
  
  queue and the next_packet-pointer points to its next pointer. If
  
  predecode_packet is NULL, it will also made to point to the newly
  
  allocated element.
  But if premux_packet is NULL and predecode_packet is not, then there
  
  will be two queues with head elements premux_packet and
  
  predecode_packet. Yet only elements reachable from predecode_packet are
  
  ever freed, so the premux_packet queue leaks.
  
  Worse yet, when the predecode_packet queue will be eventually exhausted,
  
  predecode_packet will be made to point into the other queue and when
  
  predecode_packet will be freed, the next pointer of the preceding
  
  element of the queue will still point to the element just freed. This
  
  element might very well be still reachable from premux_packet which
  
  leads to use-after-frees lateron. This happened in the tickets mentioned
  
  below.
  Fix this by never creating two queues in the first place by checking for
  
  predecode_packet to know whether the queue is empty. If premux_packet is
  
  NULL, then it is set to the newly allocated element of the queue.
  Fixes tickets #6887, #8188 and #8266.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/mpegenc.c

• Remove Plan 9 support

  29 novembre 2016, par Diego Biurrun

  Remove Plan 9 support
  Supporting the system was a nice joke for the 9 release, but it has
  
  run its course. Nowadays Plan 9 receives no testing and has no
  
  practical usefulness.
  

  • [DBH] Makefile
  • [DBH] compat/plan9/head
  • [DBH] compat/plan9/main.c
  • [DBH] compat/plan9/printf
  • [DBH] configure
  • [DBH] doc/platform.texi
  • [DBH] libavformat/os_support.h
  • [DBH] library.mak
  • [DBH] tests/checkasm/Makefile