Recherche avancée

Sur d’autres sites (4766)

• FATE Under New Management

  2 août 2010, par Multimedia Mike — FATE Server

  At any given time, I have between 20-30 blog posts in some phase of development. Half of them seem to be contemplations regarding the design and future of my original FATE system and are thus ready for the recycle bin at this point. Mans is a man of considerably fewer words, so I thought I would use a few words to describe the new FATE system that he put together.

  Overview
  Here are the distinguishing features that Mans mentioned in his announcement message :

  • Test specs are part of the ffmpeg repo. They are thus properly versioned, and any developer can update them as needed.
  • Support for inexact tests.
  • Parallel testing on multi-core systems.
  • Anyone registered with FATE can add systems.
  • Client side entirely in POSIX shell script and GNU make.
  • Open source backend and web interface.
  • Client and backend entirely decoupled.
  • Anyone can contribute patches.

  Client
  The FATE build/test client source code is contained in tests/fate.sh in the FFmpeg source tree. The script — as the extension implies — is a shell script. It takes a text file full of shell variables, updates source code, configures, builds, and tests. It’s a considerably minor amount of code, especially compared to my original Python code. Part of this is because most of the testing logic has shifted into FFmpeg itself. The build system knows about all the FATE tests and all of the specs are now maintained in the codebase (thanks to all who spearheaded that effort— I think it was Vitor and Mans).

  The client creates a report file which contains a series of lines to be transported to the server. The first line has some information about the configuration and compiler, plus the overall status of the build/test iteration. The second line contains ’./configure’ information. Each of the remaining lines contain information about an individual FATE test, mostly in Base64 format.

  Server
  The server source code lives at http://git.mansr.com/?p=fateweb. It is written in Perl and plugs into a CGI-capable HTTP server. Authentication between the client and the server operates via SSH/SSL. In stark contrast to the original FATE server, there is no database component on the backend. The new system maintains information in a series of flat files.

• 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