Recherche avancée

Sur d’autres sites (11148)

• ffmpeg, dash manifest cannot be created due to unspecified pixel format

  24 septembre 2015, par artworkad シ

  I am using ffmpeg 2.8 on OSX.

  I try to convert a short mp4 video to webm for adaptive streaming like suggested here http://wiki.webmproject.org/adaptive-streaming/instructions-to-playback-adaptive-webm-using-dash like this :

  VP9_DASH_PARAMS="-tile-columns 6 -frame-parallel 1"
  
  
  
  ffmpeg -i t2.mp4 -c:v libvpx-vp9 -s 160x90 -b:v 250k -keyint_min 150 -g 150 ${VP9_DASH_PARAMS} -an -f webm -dash 1 video_160x90_250k.webm
  
  ffmpeg -i t2.mp4 -c:a libvorbis -b:a 128k -vn -f webm -dash 1 audio_128k.webm
  
  
  
  ffmpeg \
  
   -f webm_dash_manifest -i video_160x90_250k.webm \
  
   -f webm_dash_manifest -i audio_128k.webm \
  
   -c copy -map 0 -map 1 \
  
   -f webm_dash_manifest \
  
   -adaptation_sets "id=0,streams=0 id=1,streams=1" \
  
   manifest.mpd

  However this gives me a warning unspecified pixel format :

  [webm_dash_manifest @ 0x7f9414812800] Could not find codec parameters for stream 0 (Video: vp9, none, 160x90): unspecified pixel format
  
  Consider increasing the value for the 'analyzeduration' and 'probesize' options
  
  video_160x90_250k.webm: could not find codec parameters
  
  Input #0, webm_dash_manifest, from 'video_160x90_250k.webm':
  
    Metadata:
  
      encoder         : Lavf56.36.100
  
    Duration: 00:00:09.97, bitrate: 111 kb/s
  
      Stream #0:0: Video: vp9, none, 160x90, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default)
  
      Metadata:
  
        webm_dash_manifest_duration: 9969
  
        webm_dash_manifest_initialization_range: 437
  
        webm_dash_manifest_file_name: video_160x90_250k.webm
  
        webm_dash_manifest_track_number: 1
  
        webm_dash_manifest_cues_start: 139297
  
        webm_dash_manifest_cues_end: 139399
  
        webm_dash_manifest_bandwidth: 99164
  
        webm_dash_manifest_cluster_keyframe: 1
  
        webm_dash_manifest_cue_timestamps: 0,2085,4171,6256,8342
  
  Input #1, webm_dash_manifest, from 'audio_128k.webm':
  
    Metadata:
  
      encoder         : Lavf56.36.100
  
    Duration: 00:00:10.01, bitrate: 120 kb/s
  
      Stream #1:0: Audio: vorbis, 48000 Hz, stereo, fltp (default)
  
      Metadata:
  
        webm_dash_manifest_duration: 10009
  
        webm_dash_manifest_initialization_range: 4697
  
        webm_dash_manifest_file_name: audio_128k.webm
  
        webm_dash_manifest_track_number: 1
  
        webm_dash_manifest_cues_start: 151174
  
        webm_dash_manifest_cues_end: 151240
  
        webm_dash_manifest_bandwidth: 105517
  
        webm_dash_manifest_cluster_keyframe: 1
  
        webm_dash_manifest_cue_timestamps: 0,4999,9998
  
  Output #0, webm_dash_manifest, to 'manifest.mpd':
  
    Metadata:
  
      encoder         : Lavf56.36.100
  
      Stream #0:0: Video: vp9, none, 160x90 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default)
  
      Metadata:
  
        webm_dash_manifest_duration: 9969
  
        webm_dash_manifest_initialization_range: 437
  
        webm_dash_manifest_file_name: video_160x90_250k.webm
  
        webm_dash_manifest_track_number: 1
  
        webm_dash_manifest_cues_start: 139297
  
        webm_dash_manifest_cues_end: 139399
  
        webm_dash_manifest_bandwidth: 99164
  
        webm_dash_manifest_cluster_keyframe: 1
  
        webm_dash_manifest_cue_timestamps: 0,2085,4171,6256,8342
  
      Stream #0:1: Video: vorbis, none, q=2-31, 1k tbn, 1k tbc (default)
  
      Metadata:
  
        webm_dash_manifest_duration: 10009
  
        webm_dash_manifest_initialization_range: 4697
  
        webm_dash_manifest_file_name: audio_128k.webm
  
        webm_dash_manifest_track_number: 1
  
        webm_dash_manifest_cues_start: 151174
  
        webm_dash_manifest_cues_end: 151240
  
        webm_dash_manifest_bandwidth: 105517
  
        webm_dash_manifest_cluster_keyframe: 1
  
        webm_dash_manifest_cue_timestamps: 0,4999,9998
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
    Stream #1:0 -> #0:1 (copy)
  
  Press [q] to stop, [?] for help
  
  frame=    0 fps=0.0 q=-1.0 Lsize=       1kB time=00:00:00.00 bitrate=N/A    
  
  video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
  
  Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)

  Nevertheless the manifest file is created. I tried to specify the pixel format :

  -pix_fmt yuv420p

  However this did not change anything. The warning remains the same.

  Any ideas why the warning appears and how to fix this ?

