[Ffmpeg-devel-irc] ffmpeg.log.20200206

[burek]

[01:21:48 CET] <relaxed> nickname123: can you pastbin.com a command and the output so I can reproduce?
[01:21:59 CET] <relaxed> er, pastebin
[07:01:54 CET] <sagax> hi all!
[07:02:05 CET] <sagax> i can make video from picture with ffmpeg
[07:02:10 CET] <sagax> and it's great for m
[07:02:12 CET] <sagax> e
[07:02:38 CET] <sagax> but - how to make video from picture and move picture?
[07:38:04 CET] <funyun> hi. i use minterpolate to encode 30fps vids to 60fps. but i have one video which has some incorrect interpolation already used. how would i go about removing every other frame and then using minterpolate to go from 30fps to 60fps?
[13:29:47 CET] <funyun> hi. how can i remove every even frame of a video?
[13:30:15 CET] <BtbN> halve the fps
[13:30:39 CET] <BtbN> though that will only remove every other frame, no guarantee about even or odd numbered ones
[13:30:55 CET] <BtbN> But I guess if you skip the first one, it will adjust
[13:31:14 CET] <funyun> BtbN: thanks
[13:41:48 CET] <zerodefect> In hlsenc.c, I see there are some flags one can set for example 'temp_file'. How do I use av_dict_set() to set that? av_dict_set(&pHeaderOptions, "temp_file", 1, 0); ?
[13:45:05 CET] <BtbN> What do you mean?
[13:46:12 CET] <zerodefect> I notice that it's a flag. I do enable toggle that particular bit on the flag?
[13:46:26 CET] <zerodefect> *How do I toggle that...
[13:50:45 CET] <zerodefect> Hmmm. mIRC is giving me problems. I think I'm going to restart and try again. It keeps freezing for a few seconds.
[13:52:31 CET] <BtbN> It's a flag to the -flags options.
[13:52:38 CET] <BtbN> -s
[14:57:05 CET] <void09> what is the scalabilty of ffmpeg livestream encoding ? how many cores it can use, with x264/x265 ? assuming one wants zerolatency
[14:57:33 CET] <durandal_1707> zerolatency does not exist
[15:00:18 CET] <void09> durandal_1707: i mean the -zerolatency tune parameter :P
[15:17:47 CET] <kurosu> void09: the scalability, baring you don't use too many filters, is mainly dictated by the library/codec, its settings, and the resolution
[15:18:31 CET] <kurosu> basically, codecs can't cut things into too many pieces (eg x265 will probably use 64 pixels wide stuff)
[15:18:41 CET] <kurosu> *block-based codecs
[15:20:11 CET] <kurosu> iirc, you get very diminishing returns with x265 above 8 cores and 1080p
[15:21:04 CET] <DHE> yeah, multi-core encoding will require slice based encoding to work. scaling will be poor
[15:25:30 CET] <pagios> hi all, i am trying to achieve the lowest latency with an acceptable quality, using 30fps from source with 2.5kbps bitrate, on receiving side using a command with -g 30 , -framrate 3- . hls_init_time 1 hls_time 1 -hls flags delete segments, hls_list_size, is there any way to lower latency while preserving quality?
[15:27:36 CET] <Mavrik> Can you switch away from HLS?
[15:27:41 CET] <Mavrik> That will buy you way more than any settings.
[15:27:56 CET] <Mavrik> Also smaller GOP and smaller segments would help I guess.
[15:27:58 CET] <pagios> Mavrik, i agree with you
[15:28:06 CET] <pagios> its a requirement... not my product
[15:28:27 CET] <pagios> Mavrik, since i am using 30fps, would it make sense to lowe the -g ?
[15:28:30 CET] <DHE> for HLS, 1 second is about as small as I think you can get away with
[15:28:46 CET] <pagios> DHE, so what can be optimized in the above?
[15:29:40 CET] <DHE> some encoder settings may help. x264 (I assume that's what you're using) defaults to buffering a lot of frames. but at the same time you don't want to overdo it because quality suffers
[15:30:08 CET] <pagios> DHE,  you mean from the client software that is encoding?
[15:30:27 CET] <pagios> or from ffmpeg that is receiving the stream?
[15:30:45 CET] <pagios> and yes i am using x264
[15:32:38 CET] <DHE> fun experiment: run a test encode with ffmpeg, but make 2 small changes: input from a file rather than whatever live source you're using, and use -preset:v placebo
[15:32:55 CET] <Mavrik> I don't think you can get away from the fact
[15:32:58 CET] <Mavrik> That your segments are 1 full second
[15:33:05 CET] <pagios> forgot to meantion its a livestream
[15:33:14 CET] <DHE> that much was obvious
[15:33:26 CET] <pagios> DHE, should i play with the gop/
[15:33:58 CET] <DHE> back to the experiment: when you see the ffmpeg progress message updating, press 'Q' to shut down, but watch how long it takes to actually stop and exit. estimate how many frames it encoded during this shutdown phase
[15:34:02 CET] <DHE> no. god no.
[15:34:24 CET] <durandal_1707> best meme
[15:34:24 CET] <Mavrik> We've been running low-latency video at 15 or even 10 GOP to get lag down.
[15:34:32 CET] <Mavrik> With obvious quality effects.
[15:34:38 CET] <Mavrik> But there has to be punishment for using apple stuff
[15:34:39 CET] <Mavrik> :P
[15:34:42 CET] <pagios> Mavrik, what fps?
[15:34:52 CET] <Mavrik> 30 mostly
[15:34:55 CET] <DHE> yeah but the HLS driver will still write 1 second increments, so you'll just have 2 or 3 GOPs in a single file
[15:35:13 CET] <DHE> so you'd have to set -hls_time 0.5 or such
[15:35:19 CET] <DHE> at which point I will begin crying
[15:35:23 CET] <pagios> haha
[15:35:41 CET] <Mavrik> DHE, yeah, we didn't use ffmpegs muxer but our own
[15:35:44 CET] <pagios> so what can i do?
[15:35:46 CET] <Mavrik> But obviously you need smaller segments.
[15:35:51 CET] <Mavrik> Since HLS is shitty like that.
[15:36:07 CET] <DHE> if you want to go whole ham on experimentation, you can try: -tune zerolatency
[15:36:23 CET] <DHE> I do NOT recommend this for real video streaming, but for testing see how much this improves your latency
[15:36:42 CET] <DHE> if the results are staggering, then there are other x264 parameters that can be adjusted
[15:37:31 CET] <pagios> DHE, i tried the zerolatency it sucks had issues
[15:37:40 CET] <pagios> so what params can i check in x264
[15:37:59 CET] <DHE> never mind the quality of zerolatency. how was the latency?
[15:38:40 CET] <pagios> the stream didnt go up honestly
[15:38:53 CET] <pagios> cpu suffered
[15:39:13 CET] <furq> i don't think zerolatency will ever make a difference with hls
[15:39:20 CET] <furq> since the player always buffers two segments ahead anyway
[15:39:24 CET] <DHE> furq: I want to quantify that first though
[15:39:41 CET] <DHE> x264 will buffer enormous amounts of frames in memory for its own rate control if not manage
[15:39:43 CET] <DHE> *managed
[15:45:25 CET] <Mavrik> DHE, does zerolatency actually do anything on HLS?
[15:45:35 CET] <Mavrik> Since that just improves the encoding pipeline.
[15:45:50 CET] <Mavrik> But if the client grabs a 1sec old segment, no zerolatency will help.
[15:46:01 CET] <furq> well if it's a live input then improving the encoding pipeline will push segments out faster
[15:46:08 CET] <furq> which i assume it is
[15:50:14 CET] <furq> i'm not sure how i feel about describing disabling lookahead as "improving the encoding pipeline" but you know what i mean
[15:53:01 CET] <DHE> ^^ all of that
[15:54:11 CET] <DHE> x264, depending on settings and presets, will absolutely buffer 40-60 frames within itself for rate control reasons. with live content that's 1.3 to 2 seconds of additional latency that could be eliminated with zerolatency
[15:54:41 CET] <DHE> in practice I would just reduce the number of buffered frames way down, maybe 10 or 20. zerolatency mode sets this to 0 along with a bunch of other things
[16:04:50 CET] <pagios> so to sum up, cant do anything?
[16:29:46 CET] <pagios> DHE, you meantioned some x264 i can play with what are they
[16:30:37 CET] <DHE> pagios: -x264-params rc-lookahead=15    # or maybe 10
[16:30:58 CET] <DHE> zerolatency mode sets this to 0. don't do it quite that extreme
[16:34:07 CET] <furq> yeah zerolatency also disables bframes and cabac and some other stuff that will kill quality but make no difference here
[16:34:22 CET] <furq> and frame threading which might make a small difference but probably not enough to matter
[16:36:04 CET] <DHE> should still allow frame slicing, which isn't ideal but it better than nothing
[16:40:26 CET] <furq> pagios: probably also use the lowest -threads value you can get away with
[16:40:47 CET] <pagios> -threads 0 ?
[16:40:51 CET] <furq> no that's auto
[16:40:56 CET] <furq> that's the same as not setting it
[16:41:06 CET] <pagios> -threads 1 ?
[16:41:14 CET] <furq> if you can encode in realtime with one thread then sure
[16:41:26 CET] <furq> iirc with frame threading, every thread is +1 frame of latency
[16:41:42 CET] <furq> so if this is a 16-core box or something then that's going to be ~24 frames
[16:42:16 CET] <pagios> its a virtual machine :D with 2 cpu
[16:42:24 CET] <furq> nvm then
[16:42:50 CET] <pagios> should i use 1 thread with 2 cpu or better to leave it 0
[16:43:01 CET] <furq> i wouldn't touch it if you only have two cores
[16:44:17 CET] <pagios>  -x264-params rc-lookahead=15  tune zerolatency so this
[16:44:36 CET] <DHE> *thunk*
[16:44:39 CET] <furq> zerolatency implies lookahead 0
[16:44:43 CET] <DHE> avoid zerolatency mode
[16:44:52 CET] <furq> you can use zerolatency if you want but it'll murder the quality for no good reason
[16:45:03 CET] <furq> lookahead should give you like 90% of the gains
[16:45:21 CET] <DHE> zerolatency is good for webcam chats... and that's about it
[16:45:46 CET] <furq> yeah it's totally useless outside of webrtc
[17:01:02 CET] <bencoh> I beg to differ, but ... the usecase I know of would require a crazy-high bitrate :)
[17:04:27 CET] <furq> does it also require turning off cabac
[00:00:00 CET] --- Fri Feb  7 2020