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

burek burek021 at gmail.com
Mon Nov 12 03:05:02 EET 2018

[14:39:26 CET] <tombb> Hi All, can ffmpeg do LKFS? I need to convert a file and normalize the audio to -24db LKFS... is that possible?
[14:41:19 CET] <JEEB> "Loudness units relative to full scale is a synonym for LKFS that was introduced in EBU R128."
[14:41:37 CET] <JEEB> so I would guess an audio normalization filter applying EBU R128 should be good enough?
[14:41:55 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#loudnorm
[14:42:00 CET] <JEEB> see this filter's documentation
[14:45:00 CET] <tombb> oh! lufs == lkfs then?
[14:45:05 CET] <tombb> cool - thank you!
[14:46:10 CET] <JEEB> it seems so at least according to a random quote from wikipedia
[14:46:19 CET] <JEEB> given that broadcast went for the EBU R128 spec
[14:46:28 CET] <JEEB> I would expect there to be relevant parameters :P
[14:54:26 CET] <tombb> stupid EBU :P - thanks!
[15:39:57 CET] <tombb> what would be the right way to combine filter_complex and loudnorm? I would like to split one stereo stream to 2 monos (pan=1c|c0=c0[left];[0:1]pan=1c|c0=c1[right]) and also control their loudness
[15:41:19 CET] <tombb> (the stereo to mono part works fine, but I can't add filter_complex and loudnorm in the same command)
[15:41:47 CET] <durandal_1707> pan=1c|c0=c0,loudnorm=....[left];[0:1]pan=1c|c0=c1,loudnorm=.....[right]
[15:42:23 CET] <furq> -lavfi channelsplit[a0][a1];[a0]loudnorm=xyz[out0];[a1]loudnorm=xyz[out1]
[15:57:06 CET] <tombb> awesome! thank you guys
[22:51:19 CET] <hololeap> i'm trying to broadcast a file to the network with RTP, like so: ffmpeg -i example.mp3 rtp://
[22:51:51 CET] <hololeap> but i get an error:
[22:51:51 CET] <hololeap> [NULL @ 0x564dac4314d0] Unable to find a suitable output format for 'rtp://'
[22:51:51 CET] <hololeap> rtp:// Invalid argument
[22:53:28 CET] <JEEB> you need to select a muxer
[22:53:34 CET] <JEEB> since there's no extension or anything for RTP
[22:55:09 CET] <hololeap> is there a passthrough-style muxer? i don't need to re-encode it, just broadcast it
[22:56:04 CET] <JEEB> those are separate
[22:56:11 CET] <JEEB> -c copy is for copying AVPackets from input to output
[22:56:18 CET] <JEEB> -f XXX is for the container format
[22:59:15 CET] <hololeap> [rtp @ 0x55f4c8500a20] Data doesn't look like RTP packets, make sure the RTP muxer is used
[22:59:22 CET] <hololeap> what is the flag for setting the muxer?
[22:59:47 CET] <JEEB> -f XXX
[23:00:29 CET] <JEEB> there's at least two muxers that have rtp in their name
[23:00:32 CET] <JEEB> rtp and rtp_mpegts
[23:04:20 CET] <hololeap> yeah, i'm not sure what's going wrong: https://paste.pound-python.org/show/98jf0P6eAPjDVnNf8AEe/
[23:05:45 CET] <JEEB> well for one thing you've forgotten the "please do not re-encode this" switch
[23:05:51 CET] <JEEB> which I mentioned earlier
[23:06:35 CET] <JEEB> the rest I don't know but you might also need -re before -i INPUT to simulate reading the input with a specific speed
[23:06:45 CET] <JEEB> which basically sleeps between reads :P
[23:06:53 CET] <hololeap> right... and i figured out the other part. it was apparently trying to use a <1024 port as non-root. it seems to be working now.
[23:13:05 CET] <hololeap> is there a way to slow down the transcoding so that it outputs at 1:1 speed in relation to the length of the file? it seems to be trying to output as fast as possible
[23:13:38 CET] <JEEB> I mentioned an option for the sleep()s ;P
[23:13:55 CET] <hololeap> oh, sorry :)
[23:18:14 CET] <hololeap> it's working great, thanks JEEB ... except that it is broadcasting to the address i specified over the wrong interface. it is using lo... you wouldn't happen to know how to change that, would you?
[23:19:12 CET] <JEEB> I would looke at hte AVOptions for the rtp protocol
[23:19:44 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#rtp
[23:19:51 CET] <JEEB> there's probably a way to get it through teh command line as well
[23:20:57 CET] <hololeap> hmm... yeah i don't see anything that talks about the interface unfortunately
[23:21:31 CET] <hololeap> i might be able to work around it with iptables
[23:21:55 CET] <JEEB> yea, the UDP protocol had an option -localaddr
[23:22:06 CET] <JEEB> which let you force the interface with a specific address
[23:22:18 CET] <JEEB> (it was useful with multicast if your routes were incorrectly set for receiving)
[23:23:40 CET] <JEEB> I think the RTP protocol underneath uses the UDP protocol but to be honest I've not looked into RTP in lavf enough :P
[23:26:54 CET] <hololeap> i tried rtp://, but it didn't make a difference
[23:27:37 CET] <JEEB> yea because the rtp thing doesn't take that thing in and you have to separately pass things through :P
[23:27:46 CET] <JEEB> within lavf
[23:28:17 CET] <JEEB> and tbh I didn't check enough of the code to see if the UDP code is actually using stuff from udp.c
[00:00:00 CET] --- Mon Nov 12 2018

More information about the Ffmpeg-devel-irc mailing list