• ffmpeg creating mpeg-dash chunk files too slowly resulting in 404 errors

  17 juillet 2021, par Danny

  I have a hardware encoder feeding FFmpeg to create a MPEG-DASH Low Latency stream. It works well for a while, but after letting FFmpeg run for a while and reloading the page there are many 404 errors.

  


  When that happens, the dash.js player tries to fetch the segment file on the "live edge" but the file has not been created yet by FFmpeg. For example, after running for 20-30 minutes and loading the web page player, debug code in the web server shows :

  


  2021-07-16 16:46:30.64 : GET REQUEST : /data/ott/chunk-stream0-00702.m4s
2021-07-16 16:46:30.67 : NOT FOUND. Latest files on filesystem:
    chunk-stream0-00699.m4s.tmp
    chunk-stream0-00698.m4s
    chunk-stream0-00697.m4s
    chunk-stream0-00696.m4s
    ...


  


  So you can see the browser requested chunk 702 but the latest on the server is (part of) 699. With 2 second chunks, that is 3-5 seconds of content not yet available.

  


  To analyze, I modified FFmpeg's dashenc.c to add a timestamp every time a file is opened which displays like :

  


  [dash @ 0x9b17c0] 21:48:52.935 1626443332.935  : dashenc_io_open() - opened /data/ott/chunk-stream0-00060.m4s.tmp


  


  And loaded the timestamps into Excel.

  


  Despite a segment duration of 2.000 seconds, the average time between file opens is 2.011 seconds. Over two hours this accumulated to a 45 second difference between the calculated live edge and the latest file on the server.

  


  The HW encoder is set to 25 fps and a GOP size of 5. I've confirmed both by analyzing the H.264 NALUs output by the HW encoder.

  


  My Question : Is this a bug in FFmpeg or can I avoid this problem by adjusting the settings of either the HW encoder and/or FFmpeg options ?

  


  REFERENCE

  


  FFmpeg: Version 4.4 
Centos 8 
Apache 2.4.37


  


  FFmpeg command line (pipe is fed by process reading HW encoder)

  


  ffmpeg -re -loglevel verbose -an -f h264 -i pipe:17 -c:v copy \
-f dash -dash_segment_type mp4 -b:v 1000000 -seg_duration 2.000000 \
-frag_type duration -frag_duration 0.200000 -target_latency 1 \
-window_size 10 -extra_window_size 5 -remove_at_exit 1 -streaming 1 \
-ldash 1 -use_template 1 -use_timeline 0 -write_prft 1 -avioflags direct \
-fflags +nobuffer+flush_packets -format_options movflags=+cmaf \
-utc_timing_url /web/be/time.php /data/ott/master.mpd


  


  Modified dash_io_open() from dashenc.c

  


  static int 
dashenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename, AVDictionary **options)
{
    DASHContext *c = s->priv_data;
    int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
    int err = AVERROR_MUXER_NOT_FOUND;
    if (!*pb || !http_base_proto || !c->http_persistent)
    {
        err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);

        // My Debug
        {
            char buf[20], milli[60];
            struct timeb tp;

            ftime(&tp); // sec + ms
            struct tm *tmInfo = localtime(&tp.time);

            // 2020-05-15 21:15:12.123
            strftime(buf, sizeof(buf), "%H:%M:%S", tmInfo);
            snprintf(milli, 59, "%s.%03d %d.%03d ", buf, tp.millitm, tp.time, tp.millitm);

            av_log(s, AV_LOG_INFO, "%s : dashenc_io_open() - opened %s\n", milli, filename);
        }
    }
    return err;
}


  


