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

[burek]

[00:16:46 CEST] <cards> Is it possible to mux multiple audio tracks to a single MPEG (.mp4) container? (non-mkv)
[00:17:49 CEST] <furq> yes
[00:18:44 CEST] <cards> and most players will be able to manage that?  ie, VLC
[00:19:00 CEST] <furq> sure
[00:19:34 CEST] <furq> maybe not web players but afaik those will just ignore the extra tracks
[06:36:48 CEST] <JohnGritt> is this the channel to find a codecs dealer on the down low?
[13:55:39 CEST] <termos> I'm muxing something to HLS, but if there's an error pushing my segments i'm buffering up AVPacket's. The problem is I don't want to call avformat_free_context when the output stops working since I want to keep the internal AVPacket buffers in the HLS muxer as well, so I don't lose any segments
[13:56:13 CEST] <termos> though there seems to be some memory leaking every time I'm doing this, is there a best practice way to do something like this? I avio_open every time I retry instead
[14:33:32 CEST] <termos> I guess I want to avoid the call to flush_packet_queue, but do everything else that avformat_free_context does, hmmm
[14:55:05 CEST] <ponyride1> termos: i just opened the man page on hls :(
[15:03:21 CEST] <termos> hehe, not helpful? i'm considering creating an avformat_free_context_noflush function and frees the streams and everything except flushing the internal buffers. The problem is I'm losing segments if they are flushed, causing my bitrates to run out of sync
[15:18:32 CEST] <ponyride1> termos: lhls -- experimantal
[15:18:56 CEST] <termos> ah i'm not using lhls right now
[15:19:45 CEST] <ponyride1> segments do not need to be complete to be buffered, the server is able to push partial segments to the client
[15:20:45 CEST] <ponyride1> the more i read, the more i die inside lol its complicated
[15:22:18 CEST] <DHE> lhls?
[15:23:03 CEST] <ponyride1> yeah im just reading about it
[15:24:36 CEST] <DHE> yeah I'm finding references now
[15:25:49 CEST] <DHE> looks like low-latency HLS variant... which sounds nutty but...
[15:28:29 CEST] <ponyride1> termos: what does 'error pusing segments' mean
[15:28:34 CEST] <ponyride1> * pushing
[15:29:42 CEST] <termos> error POST/PUT-ing them to a temporarily unavailable http endpoint
[15:45:55 CEST] <termos> something similar to lhls exists for dash, but lhls was kind of hijacked by Apple creating their own standard which uses http/2
[15:58:46 CEST] <ponyride1> well they own hls and lhls will have to be compliant so Apple will have to set the spec no?
[16:09:49 CEST] <termos> true they can do whatever they want, was just a bit of annoyance in the hls.js community that Apple didn't build on their "lhls community version" but went and did something very different
[16:10:21 CEST] <JEEB> technically HLS is now in the hands of IETF, but yes - de facto leader is Apple
[16:10:37 CEST] <JEEB> termos: when has apple really played well with the other kids in the sand box :)
[16:10:57 CEST] <termos> i think never :D apple's gonna apple
[16:17:26 CEST] <delsol> I'm getting a "nousable encoding entrypoint found for profile VAProfileH264High (7)" error and then error initializing output stream.  The same command works on another machine, no idea what the difference is.
[16:18:07 CEST] <delsol> I can run command locally on machine 1,  or ssh run it on machine1 from machine2.... but it doesn't run locally on machine2 or via ssh from machine 1.
[16:23:10 CEST] <JEEB> delsol: check vainfo?
[16:25:32 CEST] <delsol> vainfo is same on both machines.
[16:26:15 CEST] <delsol> gives error it can't connect to X server, and "libva error: /usr/lib64/dri/i965_drv_video.so has no function __vaDriverInit_1_0"
[16:27:31 CEST] <ponyride1>  vaapi
[16:27:34 CEST] <ponyride1>                device is either an X11 display name or a DRM render node.
[16:28:33 CEST] <ponyride1> does this mean no DISPLAY:0?
[16:28:50 CEST] <delsol> DISPLAY=:0 ffmpeg -vaapi_device /dev/dri/renderD128 -framerate 15 -f x11grab -video_size1024x768 -i :0 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 30 /video/video.mp4
[16:28:56 CEST] <delsol> works fine on one machine, doesn't work on the other
[16:29:28 CEST] <ponyride1> but when you run ssh... there is no x11
[16:29:51 CEST] <delsol> I can run it on machine 1 via ssh from machine2
[16:29:53 CEST] <delsol> works fine
[16:30:44 CEST] <delsol> doesn't work locally even when run in X, in a terminal window on second machine.
[16:31:40 CEST] <ponyride1> delsol: try something like xhost +
[16:32:05 CEST] <ponyride1> just temporarily.. maybe its a permssion thing? are you sshing as root or as another user
[16:32:14 CEST] <delsol> no dice with xhost +
[16:32:42 CEST] <delsol> even locally, on an xterm, on the DISPLAY=:0 of the second machine, it still doesn't run.
[16:32:45 CEST] <delsol> as root
[16:33:18 CEST] <ponyride1> delsol: you should take this to your distro maybe..
[16:33:39 CEST] <ponyride1> im not sure if this is really an ffmpeg error?
[16:34:22 CEST] <delsol> It worked fine without hardware accel.
[16:34:57 CEST] <delsol> I upgraded Xorg and intel drivers, etc, it still worked fine without hardware accel.
[16:35:46 CEST] <delsol> turn hardware accel on, to reduce CPU load of encoding the X11grab, and works fine on main machine, doesn't work on any of the client machines.
[16:41:04 CEST] <ponyride1> delsol: better ask your distro ^^
[16:42:03 CEST] <delsol> ffmpeg -y -framerate 15 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 30 -x264-params scenecut=10:keyint=450 -pix_fmt yuv420p -preset ultrafast /video/vido.mp4 -nostdin -nostats </dev/null 2>&1       works fine
[16:42:19 CEST] <delsol> ffmpeg -vaapi_device /dev/dri/renderD128 -framerate 15 -f x11grab -video_size 1024x768 -i :0 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 30 /video/video.mp4 -nostdin -nostats </dev/null 2>&1      doesn't work on the client machines.
[16:43:08 CEST] <ponyride1> what machine is it?
[16:43:30 CEST] <delsol> model name	: Intel(R) Pentium(R) 3560Y @ 1.20GHz
[16:43:59 CEST] <ponyride1> what linux
[16:44:09 CEST] <ponyride1> what distro
[16:44:33 CEST] <delsol> slackware-(not_quite)current
[16:45:19 CEST] <delsol> with a newer Xorg, newer intel drivers, newer ffmpeg, etc
[16:45:30 CEST] <delsol> Fluxbox is the window manager.
[16:48:15 CEST] <ponyride1> i really dont know. it could be your drivers, it could be some packaging error of your distro, it could be a bug elsewhere
[16:48:32 CEST] <delsol> Other machines that work just fine are other haswell boxes,
[16:48:49 CEST] <delsol> including i3-4030U
[16:49:36 CEST] <delsol> oh shit. I know why
[16:49:37 CEST] <ponyride1> delsol: you could just have some bad command too... i
[16:49:55 CEST] <delsol> Intel® Quick Sync VideoNo
[16:50:13 CEST] <delsol> Looks like its hardware disabled on the pentium....
[16:50:22 CEST] <delsol> well shit
[16:50:47 CEST] <delsol> (is there a way to detect quicksync?)
[16:51:16 CEST] <ponyride1> huh
[16:54:42 CEST] <ponyride1> !man
[16:57:01 CEST] <ponyride1> you should look at teh man page for qsv though
[16:57:38 CEST] <ponyride1> i think your barking up the wrong tree
[16:58:38 CEST] <delsol> I think its the fact that the one machine has quicksync disabled by intel....
[16:58:50 CEST] <delsol> according to ark.intel.com
[17:00:42 CEST] <Fenrirthviti> it's not disabled, it just doesn't exist
[17:01:02 CEST] <Fenrirthviti> quicksync is a dedicated hardware encoder that's part of the integrated GPU
[17:01:23 CEST] <Fenrirthviti> so the physical chip for that is just nonexistent on such a low-end CPU
[17:01:54 CEST] <delsol> .... its disabled, since that chip comes off the same wafer as the other chip.
[17:01:57 CEST] <Fenrirthviti> typically the only way to check is to try and start an encode session
[17:02:11 CEST] <delsol> so its laser-disabled, or firmware disabled from the GPU.
[17:02:43 CEST] <ponyride1> delsol: the man page also states Note that most acceleration methods are intended for playback and will not be faster than software decoding
[17:02:46 CEST] <ponyride1> on modern CPUsy
[17:05:07 CEST] <ponyride1> delsol: i3-4030U - qucksync = yes, 3560Y quickync = NO
[17:06:15 CEST] <ponyride1> Fenrirthviti: i just looked up the specs. ur right it doesnt exist
[17:06:22 CEST] <ponyride1> anyway i gtg to bed gooluck
[17:06:37 CEST] <delsol> ponyride1: switching to quicksync encode of the x11grab takes a shitty machine from roughly 40% of a core during screen abuse, to 25%....
[17:07:29 CEST] <delsol> with several VNC sessions to record potentially, that makes a difference, thats why I was trying to offload what I could.
[17:07:36 CEST] <ponyride1> i dont really see how this is relevant
[17:08:37 CEST] <delsol> I guess I need to find a way to detect quicksync support now, run the accelerated command on machines with quicksync, run the other command on machines without.
[17:10:21 CEST] <ponyride1> you misunderstand
[17:10:38 CEST] <ponyride1> https://ark.intel.com/content/www/us/en/ark/products/76622/intel-pentium-processor-3560y-2m-cache-1-20-ghz.html
[17:10:42 CEST] <ponyride1> no quicksync for you
[17:11:25 CEST] <delsol> yeah, I saw that. I mentioned that 20 minutes ago....
[17:11:51 CEST] <delsol> the question now, is how the hell can I detect quicksync = YES vs quicksync = NO automatically.
[17:14:44 CEST] <grill05> I'm using a custom video encoder with ffmpeg. I pipe using yuv4mpegpipe to stdout, and the encoder reads from stdin via a pipe. Unfortunately the encoder doesn't write to stdout. So right now, I have to use a tmp video file (made with encoder) and encode audio later separately
[17:15:06 CEST] <grill05> I'd like to do this in 1 command. If the encoder could write to stdout, I could do sometimething like
[17:15:55 CEST] <grill05> ffmpeg -i input.mkv -f yuv4mpegpipe - | custom_encoder -i - -o - | ffmpeg -i - -i input.mkv -map 0:0 -c:v copy -map 1:0 -c:a  copy output.mkv
[17:16:30 CEST] <grill05> Since the custom encoder cant write to stdout, is there a way using FIFOs (on linux) to achieve the same effect as two pipes ?
[17:16:46 CEST] <Fenrirthviti> delsol: we have a check somewhere in here: https://github.com/obsproject/obs-studio/tree/master/plugins/obs-qsv11 but I don't know exactly where off the top of my head
[17:16:55 CEST] <Fenrirthviti> there's no simple way with just ffmpeg though, afaik
[17:16:57 CEST] <TheAMM> grill05: yes
[17:17:07 CEST] <TheAMM> I haven't looked at your commands at all, but FIFOs work, yes
[17:17:14 CEST] <grill05> please post a sample command line
[17:17:20 CEST] <TheAMM> mkfifo foo
[17:17:32 CEST] <delsol> Fenrirthviti: hmmm. I'll take a glance.
[17:17:33 CEST] <TheAMM> ffmpeg -i a.mkv -y foo, iirc
[17:17:49 CEST] <grill05> I mean the whole thing, that acts in same way as two pipes joined together, maybe on pastebin ?
[17:17:54 CEST] <grill05> ok
[17:18:00 CEST] <TheAMM> Nah
[17:18:13 CEST] <TheAMM> I'm just here to confirm that FIFOs do work as outputs (and inputs)
[17:18:26 CEST] <TheAMM> (depending on your containers ofc etc)
[17:20:36 CEST] <grill05> TheAMM,  ok. If I do the first command (write to fifo with custom video encoder), wont the command block till the whole video is encoded ? That would defeat the purpose, which is simultaneous encoding of audio+video
[17:21:38 CEST] <TheAMM> Open two shells or background the jobs
[17:22:13 CEST] <grill05> hmm..backgrounding might work. thanks. I'll try it out
[17:29:00 CEST] <grill05> TheAMM, so backgrounding did'nt work. starting two shells (encoding video to FIFO in shell 1 and muxing it with audio on shell 2), gives these errors (in shell 2) "Timestamps are unset in a packet for stream 0"
[17:29:25 CEST] <grill05> The video is normally written as .ivf (AV1)
[17:30:58 CEST] <TheAMM> 🤷
[17:31:05 CEST] <TheAMM> Someone else will have to help
[17:32:47 CEST] <grill05> thanks anyway. This is farther along than I would have reached by myself :)
[17:41:08 CEST] <voxelcloud> Hi, I'm trying to figure out if I've found a bug. I'm using the drawtext filter to write out frames with frame numbers drawn on. One frame gets printed twice, as in there are two frames with the same frame number printed on it (and the same frame content). The video is mpeg1. Command line is here: https://pastebin.com/xBf50Wbp. I've tested 4.1.4 on Fedora 30 and built it from master with the same issue.
[17:51:26 CEST] <kepstin> voxelcloud: expected behaviour. The image output is cfr (by default) since you lose frame timing information. So it may drop or duplicate frames if the input is not cfr.
[17:52:02 CEST] <kepstin> voxelcloud: you can use `-vsync vfr` option to override that behaviour
[17:55:06 CEST] <voxelcloud> kepstin, Thanks! Makes perfect sense.
[17:55:35 CEST] <voxelcloud> and that does indeed fix it.
[18:06:49 CEST] <JordiGH> What's going on with the first command here? https://video.stackexchange.com/a/28276
[18:07:09 CEST] <JordiGH> What's with the /dev/null? Where is anything being saved, then?
[18:07:24 CEST] <JEEB> 1st pass video generally isn't kept
[18:07:41 CEST] <JEEB> might as well do that without the -f webm and instead -f null -
[18:07:44 CEST] <kepstin> libvpx doesn't even generate any video output when you run pass 1, you just get an empty file
[18:08:51 CEST] <kepstin> the log output used by pass 2 is saved to a separate file. it's configurable, but there's a default that's saved to the cwd
[18:09:28 CEST] <JordiGH> I still don't understand. Is pass 1 writing anything to disk?
[18:09:36 CEST] <JordiGH> You're saying it's saving a log file to cwd?
[18:10:10 CEST] <JordiGH> ffmpeg2pass-0.log
[18:10:12 CEST] <JordiGH> Oh, boy, there it is.
[18:10:17 CEST] <JordiGH> That was generated by pass 1?
[18:10:24 CEST] <kepstin> yes, and read by pass 2
[18:11:43 CEST] <kepstin> note that you shouldn't run multiple two-pass encodes in the same directory without specifying a different filename for the 2pass log for each, otherwise they'll clobber each-others log files :)
[18:11:45 CEST] <JordiGH> Aha. So anyway, thanks for helping me generate this: https://mathstodon.xyz/@JordiGH/102998504788285261
[18:12:59 CEST] <kepstin> hmm. for mastodon there's normally an upload size limit, you might want to do a 2pass encode with a bitrate that'll result in maxing out the file size to the limit.
[18:13:18 CEST] <JordiGH> It was less than 2 megs, well within the limit.
[18:13:33 CEST] <JordiGH> I just didn't want my waves to get all pixelly.
[18:53:29 CEST] <familiya> Hi, I am pretty new at using ffmpeg, I have a requirement where in I want to produce output in raw y416 pixel format. Not sure if AV_PIX_FMT_AYUV64LE would be helpful
[18:54:08 CEST] <BtbN> what even is y416?
[18:54:21 CEST] <familiya> Its pixel format
[18:55:38 CEST] <familiya> More information available at https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats
[18:56:46 CEST] <BtbN> "Bits 0-15 contain the U sample, bits 16-31 contain the Y sample, bits 32-47 contain the V sample, and bits 48-63 contain the alpha value."
[18:56:50 CEST] <BtbN> I don't think ffmpeg has that.
[18:57:11 CEST] <BtbN> AYUV64 is close, but the ordering seems off
[18:57:49 CEST] <familiya> Just curious as ffmpeg wiki has a ref to y416 https://en.wikipedia.org/wiki/FFmpeg#Pixel_formats
[19:02:44 CEST] <kepstin> could probably do a hack where you use a filter to swap some of the planes around then output as AYUV64
[19:03:10 CEST] <kepstin> but yeah, AVYU (or UYVA depending on endianness) is such a weird order.
[19:15:01 CEST] <familiya> kepstin: Not sure if I understand your suggestion, as far I understand Y416 is a packed pixel format. Not sure how can I swap planes and from where. I would like to apologies in advance as I am pretty new to ffmpeg, and would end up asking pretty trivial questions
[19:16:06 CEST] <kepstin> https://www.ffmpeg.org/ffmpeg-filters.html#shuffleplanes
[19:16:35 CEST] <kepstin> iirc it works on packed formats too, but the video's probably in planar format in ffmpeg then converted to packet to output in many cases
[19:44:55 CEST] <familiya> how about adding support in codec, where I can shuffle the planes from pixel format AV_PIX_FMT_YUVA444P16
[21:14:46 CEST] <realies> hey I'm using ebur128 to get loudness data and wonder what I and Threshold mean in the Integrated loudness section
[21:17:01 CEST] <kepstin> realies: I is the important one, that's the integrated loudness (loudness over the entire track)
[21:17:57 CEST] <kepstin> in order to understand the threshold you need to read the math in https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-4-201510-I!!PDF-E.pdf - it's an internal detail about the loudness gating to make sure the calculated loudness is representative of most of the track, and excludes stuff like silence and outliers.
[21:18:21 CEST] <realies> kepstin, using a VST plugin (https://youlean.co/download-youlean-loudness-meter/) to measure the integrated loudness of the same clip and it gives me -34 LUFS, while ffmpeg gives me -25 LUFS, both using EBU standard
[21:18:56 CEST] <realies> ok, Threshold: -35.9 LUFS in ffmpeg is closer to the -34 from the VST plugin
[21:19:14 CEST] <kepstin> it's likely that the meters are measuring different audio
[21:19:31 CEST] <kepstin> like your vst plugin is running on audio that's ~10dB louder than the audio that ffmpeg is measuring
[21:19:56 CEST] <kepstin> probably due to settings inside the application you're using, or possibly settings in how you're exporting the audio before running ffmpeg on it
[21:20:36 CEST] <kepstin> ffmpeg's calculation is correct, and is consistent with other implementations when run over the same audio
[21:21:06 CEST] <realies> was looking to match the values from the VST with ffmpeg I guess
[21:21:26 CEST] <kepstin> you first need to match the audio gain that you're feeding as input to both
[21:21:43 CEST] <kepstin> if the audio gain is different, then the measured loudness will be different by the same amount
[21:22:03 CEST] <kepstin> (if it's consistent difference, you can just use an offset equal to the gain difference tho)
[21:22:37 CEST] <realies> all channels are on 0db
[21:22:49 CEST] <kepstin> make sure you didn't insert the VST plugin before e.g. a compressor or levels plugin
[21:22:55 CEST] <realies> new, empty project
[21:23:25 CEST] <realies> anyways, matching the data with a VST is not that important, trying to automate a filter chain to make voice audio sound 'broadcast compatible'
[21:23:46 CEST] <kepstin> well, all i can tell you is that there's either some gain being changed somewhere or that the plugin you're using is wrong :/
[21:23:54 CEST] <realies> perhaps
[21:24:10 CEST] <kepstin> since it seems like the levels in the exported audio that you're running through ffmpeg don't match the levels that the vst plugin sees
[21:24:21 CEST] <durandal_1707> realies: do you use video output from ebur128?
[21:24:38 CEST] <realies> I've downloaded a few broadcasts from BBC's website and I get I:         -18.4 LUFS when they specify about -23 LUFS in their broadcast specs lol
[21:24:51 CEST] <realies> durandal_1707, no, ffmpeg -hide_banner -nostats -i BroadcastingHouse-20191006.mp3 -af ebur128=framelog=verbose -f null -
[21:25:17 CEST] <kepstin> realies: interesting. -18 LUFS is the ReplayGain reference loudness, commonly used for people normalizing their music collections.
[21:25:46 CEST] <kepstin> youtube for reference seems to use something around -14 LUFS (but they only lower gain if it's louder, they never increase gain)
[21:25:47 CEST] <realies> hmm, could it be that they loudness normalise downloads with different settings to what's being broadcasted? seems unlikely though
[21:26:17 CEST] <kepstin> -23 is the standard for tv broadcasts, but afaik there's no radio standards
[21:27:14 CEST] <realies> -23 sounds like the upper limit... what about the expected dynamic range for voice? :) no one is saying anything about that
[21:27:45 CEST] <kepstin> dynamic range is a completely separate issue
[21:27:50 CEST] <realies> indeed
[21:28:08 CEST] <kepstin> (although the ebu r128 meters do measure something sort of dynamic rangey)
[21:28:18 CEST] <realies> 'Loudness range'
[21:29:26 CEST] <kepstin> the value ffmpeg outputs as LRA is the loudness range, which is equavalent to the LRA high minus LRA low
[21:30:03 CEST] <kepstin> iirc those are the highest and lowest instantaneous loudness values excluding values outside the threshold, but check the spec to confirm that
[21:30:57 CEST] <kepstin> note that these values are all negative, so -23 LUFS is more of a lower limit than an upper limit
[21:31:19 CEST] <kepstin> it's kind of quiet, tbh, but provides lots of headroom for dynamic loud sound effects in movies and stuff
[21:32:44 CEST] <kepstin> most modern pop/rock music ends up being mastered to around -8 to -10 LUFS, fwiw, so it basically always ends up having gain lowered by streaming services.
[21:33:05 CEST] Action: kepstin has seen higher than that even in some things
[21:33:14 CEST] <realies> sure
[21:33:48 CEST] <realies> just wondering how could one make an universal processing filter chain for voice input... :)
[21:34:31 CEST] Action: realies goes looking up dynaudnorm || loudnorm 
[21:34:35 CEST] <kepstin> hmm. main issue there would be dealing is people moving around closer/further from the mic
[21:35:04 CEST] <realies> you would hope that the loudnorm deals with that
[21:35:08 CEST] <kepstin> i've successfully helped someone here recently using loudnorm on an audiobook file with inconsistent levels, just set the target LRA fairly low.
[21:35:09 CEST] <realies> or dynaudnorm
[21:35:26 CEST] <realies> yeah, should act like a compressor I assume
[21:36:58 CEST] <kepstin> dynaudnorm is a normalizer, not loudness adjustment, so it doesn't take perceptual loudness into effect. However, it should be ok with keeping voice from a single speaker at a consistent level.
[21:37:56 CEST] <kepstin> assuming you don't have any clipping
[21:38:17 CEST] <kepstin> (or use rms mode)
[21:39:12 CEST] <realies> was thinking of chaining dynaudnorm to loudnorm for more 'even sounding' result
[21:39:57 CEST] <kepstin> might work, use dynaudnorm to do the short-term normalization, then loudnorm to adjust the result to the desired LUFS target.
[21:40:10 CEST] <realies> it does something weird...
[21:40:25 CEST] <durandal_1707> really? what weird?
[21:40:35 CEST] <realies> https://i.snipboard.io/5eXwRo.jpg
[21:40:52 CEST] <realies> beginning and end are 'quiet' and the middle is boosted
[21:41:17 CEST] <durandal_1707> that is normalizer
[21:41:37 CEST] <durandal_1707> if you want begining and end also boosted use alt boundary option
[21:41:39 CEST] <realies> that's dynaudnorm
[21:42:00 CEST] <kepstin> dynaudnorm documentation explicitly says that it has this behaviour
[21:42:23 CEST] <realies> sorry, I've missed altboundary :)
[21:43:02 CEST] <realies> awesome
[21:44:08 CEST] <kepstin> note that you might want to try the rms option for dynaudnorm too, see which way works better.
[21:46:46 CEST] <realies> I've added r=1.0 but not seeing/hearing any difference
[21:47:55 CEST] <kepstin> i'd expect you'd have to use a lower value, with rms 1 it would hitting the peak limit the whole time :)
[21:49:08 CEST] <realies> ah
[21:49:21 CEST] <kepstin> i assume the scale 0-1 represents the linear pcm levels, so 1 would be 0 dBFS and 0 is silence
[21:49:39 CEST] <realies> so 0.23 could be a good value? lol
[21:49:48 CEST] Action: realies hasn't got a clue
[21:50:16 CEST] <kepstin> i dunno, probably ok? :)
[21:50:21 CEST] <realies> :)
[21:51:36 CEST] <durandal_1707> you can use dB: dynaudnorm=b=1:r=-30dB
[21:51:51 CEST] <realies> :o
[21:52:02 CEST] <kepstin> oh, it can take a value in dB directly? that's handy
[21:52:14 CEST] <realies> awesome
[21:52:14 CEST] <kepstin> i guess the conversion is done by the ffmpeg option parser units stuff
[21:52:19 CEST] <durandal_1707> yes
[21:52:34 CEST] Action: kepstin does not recommend setting bitrate in dB
[21:52:57 CEST] <durandal_1707> but not all options supports that, some take dB directly
[21:53:25 CEST] <durandal_1707> *other filters
[21:53:39 CEST] <realies> feels like I should use dynaudnorm to expand the audio and maybe add a bit of compression before it goes to the loudness normaliser
[21:55:14 CEST] <durandal_1707> i prefer vanilla audio
[21:55:22 CEST] <kepstin> dynaudnorm doesn't do any expanding, not sure what you mean?
[21:55:42 CEST] <kepstin> (it does have a builtin compressor, fwiw, but it's off by default)
[21:56:44 CEST] <kepstin> dynaudnorm is basically equivalent to a person sitting watching a dB meter (either peak or rms) and turning the volume knob to try to keep the level mostly the same
[21:57:05 CEST] <durandal_1707> expanding is fixed operation
[21:57:50 CEST] <durandal_1707> you can expand audio with agate filter and setting mode to upward
[21:59:13 CEST] <phobosoph> hi
[21:59:21 CEST] <phobosoph> so I found a mystery! :D
[21:59:29 CEST] <phobosoph> ffmpeg shows me the stats while streaming to YouTube Live
[21:59:40 CEST] <phobosoph> suddenly YouTube Live doesn't recognize the stream anymore (No data)
[21:59:44 CEST] <phobosoph> so I checked the logs
[21:59:54 CEST] <phobosoph> frame=331657 fps= 24 q=-1.0 size= 8311736kB time=03:04:41.19 bitrate=6144.6kbits/s speed=0.807x
[22:00:01 CEST] <phobosoph> can you see it? speed is 0.8...x
[22:00:11 CEST] <realies> sorry, wrong terminology, i meant to even out the audio level and maybe shorten the dynamic range before it goes to the loudness normaliser
[22:00:12 CEST] <phobosoph> it started with speed=1.03x or something like that
[22:00:20 CEST] <phobosoph> The speed drops over time!
[22:00:22 CEST] <phobosoph> why
[22:00:22 CEST] <realies> phobosoph, maybe -r?
[22:00:42 CEST] <phobosoph> aha
[22:00:56 CEST] <phobosoph> realies: so the source stream of the webcam got 30fps
[22:01:02 CEST] <phobosoph> ideally this fps is kept for youtube
[22:01:05 CEST] <phobosoph> otherwise it would be a waste
[22:01:17 CEST] <kepstin> if you use no special options, ffmpeg will do that by default
[22:01:36 CEST] <phobosoph> right
[22:01:43 CEST] <phobosoph> but why is the speed constantly dropping?
[22:01:45 CEST] <durandal_1707> depends what processing is done ... any filtering or similar?
[22:01:49 CEST] <kepstin> the speed going low usually means that you're either network limited or cpu limited (it can't send data fast enough, or it can't encode video fast enough)
[22:02:11 CEST] <kepstin> is your internet connection good enough to send 6mbit/s upstream? :)
[22:02:54 CEST] <phobosoph> No filter, mute audio is added
[22:02:58 CEST] <phobosoph> yes, internet connection is not saturated
[22:03:17 CEST] <phobosoph> https://pastebin.com/kgaZqwD2
[22:03:26 CEST] <kepstin> btw, does anyone know offhand if mp3 audio in a video file with mp4 container plays on iOS?
[22:03:27 CEST] <phobosoph> that's the ffmpeg command used
[22:03:40 CEST] <kepstin> phobosoph: don't use -re
[22:03:41 CEST] <phobosoph> it adds mute audio channel, otherwise youtube will not accept it
[22:03:53 CEST] <phobosoph> kepstin: so just ommit '-re'?
[22:03:53 CEST] <ritsuka> kepstin: it does not
[22:04:08 CEST] <kepstin> ritsuka: ah :/ well, aac it is then, i guess.
[22:04:23 CEST] <phobosoph> kepstin: thanks, so when I ommit -re do I need something else?
[22:04:25 CEST] <kepstin> phobosoph: -re is not needed if your input is already realtime, it only causes desync issues then
[22:04:28 CEST] <phobosoph> ah
[22:04:30 CEST] <phobosoph> thanks!!!!!
[22:05:07 CEST] <peloverde> What's the correct filter chain for going from rgb24 to y420p8 with dither? Do I need to go through a high bit depth intermediate?
[22:05:51 CEST] <JEEB> peloverde: I would recommend testing out between scale and zscale
[22:06:21 CEST] <durandal_1707> scale would be needed anyway, as it will unpack rgb24 into gbrp
[22:06:22 CEST] <JEEB> something like -vf scale,format=yuv420p
[22:06:26 CEST] <phobosoph> ok, restarted ffmpeg without -re
[22:06:28 CEST] <JEEB> durandal_1707: yes
[22:06:34 CEST] <phobosoph> speed is at 1.03x currently
[22:06:39 CEST] <phobosoph> 0.02
[22:06:55 CEST] <kepstin> phobosoph: it'll usually burst a little bit at the start because of how the encoder works, then converge to 1.0
[22:07:03 CEST] <JEEB> -vf format=gbrp,zscale,format=yuv420p
[22:07:09 CEST] <JEEB> something like that I guess for zscale comparison
[22:07:14 CEST] <phobosoph> that's ok! I just want the stream to be recognized by YouTube Live
[22:07:21 CEST] <phobosoph> right, 1.01
[22:07:30 CEST] <phobosoph> looks good
[22:07:33 CEST] <phobosoph> crazy, a stupid -re flag did that
[22:07:34 CEST] <phobosoph> lol
[22:07:35 CEST] <JEEB> although the filter chain might add the rgb to gbrp conversion automagically?
[22:08:03 CEST] <phobosoph> kepstin: well, thank you! You helped me a lot. I will now monitor this for some hours.
[22:08:06 CEST] <kepstin> JEEB: the filter chain will automatically convert to *something* zscale accepts as input, but it's hard to predict what it'll pick :)
[22:08:14 CEST] <JEEB> kepstin: aye-men
[22:08:26 CEST] <phobosoph> kepstin: "yuv420p instead of yuvj420p" - can this be done without re-encoding? video is currently just copied
[22:08:28 CEST] <durandal_1707> JEEB: yes, but that may have been gray8
[22:08:29 CEST] <JEEB> I specifically often disable automagic conversions in my filter chains
[22:08:34 CEST] <phobosoph> I don't think I can make my webcam use yuv420p instead of yuvj420p
[22:08:44 CEST] <phobosoph> hm, I hadn't tried the base profiles enough yet I think
[22:09:19 CEST] <kepstin> phobosoph: changing that (that's converting from full range/pc levels to limited/tv levels) cannot be done without re-encoding
[22:09:27 CEST] <phobosoph> kepstin: I see, thanks
[22:09:33 CEST] <phobosoph> I try to convince my webcam then
[22:10:39 CEST] <phobosoph> I can select a profile: Baseline, Main, High
[22:10:45 CEST] <phobosoph> from what I understand is High profile for higher quality
[22:10:56 CEST] <phobosoph> as YouTube Live does the video distribution I can pick High then?
[22:11:06 CEST] <phobosoph> and let YouUtbe encode/compress as demanded by devices?
[22:11:17 CEST] <kepstin> no reason to use anything other than high, yeah.
[22:11:21 CEST] <realies> eh?... Number of attacks/decays bigger than number of channels.
[22:11:38 CEST] <kepstin> but that has no relation to the levels issue
[22:11:58 CEST] <kepstin> it's strange that you'd be getting yuvj420p from an h264 stream, tho
[22:13:24 CEST] <realies> does compand specify attacks/decays for individual channels separately? compand=0|0:1|1:-90/-900|-70/-70|-30/-9|0/-3:6:0:0:0
[22:16:01 CEST] <phobosoph> kepstin: I switched to high profile :D
[22:16:03 CEST] <phobosoph> let's see
[22:16:19 CEST] <realies> it seems so, although it's not very clear from the docs
[22:16:25 CEST] <phobosoph> Non-monotonous DTS in output stream 0:0; previous: 0, current: -167; changing to 0. This may result in incorrect timestamps
[22:16:31 CEST] <realies> how should they be formatted
[22:16:32 CEST] <phobosoph> I get four warnings at the beginning
[22:17:07 CEST] <kepstin> phobosoph: a couple at the start like that can just be ignored, quirk of joining the stream in the middle.
[22:17:25 CEST] <phobosoph> good!
[22:17:26 CEST] <phobosoph> thanks man
[22:17:29 CEST] <phobosoph> it seems to work now
[22:17:41 CEST] <phobosoph> finally, I already thought of force-terminating ffmpeg each hour or so and restart it
[22:19:13 CEST] <phobosoph> yes, speed converged to 1x now as you said
[22:23:07 CEST] <realies> why is compand=.3|.3:1|1:-90/-60|-60/-40|-40/-30|-20/-20:6:0:-90:0.2 failing with Number of attacks/decays bigger than number of channels.?
[22:24:16 CEST] <durandal_1707> realies: mono audio?
[22:24:32 CEST] <realies> yes
[22:24:37 CEST] <durandal_1707> use latest version of ffmpeg, there are extra entries ignored
[22:25:27 CEST] <realies> assuming brew does not provide the latest version (4.2.1_1)
[22:26:13 CEST] <durandal_1707> compand is for more advanced users, try acompressor instead
[22:27:18 CEST] <realies> fine using compressors as long as I get the parameter syntax
[22:27:22 CEST] <realies> *parameters
[22:28:30 CEST] <realies> hmm... latest seems to be 4.2.1
[22:30:07 CEST] <delsol> .... is there an easy way to know how much of the quicksync hardware is being used at any given time? a way to do a "htop" for quicksync or something?
[22:30:46 CEST] <durandal_1707> realies: compand=.3:1:-90/-60|-60/-40|-40/-30|-20/-20:6:0:-90:0.2
[22:31:07 CEST] <realies> oh now I see it :)
[22:31:14 CEST] <realies> thanks!
[22:31:38 CEST] <realies> using ffmpeg-95459-ged78ca4123 also helped
[22:33:54 CEST] <realies> durandal_1707, that compand produces a different output vs the other one
[22:34:33 CEST] <durandal_1707> realies: for same, mono audio?
[22:35:08 CEST] <realies> yes, just different compand (and ffmpeg version) https://i.snipboard.io/hNDZuz.jpg, first is the one you've posted, second the one from above with latest ffmpeg
[22:35:57 CEST] <realies> could be the diff versions, tbc
[22:36:43 CEST] <durandal_1707> use same version of ffmpeg
[22:36:46 CEST] <realies> nope, it's the compand parameters
[22:37:40 CEST] <kepstin> delsol: on windows the task manager gpu view will show it. On linux, install intel-gpu-tools and use the intel_gpu_top command
[22:37:48 CEST] <realies> peaks are identical to the screenshot above when processing using the same ffmpeg version
[22:37:54 CEST] <kepstin> (fedora calls it igt-gpu-tools instead)
[22:38:32 CEST] Action: realies goes retrying
[22:40:18 CEST] <realies> durandal_1707, ignore what i've said :)
[22:56:25 CEST] <realies> kepstin, ReplayGain seems to be -14, not -18 LUFS (ITU 1770) :P
[22:59:39 CEST] <kepstin> realies: https://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification#Reference_level explains it
[22:59:50 CEST] <kepstin> the replaygain -14 is measured differently, but is close ot -18 LUFS
[23:35:37 CEST] <realies> interesting
[23:36:34 CEST] <realies> wondering what would be an adequate approach to profile and remove background noise
[23:41:32 CEST] <realies> this is to remove background noise from speech
[23:58:52 CEST] <realies> arnndn seems pretty interesting, is there any sample models?
[00:00:00 CEST] --- Tue Oct 22 2019