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

[burek]

[03:16:41 CEST] <Saccarab> is there a limit to maximum inputs you can provide to an amix command?
[03:21:21 CEST] <c_14> INT_MAX probably
[03:21:28 CEST] <c_14> though I guess you'll run out of memory some time before that
[03:23:35 CEST] <furq> amix AVOptions:
[03:23:35 CEST] <furq>   inputs            <int>        ..F.A.... Number of inputs. (from 1 to 1024) (default 2)
[03:23:51 CEST] <Saccarab> thanks
[03:24:20 CEST] <c_14> oh, they did actually put a limit on it
[04:10:29 CEST] <realies> what version of libmp3lame does ffmpeg use?
[04:10:36 CEST] <realies> i only get encoder         : Lavc58.35.100 libmp3lame
[04:10:47 CEST] <furq> whichever one you linked it with
[04:10:56 CEST] <realies> is there any way to find out?
[04:11:07 CEST] <realies> installed with brew under macos
[04:11:23 CEST] <furq> https://formulae.brew.sh/formula/ffmpeg
[04:11:37 CEST] <realies> wow, thanks
[04:13:21 CEST] <furq> there haven't been any quality-related updates to lame since 2011 anyway
[04:22:31 CEST] <realies> yeah just wanted to know if runs the latest, afaik lame does best mp3 encoding?
[04:23:01 CEST] <furq> yeah
[18:22:33 CEST] <aldenp> hi, so I'm trying to record my desktop+audio with ffmpeg (on Linux) and would like to use as little CPU as possible, regardless of the cost to file size, with highest possible quality. I'm currently using `-crf 0 -preset ultrafast`, with thread_queue_size set to 1024 for both video and audio, yet despite this I still get `Thread message queue blocking` errors
[18:29:50 CEST] <tdr> aldenp, are you trying too high of a framerate maybe?
[18:30:42 CEST] <aldenp> I'm recording at 60fps, since that's my monitor's native refresh rate; I'm trying to record as losslessly as possible and reencode later for better file size
[18:34:46 CEST] <aldenp> I'm not getting close to max CPU usage, although I'm guessing CPU isn't the bottleneck anyways
[18:35:48 CEST] <tdr> prob depends a lot on your hardware and exact command
[18:36:53 CEST] <aldenp> http://dpaste.com/1YK2S4G this is my exact command
[18:37:09 CEST] <tdr> https://trac.ffmpeg.org/wiki/Capture/Desktop has some tips for lossless encoding (for later re-encoding)
[18:38:13 CEST] <aldenp> I've read that already, and implemented it in my command
[18:38:28 CEST] <tdr> yeah i read your link
[18:39:59 CEST] <tdr> what kind of card do you have, are you using shared memory for it or does it support hw encoding etc?
[18:40:19 CEST] <aldenp> I just have integrated graphics
[18:41:02 CEST] <tdr> also, how many cpu cores, you said ure not maxing it, but how is your load distributed beteween cores etc?
[18:42:03 CEST] <aldenp> quad core, it's running at about 90% CPU usage of 400%; how would I check the distribution?
[18:42:47 CEST] <tdr> aldenp, several ways to do it.  htop in a terminal will show per core, or pressing 1 in top should shows per core if it doesnt by default
[18:44:43 CEST] <aldenp> it's distributed pretty evenly
[18:44:55 CEST] <aldenp> about 16% per core
[18:59:18 CEST] <aldenp> maybe this is a dumb question but is it possible to dump data recorded from x11grab directly to a file without encoding?
[19:00:47 CEST] <aldenp> I'm also experiencing audio stuttering, extremely high latency (audio is almost 2 seconds after video), and occasionally it just fails to record audio entirely despite not giving any warnings
[19:05:20 CEST] <aldenp> I get a lot of `Queue input is backward in time` warnings (even when the audio is working correctly aside from the high latency), as well as `Non-monotonous DTS in output stream 0:1` which seems to line up with when the stuttering occurs
[19:05:54 CEST] <JEEB> if you are using the command line app you can see with -debug_ts how the timestamps go through the chain
[19:06:01 CEST] <JEEB> it seems like stuff is wonky
[19:06:21 CEST] <JEEB> as in the timings of your packets/frames is going to hell and back
[19:08:37 CEST] <aldenp> latency seems to increase the longer I record, since at the beginning the latency is fine but after a minute of recording it's terrible
[19:08:42 CEST] <aldenp> I'll run with -debug_ts
[19:09:08 CEST] <aldenp> I don't know how I'm going to interpret that output though
[19:32:40 CEST] <upgreydd> Hello there. How to set overall bitrate in file other than video bitrate?
[19:33:45 CEST] <Mavrik> That's a wierd question :)
[19:33:56 CEST] <Mavrik> Can you explain a bit more what you're trying to do? And what format?
[19:37:55 CEST] <upgreydd> Mavrik: I'm still struggling with some h264 - I have a hardware which requires specific header to play - I've alredy wroted needed heaer generator but all encoding settings need to be as in original file and I set same video stream bitrate but when I'm checking sections line by line my "overall bitrate" is same as "video bitrate". They have different, no idea how to set this like them
[19:40:20 CEST] <upgreydd> Mavrik: https://0bin.net/paste/JxEUUZPhqiOqj9zy#pRnvh-8Y6FxME0ACL+AimR5WeWbA+H8Yn/xTyteAApq please look here
[19:41:13 CEST] <upgreydd> Overall bit rate: 2983600                   Bit rate: 132777984
[19:42:48 CEST] <upgreydd> and here's mine: https://0bin.net/paste/HVB5nurH5rF6Gexv#VP7jEti2WMFje2rcas50ULVcf8RdA1owMaAybjkScMn
[19:42:58 CEST] <upgreydd> I have Overall bit rate same as Bit rate :/
[19:45:31 CEST] <upgreydd> I guess that's the reason why my file is 15 times bigger than their
[19:45:57 CEST] <upgreydd> 50* not 15
[19:51:28 CEST] <Mavrik> upgreydd, something is really messed up with the original file here
[19:52:01 CEST] <upgreydd> Mavrik: can I mess up mine one too? xD
[19:53:34 CEST] <Mavrik> I don't really know of a way to prepare libx264 to report a 133Mbps CBR stream in internal strucures while generating a 3Mbps stream in reality
[20:07:31 CEST] <upgreydd> Thank you Mavrik . One more question - meybe you know how to detect which version of h264 codec was used? I mean some number version - Still have black movie in hardware :/
[20:46:43 CEST] <upgreydd> OK, they are using ivahd_video_decoder-omap5430.so
[22:11:21 CEST] <inna> hey
[22:11:33 CEST] <inna> is there a switch for limiting cpu usage?
[22:11:44 CEST] <inna> for the sake of skipped frames, or delayed encoding?
[22:17:10 CEST] <inna> currently i'm setting the process' priority to low
[22:17:21 CEST] <inna> and io
[22:18:12 CEST] <TheAMM> You can use https://ffmpeg.org/ffmpeg-filters.html#realtime_002c-arealtime to sleep within ffmpeg
[22:18:50 CEST] <JEEB> oh wow, they added a filter for it too? there already was the -re thing in ffmpeg.c
[22:41:24 CEST] <inna> thanks!
[23:10:09 CEST] <upgreydd> Hello. Can anyone please help me with files? I'm not sure what's the difference in settings between them :/ For me both are compressed same way. https://filebin.net/0dd8bc5v7y3eh8k4
[23:11:44 CEST] <JEEB> seem pretty similar, you could check with ffmpeg.c and the trace headers bsf
[23:11:50 CEST] <JEEB> to see if there's anything more specific
[23:12:03 CEST] <JEEB> at least ffprobe -v verbose "http://URL" shows very similar stuff
[23:14:28 CEST] <JEEB> something like `ffmpeg -v verbose -i FILE -bsf trace_headers -c copy -f null - 2> trace.log`
[23:14:37 CEST] <JEEB> and then you get a trace.log file with the structure
[23:14:40 CEST] <JEEB> you can then compare
[23:16:25 CEST] <upgreydd> JEEB: thank you. one more question, what is IVAHD ?
[23:16:36 CEST] <JEEB> I have no idea
[23:16:57 CEST] <JEEB> ok, on one of the streams I see quite a bit of stuffing bytes
[23:17:18 CEST] <JEEB> oh
[23:17:23 CEST] <JEEB> [AVBSFContext @ 0000028635ac5140] bit_equal_to_one out of range: 0, but must be in [1,1].
[23:17:26 CEST] <JEEB> [AVBSFContext @ 0000028635ac5140] Failed to read unit 3 (type 6).
[23:17:32 CEST] <JEEB> so the first file actually has incorrect stuff in it?
[23:17:37 CEST] <upgreydd> JEEB: ? How did you get this? :D
[23:17:53 CEST] <upgreydd> JEEB: Sintegrate or DoorIN?
[23:17:54 CEST] <JEEB> try the command I noted just :P
[23:18:04 CEST] <JEEB> the one using trace_headers
[23:18:15 CEST] <JEEB> basically it will output all the H.264 structures nicely
[23:18:45 CEST] <JEEB> the DoorIN one seems to be the borked one?
[23:19:03 CEST] <upgreydd> JEEB: DoorIN is working in hardware xD
[23:19:16 CEST] <upgreydd> second one is converted by me
[23:20:30 CEST] <JEEB> but yea, the DoorIN one seems to have a broken picture timing sei
[23:20:43 CEST] <JEEB> bit_equal_to_one which is defined as being 1 is 0 :P
[23:21:31 CEST] <JEEB> upgreydd: please see if you can verify the same thing with the trace_headers bit stream filter on your side?
[23:22:07 CEST] <JEEB> but I kind of would be surprised if this change would fix your stream
[23:22:24 CEST] <JEEB> I'd rather see if fixing that picture timing sei still works in the hardware
[23:22:38 CEST] <JEEB> and/or just fixing it and going through it again with the trace_headers bsf
[23:22:41 CEST] <JEEB> to see how far you get
[23:25:16 CEST] <upgreydd> JEEB: I have checked - have same error in DoorIN file, How can I detect this bit offset to fix stream?
[23:29:40 CEST] <upgreydd> JEEB: probably they pushed some checksum in place of type6-h264-filter - it's only info for encoding and there can be a checksum which is verified
[23:31:11 CEST] <JEEB> it seems to be the 8th (?) NAL unit in the stream
[23:32:45 CEST] <upgreydd> JEEB: is there some application to analyze this or detect hex offset? :p
[23:35:51 CEST] <JEEB> NAL units can be detected by the three or four byte start code
[23:35:57 CEST] <JEEB> 0x00 00 00 (00) 01
[23:36:16 CEST] <JEEB> and then the bit stream filter together with the H.264 spec gives you the stuff you can stare at in a hex editor
[23:36:45 CEST] <upgreydd> JEEB: thank you, so getting back to debugging this shit xD
[23:37:08 CEST] <JEEB> because the first number you see in the bit stream filter lines
[23:37:11 CEST] <JEEB> is the bit offset
[00:00:00 CEST] --- Sun May 26 2019