Recherche avancée

Sur d’autres sites (7560)

• On the fly transcoding and HLS streaming with ffmpeg

  12 janvier 2023, par syfluqs

  I am building a web application that involves serving various kinds of video content. Web-friendly audio and video codecs are handled without any problems, but I am having trouble designing the delivery of video files incompatible with HTML5 video players like mkv containers or H265.

  



  What I have done till now, is use ffmpeg to transcode the video file on the server and make HLS master and VOD playlists and use hls.js on the frontend. The problem, however, is that ffmpeg treats the playlist as a live stream playlist until transcoding is complete on the whole file and then it changes the playlist to serve as VOD. So, the user can't seek until the transcoding is over, and that my server has unnecessarily transcoded the whole file if the user decides to seek the video file halfway ahead. I am using the following ffmpeg command line arguments

  



  ffmpeg -i sample.mkv \
       -c:v libx264 \
       -crf 18 \
       -preset ultrafast \
       -maxrate 4000k \
       -bufsize 8000k \
       -vf "scale=1280:-1,format=yuv420p" \
       -c:a copy -start_number 0 \
       -hls_time 10 \
       -hls_list_size 0 \
       -f hls \
file.m3u8


  



  Now to improve upon this system, I tried to generate the VOD playlist through my app and not ffmpeg, since the format is self explanatory. The webapp would generate the HLS master and VOD playlists beforehand using the video properties such as duration, resolution and bitrate (which are known to the server) and serve the master playlist to the client. The client then starts requesting the individual video segments at which point the server will individually transcode and generate each segment and serve them. Seeking would be possible as the client already has the complete VOD playlist and it can request the specific segment that the user seeks to. The benefit, as I see it, would be that my server would not have to transcode the whole file, if the user decides to seek forward and play the video halfway through.

  



  Now I tried manually creating segments (10s each) from my sample.mkv using the following command

  



  ffmpeg -ss 90 \
       -t 10 \
       -i sample.mkv \
       -g 52 \
       -strict experimental \
       -movflags +frag_keyframe+separate_moof+omit_tfhd_offset+empty_moov \
       -c:v libx264 \
       -crf 18 \
       -preset ultrafast \
       -maxrate 4000k \
       -bufsize 8000k \
       -vf "scale=1280:-1,format=yuv420p" \
       -c:a copy \
fileSequence0.mp4


  



  and so on for other segments, and the VOD playlist as

  



  #EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
fileSequence0.mp4
#EXTINF:10.0,
fileSequence1.mp4
...
... and so on 
...
#EXT-X-ENDLIST


  



  which plays the first segment just fine but not the subsequent ones.

  



  Now my questions,

  



  


  1. Why don't the subsequent segments play ? What am I doing wrong ?

  


  2. Is my technique even viable ? Would there be any problem with presetting the segment durations since segmenting is only possible after keyframes and whether ffmpeg can get around this ?

  


  



  My knowledge regarding video processing and generation borders on modest at best. I would greatly appreciate some pointers.

  


• fftools/ffmpeg : add thread-aware transcode scheduling infrastructure

  18 mai 2023, par Anton Khirnov

  fftools/ffmpeg : add thread-aware transcode scheduling infrastructure
  See the comment block at the top of fftools/ffmpeg_sched.h for more
  
  details on what this scheduler is for.
  This commit adds the scheduling code itself, along with minimal
  
  integration with the rest of the program :
  
  * allocating and freeing the scheduler
  
  * passing it throughout the call stack in order to register the
  
    individual components (demuxers/decoders/filtergraphs/encoders/muxers)
  
    with the scheduler
  The scheduler is not actually used as of this commit, so it should not
  
  result in any change in behavior. That will change in future commits.
  

  • [DH] fftools/Makefile
  • [DH] fftools/ffmpeg.c
  • [DH] fftools/ffmpeg.h
  • [DH] fftools/ffmpeg_dec.c
  • [DH] fftools/ffmpeg_demux.c
  • [DH] fftools/ffmpeg_enc.c
  • [DH] fftools/ffmpeg_filter.c
  • [DH] fftools/ffmpeg_mux.c
  • [DH] fftools/ffmpeg_mux.h
  • [DH] fftools/ffmpeg_mux_init.c
  • [DH] fftools/ffmpeg_opt.c
  • [DH] fftools/ffmpeg_sched.c
  • [DH] fftools/ffmpeg_sched.h

• fate : Avoid unnecessary pixel format conversions

  30 juin 2015, par Martin Storsjö

  fate : Avoid unnecessary pixel format conversions
  Most of the fate-dds-* and fate-txd-* tests already
  
  output into the same pixel format regardless of
  
  platform endianness, so there’s no need to force
  
  conversion to another format.
  This fixes the tests fate-txd-16bpp, fate-txd-odd,
  
  fate-dds-rgb16, fate-dds-rgb24 and fate-dds-xrgb on
  
  big endian, where the tests seem to fail due to issues
  
  with certain conversion codepaths in swscale.
  Those conversion codepaths should of course be fixed, but
  
  the individual decoder tests should use as little extra
  
  conversion steps as possible.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] tests/fate/image.mak
  • [DH] tests/fate/video.mak
  • [DH] tests/ref/fate/dds-rgb16
  • [DH] tests/ref/fate/dds-rgb24
  • [DH] tests/ref/fate/dds-uyvy
  • [DH] tests/ref/fate/dds-xbgr
  • [DH] tests/ref/fate/dds-y
  • [DH] tests/ref/fate/dds-ya
  • [DH] tests/ref/fate/dds-yuyv
  • [DH] tests/ref/fate/txd-16bpp
  • [DH] tests/ref/fate/txd-odd