Recherche avancée

Sur d’autres sites (14430)

• 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;
}


  


• Anomalie #4123 : Porte Plume : focus gênant dans certains cas

  4 avril 2018, par Mathieu L

  Ca fonctionne en effet avec FF.

  Le bug est présent avec Chrome et Safari.
  J’utilise SPIP 3.2.1 mais j’ai eu ce comportement depuis très longtemps sans avoir jamais pu le rendre reproductible, jusqu’à aujourd’hui.

  Exemple : https://media.giphy.com/media/3BMAtSczdIV2uhQq0B/giphy.gif