[FFmpeg-user] m3u8 generated with bad bandwith
Hi, We have the problem that the m3u8 always outputs the wrong bandwidth for the main stream, which we would like to loop through unprocessed. Our command is: ffmpeg -hide_banner -analyzeduration 10M \ -y -threads 0 -init_hw_device vaapi=intel:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_device intel \ -i rtmp://127.0.0.1:1935/live/test \ -level 41 -qp 23 -color_range tv -af aresample=async=1:min_hard_comp=0.10:first_pts=0 -vsync -1 -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -bf 3 -b_strategy 2 \ -muxdelay 0 -muxpreload 0 \ -max_muxing_queue_size 1024 \ -filter_complex "format=nv12,hwupload,scale_vaapi=w=1280:h=720,split=2[720p][480];[480]scale_vaapi=w=854:h=480,split=2[480p][240];[240]scale_vaapi=w=426:h=240[240p]" \ -map [720p] -c:v:0 h264_vaapi \ -map [480p] -c:v:1 h264_vaapi -b:v:1 700k -maxrate:v:1 900k \ -map [240p] -c:v:2 h264_vaapi -b:v:2 250k -maxrate:v:2 267k \ -map 0:a \ -map 0:a \ -map 0:a \ -c:a aac \ -var_stream_map "v:1,a:1 v:0,a:0 v:2,a:2" \ -output_ts_offset 0 \ -f hls -hls_flags second_level_segment_index+second_level_segment_duration+append_list+split_by_time+program_date_time+discont_start+omit_endlist -hls_start_number_source epoch -hls_time 2 -hls_list_size 3 \ -master_pl_name play.m3u8 -strftime 1 -hls_segment_filename /tmp/live/test/vs%v/%s_%%d_%%t.ts /tmp/live/test/vs%v/play.m3u8 And this is the result. The bandwidth of 140800 is wrong. #EXTM3U #EXT-X-VERSION:3 #EXT-X-STREAM-INF:BANDWIDTH=910800,RESOLUTION=854x480,CODECS="avc1.640829,mp4a.40.2" vs0/play.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=140800,RESOLUTION=1280x720,CODECS="avc1.640829,mp4a.40.2" vs1/play.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=415800,RESOLUTION=426x240,CODECS="avc1.640829,mp4a.40.2" vs2/play.m3u8 kind regards Paul Eppner -- Philipp Roggan ViStream GmbH E-Mail: philipp.roggan@vistream.online Web: https://www.vistream.online/ Hagenstraße 50 10365 Berlin Geschäftsführer: Paul Eppner Handelsregister: Amtsgericht Charlottenburg HRB 221474 B Diese E-Mail ist nur für den in der Anrede bezeichneten Empfänger bestimmt und kann vertrauliche Informationen enthalten. Falls Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen Sie sie vollständig. Vielen Dank! This email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender and delete the email from your system. Thank you! -- Philipp Roggan ViStream GmbH E-Mail: philipp.roggan@vistream.online Web: https://www.vistream.online/ Hagenstraße 50 10365 Berlin Geschäftsführer: Paul Eppner Handelsregister: Amtsgericht Charlottenburg HRB 221474 B Diese E-Mail ist nur für den in der Anrede bezeichneten Empfänger bestimmt und kann vertrauliche Informationen enthalten. Falls Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen Sie sie vollständig. Vielen Dank! This email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender and delete the email from your system. Thank you! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Increased latency from filter_complex
Hi Paul, thanks again for answering. Please show how you use sidechaincompress filter. Basically we did what is mentioned here: https://superuser.com/questions/1093607/ffmpeg-sidechaincompress-give-more-importance-to-the-sidechain We too found no audible difference between ratio 1 and ratio 20. But this all doesn't touch the initial question I contacted the mailing list for. We found that applying any ducking increased latency. by ~8 seconds and for every additional audio track it added 8 seconds on top. So it seems like the analyzing of the the audio tracks happens sequentially at least for the filters we used. What I wanted to know is, if there are ways to write those differently to mitigate this problem. In case of the sidechain filter, if this is handled sequentially too, the problem would still be there, even if a sidechain might be less workload. @all Anybody else knows how to do this in parallel instead? Thanks Philipp ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Increased latency from filter_complex
Hi Paul, thanks for your answer. 3 loudnorm calls and 2 dynaudnorm calls? for ducking there is sidechaincompress filter We tried sidechain of course, but will try this again. Our problem is, that the resulting audio from the sidechaincompress never reached the same quality. The audio from the primary channel also never got down to a level, where the secondary audio could be understood without problems. If you have any parameters or tips how to achieve this, please share. Thank you. But regarding the central difficulty, the increasing latency from - what we suspect serial instead of parallel processing of the audio channels - this does not help. Or is sidechaincompress being handled differently? Thank you for your time. Philipp ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Increased latency from filter_complex
Hi everyone, we are using ffmpeg to create hls streams in multiple resolutions and also languages from incoming rtmp streams. When encoding without the filter_complex for ducking we get a minimal latency of around 8 seconds, but the moment we add the autoducking we jump up to around 15 seconds. Also it seems that for every additional audio stream we add, it adds another 8 seconds of latency. The filter_complex is the folowing: ``` -filter_complex "format=nv12,hwupload,scale_vaapi=w=1280:h=720,split=2[720p][480];[480]scale_vaapi=w=854:h=480,split=2[480p][240];[240]scale_vaapi=w=426:h=240[240p]; \ [0:a:0] loudnorm=i=-16.0:lra=12.0:tp=-3.0, asplit=2 [normalize] [out]; \ [normalize] volume=0.1, asplit=2 [bg1] [bg2]; \ [1:a:0] agate, adelay=2900:all=1 [tmp1]; \ [bg1][tmp1] amix, dynaudnorm=b=1:p=0.35:r=1:f=150, loudnorm=i=-16.0:lra=12.0:tp=-3.0 [out1]; \ [2:a:0] agate, adelay=8000:all=1 [tmp2]; \ [bg2][tmp2] amix, dynaudnorm=b=1:p=0.35:r=1:f=150, loudnorm=i=-16.0:lra=12.0:tp=-3.0 [out2]" ´´´ To us it looks like the audio streams get processed sequentially. Each process needs to check the secondary audio levels for a few seconds, to be able to duck the main audio accordingly, resulting in the increased overall latency. Is this correct and if so, is there a way to achieve this in parallel? Or is there any other way to get the autoducking, that doesnt introduce additional latency? Thank you! Philipp PS: Full ffmpeg call in the appended textfile. This is the full call we use: ``` ffmpeg -hide_banner -loglevel info \ -y -threads 0 -init_hw_device vaapi=intel:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_device intel \ -filter_complex_threads 8 \ -thread_queue_size 8291 \ -i "rtmp://127.0.0.1:1935/live/stream" \ -i "rtmp://127.0.0.1:1935/live/stream-de" \ -i "rtmp://127.0.0.1:1935/live/stream-en" \ -level 41 -qp 23 -color_range tv \ -async 1 -vsync -1 -r 25 -g 50 -keyint_min 50 -force_key_frames "expr:gte(t,n_forced*50)" -sc_threshold 0 -bf 3 -b_strategy 2 \ -tune zerolatency -crf 23 \ -muxdelay 0 -muxpreload 0 \ -max_muxing_queue_size \ -filter_complex "format=nv12,hwupload,scale_vaapi=w=1280:h=720,split=2[720p][480];[480]scale_vaapi=w=854:h=480,split=2[480p][240];[240]scale_vaapi=w=426:h=240[240p]; \ [0:a:0] loudnorm=i=-16.0:lra=12.0:tp=-3.0, asplit=2 [normalize] [out]; \ [normalize] volume=0.1, asplit=2 [bg1] [bg2]; \ [1:a:0] agate, adelay=2900:all=1 [tmp1]; \ [bg1][tmp1] amix, dynaudnorm=b=1:p=0.35:r=1:f=150, loudnorm=i=-16.0:lra=12.0:tp=-3.0 [out1]; \ [2:a:0] agate, adelay=8000:all=1 [tmp2]; \ [bg2][tmp2] amix, dynaudnorm=b=1:p=0.35:r=1:f=150, loudnorm=i=-16.0:lra=12.0:tp=-3.0 [out2]" \ -map [720p] -c:v:0 h264_vaapi -b:v:0 2800k -maxrate:v:0 2996k -bufsize:v:0 4200k \ -map [480p] -c:v:1 h264_vaapi -b:v:1 700k -maxrate:v:1 900k -bufsize:v:1 850k \ -map [240p] -c:v:2 h264_vaapi -b:v:2 250k -maxrate:v:2 267k -bufsize:v:2 325k \ -map [out] \ -map [out1] \ -map [out2] \ -c:a aac -b:a 64k -ar 48000 -ac 1 \ -var_stream_map "v:1,agroup:aac v:0,agroup:aac v:2,agroup:aac a:0,agroup:aac,default:yes a:1,agroup:aac a:2,agroup:aac" \ -strict experimental -lhls 1 \ -f hls -hls_flags second_level_segment_index+second_level_segment_duration+append_list+split_by_time+program_date_time+discont_start -hls_start_number_source epoch -hls_time 2 -hls_list_size 3 \ -master_pl_name play2.m3u8 -strftime 1 -hls_segment_filename /var/lib/streaming/hls/live/stream/stream%v/%s_%%d_%%t.ts /var/lib/streaming/hls/live/stream/stream%v/play.m3u8 ``` ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
