Recherche avancée

Sur d’autres sites (4353)

• HLS implementation with FFmpeg

  10 août 2015, par Joseph K

  I am trying to implement HLS using FFmpeg for transcoding + segmenting but have been facing a couple of issues that have been bugging me for the past week.

  Issue

  Webserver currently receives live MP4 fragments being recorded on-the-go and needs to take care of transcoding and segmentation.

  As mp4 fragments are being received, they need to be encoded. Then segmented. If i run a segmenter (be it ffmpeg or apple mediastreamsegmenter), every mp4 fragment is being treated as a VOD by itself and I’m not being able to integrate them as part of a larger live event implementation.

  I thought of a solution where every time I receive an mp4 fragment, I first use fmpeg to concatenate it with previous ones to form the larger mp4 that I then pass to be segmented for HLS. That did not work either because the entire stream has to be re-segmented each and every time and existing TS fragments replaced by new ones that are similar yet shifted in time.

  Implementation 1

  ffmpeg -re -i fragmentX.mp4 -b:v 118k -b:a 32k -vcodec copy -preset:v veryfast -acodec aac -strict -2 -ac 2 -f mpegts -y fragmentX.ts

  I manage the m3u8 manifest on my own, deleting old fragments and appending new ones.

  When validating the stream, I find it stacked with EXT-X-DISCONTINUITY tags making the stream unwatchable.

  Implementation 2

  First combine latest fragment with overall.mp4

  ffmpeg -i "concat:newfragment.mp4|existing.mp4" -c copy overall.mp4

  Then pass the combination to ffmpeg for HLS segmentation

  ffmpeg -re -i overall.mp4 -ac 2 -r 20 -vcodec libx264 -b:v 318k -preset:v veryfast -acodec aac -strict -2 -b:a 32k -hls_time 2 -hls_list_size 3 -hls_allow_cache 0 -hls_base_url /Users/JosephKalash/Desktop/test/350/ -hls_segment_filename ’350/fragment%03d.ts’ -hls_flags delete_segments 350/index.m3u8

  Concatenation is not perfect and there are noticeable glitches where the fragments are supposed to be stitched. Segmentation replaces older fragments and the manifest is rewritten as if it’s a new HLS stream every time ffmpeg is called.

  I cannot figure out how to get this to work properly.

  Any ideas ?

• libFLAC/stream_decoder : Fix double free

  22 août 2015, par Erik de Castro Lopo

  libFLAC/stream_decoder : Fix double free
  The american-fuzzy-lop fuzzer found a couple of instances of double
  
  free() resulting from commit 15a9062609.
  The problematic free() were the ones associated with use of the
  
  safe_realloc_mul_2op_() function which can call realloc(ptr,0) which
  
  according to the realloc manpage is already an implicit free().
  

  • [DH] src/libFLAC/stream_decoder.c

• avcodec/vc1dec : Re-order init to avoid initting hwaccel too early

  8 août 2015, par Philip Langdale

  avcodec/vc1dec : Re-order init to avoid initting hwaccel too early
  At least for vdpau, the hwaccel init code tries to check the video
  
  profile and ensure that there is a matching vdpau profile available.
  If it can’t find a match, it will fail to initialise.
  In the case of wmv3/vc1, I observed initialisation to fail all the
  
  time. It turns out that this is due to the hwaccel being initialised
  
  very early in the codec init, before the profile has been extracted
  
  and set.
  Conceptually, it’s a simple fix to reorder the init code, but it gets
  
  messy really fast because ff_get_format(), which is what implicitly
  
  trigger hwaccel init, is called multiple times through various shared
  
  init calls from h263, etc. It’s incredibly hard to prove to my own
  
  satisfaction that it’s safe to move the vc1 specific init code
  
  ahead of this generic code, but all the vc1 fate tests pass, and I’ve
  
  visually inspected a couple of samples and things seem correct.
  Signed-off-by : Philip Langdale <philipl@overt.org>
  

  • [DH] libavcodec/vc1dec.c