• APPLY Strong to Buffer rule. Quit Switching Bit rates MPEG DASH

  14 juillet 2015, par Vinay

  I am using mpeg dash for adaptive bit rate streaming of video from my server.

  I have used ffmpeg and MP4Box to generate 4 different quality video files from my source .mp4

  The .mpd file generated has the below code

  <?xml version="1.0"?>
  
  
  
  <mpd xmlns="urn:mpeg:dash:schema:mpd:2011" minbuffertime="PT1.500000S" type="static" mediapresentationduration="PT0H3M1.42S" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011">
  
   <programinformation moreinformationurl="http://gpac.sourceforge.net">
  
    
  
   </programinformation>
  
  
  
   <period duration="PT0H3M1.42S">
  
    <adaptationset segmentalignment="true" maxwidth="1920" maxheight="1080" maxframerate="24" par="16:9" lang="und" subsegmentstartswithsap="1">
  
     <representation mimetype="video/mp4" codecs="avc1.64000d" width="320" height="240" framerate="24" sar="1:1" startwithsap="1" bandwidth="375715">
  
      <baseurl>400_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="904-1403">
  
        <initialization range="0-903"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.640015" width="420" height="270" framerate="24" sar="1:1" startwithsap="1" bandwidth="644824">
  
      <baseurl>700_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="905-1404">
  
        <initialization range="0-904"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.64001f" width="1024" height="576" framerate="24" sar="1:1" startwithsap="1" bandwidth="1349484">
  
      <baseurl>1500_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="905-1404">
  
        <initialization range="0-904"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.64001f" width="1280" height="720" framerate="24" sar="1:1" startwithsap="1" bandwidth="2264379">
  
      <baseurl>2500_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="905-1404">
  
        <initialization range="0-904"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.640028" width="1920" height="1080" framerate="24" sar="1:1" startwithsap="1" bandwidth="3633049">
  
      <baseurl>4000_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="906-1405">
  
        <initialization range="0-905"></initialization>
  
      </segmentbase>
  
     </representation>
  
    </adaptationset>
  
   </period>
  
  </mpd>

  I am using video.js along with dash.js to playback the mpeg dash content on client side. The issue is that the video doesn’t playback perfectly when i simulate network conditions from chrome dev tools.

  It works at times and it doesn’t at others. For ex the stream starts with bit rate of 400kbps and then detects enough bandwidth available so it switches to 2500kbps. Then when i bring down my bandwidth to 400kbps again then the video freezes at some point of time.

  At times the video freezes after few initial seconds of playback when it tries to switch the stream. I think there might be some command line parameter that i am missing while generating my video files via ffmpeg or generating .mpd file via MP4Box.

  below are the commands i use for ffmpeg and MP4Box

  ffmpeg -y -i inputfile -c:a libfdk_aac -ac 2 -ab 128k -c:v libx264 -r 24 – g 24 -b:v 1500k -maxrate 1500k -bufsize 1000k -vf "scale=-1:720" outputfile.mp4
  
  
  
  
  
  MP4Box -dash [DURATION] -rap -frag-rap -profile [PROFILE] -out [path/to/outpout.file] [path/to/input1.file] [path/to/input2.file] [path/to/input3.file]

  Also while i am generating .mpd files via MP4Box i am getting below warning in console

  [DASH]: Files have non-proportional track layouts (320x240 vs 420x270) but sample size and aspect ratio match, assuming precision issue
  
  [DASH]: Files have non-proportional track layouts (320x240 vs 1024x576) but sample size and aspect ratio match, assuming precision issue
  
  [DASH]: Files have non-proportional track layouts (320x240 vs 1280x720) but sample size and aspect ratio match, assuming precision issue
  
  [DASH]: Files have non-proportional track layouts (320x240 vs 1920x1080) but sample size and aspect ratio match, assuming precision issue

  Whenever the video stops playing the chrome console has these logs

  Number of times the buffer has run dry: 25
  
  Apply STRONG to buffer rule.
  
  Quit switching bit rates.

  I don’t have any clue as to why the buffers run dry and it stops switching the bit rates.

  Anything that is predominantly wrong in the process ?