Recherche avancée

Sur d’autres sites (11751)

• lavfi/vf_xfade : rewrite activate inputs handling

  2 juin 2023, par Marvin Scholz

  lavfi/vf_xfade : rewrite activate inputs handling
  The old code was not properly handling a bunch of edge-cases with
  
  streams terminating earlier and also did not properly report back EOF
  
  to the first input.
  This fixes at least one case where the filter could stop doing
  
  anything :
  ffmpeg -f lavfi -i "color=blue:d=10" -f lavfi -i "color=aqua:d=0" -filter_complex "[0][1]xfade=duration=2:offset=0:transition=wiperight" -f null -
  

  • [DH] libavfilter/vf_xfade.c

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


  


• RTSP to HLS conversion with error on some devices

  2 septembre 2024, par Wallace Ketler

  I'm trying to convert, on a node server, RTSP IP camera devices to HLS to run livestreams on the web. The following code works well for some RTSP devices, but for others I encounter problems.

  


     function startLive(rtspUrl, outputDir, id_local, id_camera) {
        return new Promise((resolve, reject) => {
            const processKey = `${id_local}_${id_camera}`;
            if (ffmpegProcesses[processKey]) {
                return reject(new Error('Conversão já está em andamento para esta câmera'));
            }
        
            const process = ffmpeg(rtspUrl)
                .inputOptions([
                    '-rtsp_transport', 'tcp',
                    '-fflags', 'nobuffer',
                    '-max_delay', '1000000',
                    '-analyzeduration', '1000000',
                    '-probesize', '1000000',
                    '-flush_packets', '1',
                    '-avioflags', 'direct'
                ])
                .outputOptions([
                    '-c:v', 'libx264',
                    '-preset', 'ultrafast',
                    '-tune', 'zerolatency',
                    '-c:a', 'aac',
                    '-hls_time', '10',
                    '-hls_flags', 'delete_segments',
                    '-hls_list_size', '5',
                    '-hls_wrap', '5',
                    '-strict', '-2'
                ])
                .output(path.join(outputDir, 'stream.m3u8'))
                .on('start', (commandLine) => {
                    console.log('Spawned FFmpeg with command: ' + commandLine);
                })
                .on('stderr', (stderrLine) => {
                    console.log('FFmpeg stderr: ' + stderrLine);
                })
                .on('end', () => {
                    console.log('Conversão concluída');
                    delete ffmpegProcesses[processKey]; 
                    resolve();
                })
                .on('error', (err, stdout, stderr) => {
                    console.error('Erro na conversão', err);
                    console.error('FFmpeg stdout:', stdout);
                    console.error('FFmpeg stderr:', stderr);
                    delete ffmpegProcesses[processKey]; 
                    reject(err);
                })
                .run();
    
            ffmpegProcesses[processKey] = process; 
        });
    }


  


  When the conversion succeeds, it continues indefinitely with the logs :

  


  FFmpeg stderr: frame=   61 fps= 48 q=13.0 size=N/A time=00:00:02.03 bitrate=N/A dup=60 drop=0 speed= 1.6x    
FFmpeg stderr: frame=   75 fps= 42 q=17.0 size=N/A time=00:00:02.52 bitrate=N/A dup=62 drop=0 speed=1.41x    
FFmpeg stderr: frame=   91 fps= 39 q=16.0 size=N/A time=00:00:03.04 bitrate=N/A dup=65 drop=0 speed=1.31x    
FFmpeg stderr: frame=  108 fps= 38 q=15.0 size=N/A time=00:00:03.60 bitrate=N/A dup=68 drop=0 speed=1.27x    
FFmpeg stderr: frame=  121 fps= 36 q=24.0 size=N/A time=00:00:04.03 bitrate=N/A dup=70 drop=0 speed=1.21x    
FFmpeg stderr: frame=  138 fps= 36 q=16.0 size=N/A time=00:00:04.60 bitrate=N/A dup=73 drop=0 speed= 1.2x    
FFmpeg stderr: frame=  152 fps= 35 q=17.0 size=N/A time=00:00:05.08 bitrate=N/A dup=75 drop=0 speed=1.17x    
FFmpeg stderr: frame=  168 fps= 35 q=16.0 size=N/A time=00:00:05.60 bitrate=N/A dup=78 drop=0 speed=1.15x    
FFmpeg stderr: frame=  183 fps= 34 q=21.0 size=N/A time=00:00:06.11 bitrate=N/A dup=80 drop=0 speed=1.13x    
FFmpeg stderr: frame=  198 fps= 34 q=16.0 size=N/A time=00:00:06.60 bitrate=N/A dup=83 drop=0 speed=1.12x    
FFmpeg stderr: frame=  215 fps= 33 q=16.0 size=N/A time=00:00:07.16 bitrate=N/A dup=86 drop=0 speed=1.11x    
FFmpeg stderr: frame=  230 fps= 33 q=16.0 size=N/A time=00:00:07.66 bitrate=N/A dup=88 drop=0 speed= 1.1x    
FFmpeg stderr: frame=  246 fps= 33 q=19.0 size=N/A time=00:00:08.20 bitrate=N/A dup=91 drop=0 speed= 1.1x    


  


  And with the segments saved in the folder configured as output. But for certain devices, after creating the stream.m3u8 file and saving the first segment, the conversion is considered finished and falls into .on('end') . The error log is as follows :

  


  FFmpeg stderr: frame=    0 fps=0.0 q=0.0 size=N/A time=00:00:01.12 bitrate=N/A speed=2.08x    
FFmpeg stderr: [hls @ 0x55e00dfc4380] Opening 'my_path/stream0.ts' for writing
FFmpeg stderr: [hls @ 0x55e00dfc4380] Opening 'my_path/stream.m3u8.tmp' for writing
FFmpeg stderr: frame=    0 fps=0.0 q=0.0 Lsize=N/A time=00:00:01.37 bitrate=N/A speed= 2.5x    
FFmpeg stderr: video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
FFmpeg stderr: [aac @ 0x55e00dfff840] Qavg: 65536.000
FFmpeg stderr: 
Conversão concluída


  


  The muxing overhead: unknown only appears when the error occurs and the conversion is complete.

  


  I've already tried changing the video and audio encoders, as well as the various input and output parameters of the conversion. I also tried updating ffmpeg (it's already on the latest version, using fluent-ffmpeg, "fluent-ffmpeg": "^2.1.3",)

  


  I would like to understand why this happens on some devices and how to fix it. Thanks.