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

[burek]

[00:37:04 CEST] <cryptodechange> Here are my mpv screenshots from the tonemap tests
[00:37:07 CEST] <cryptodechange> https://imgur.com/a/ifKhhld
[00:37:15 CEST] <cryptodechange> Included the 4k and 1080p raw screenshots too
[00:38:16 CEST] <cryptodechange> BT709 with no tonemapping is blown out, hable tonemap is too dull
[00:38:31 CEST] <cryptodechange> @JEEB @haasn
[00:39:26 CEST] <cryptodechange> I'm guessing mpv is doing its own tonemapping (opencl as you mentioned) which looks superior to the ffmpeg tonemapped version
[00:39:34 CEST] <cryptodechange> and closer to the raw 1080p version
[00:50:50 CEST] <JEEB> cryptodechange: it's just that the 100% cpu-only version hasn't been updated while the intel guy made the opencl filter based on newer stuff in mpv
[00:53:56 CEST] <Zexaron> So I kinda slowly started the ffmpeg upgrade for dolphin-emu ... which I talked aroun here a few times, I have all the logs of the stuff so no need to re-explain, just switching the container format was straightforward, MKV ... but it's still with all existing "ticks" implementation code
[00:54:31 CEST] <Zexaron> But I though it would be better to go slower and test it out and see how this MKV file looks like underneath
[00:55:13 CEST] <Zexaron> I've ran it with ffprobe - are these ffprobe settings deep enough? ffprobe -v debug -show_format -show_streams -analyzeduration 900000000 -probesize 23554432 framedump0.mkv
[00:55:58 CEST] <JEEB> umm
[00:56:06 CEST] <JEEB> that's a crapload of stuff
[00:56:27 CEST] <JEEB> I think at that point something like -show_packets might be more useful, but dunno :P
[00:56:35 CEST] <JEEB> also if you want to see matroska-specifics there's mkvinfo
[00:56:46 CEST] <Zexaron> I was about to
[00:56:55 CEST] <Zexaron> look into toolnix mkv stuff
[01:03:47 CEST] <Zexaron> just thought if someone notices anything odd https://gist.github.com/Zexaron/406916ad620e14a20af4e78f3b7e54a6
[01:05:05 CEST] <Zexaron> the video shouldn't show signs of lag, it should be smooth, as if lag never happened in real-time recording
[01:07:52 CEST] <Zexaron> Well I'm not actually sure how it's suppose to be, 1. suppose to be right  2. suppose to be in actual existing implementation and 3. in this mkv version
[01:09:02 CEST] <Zexaron> I did upload some if anyone wants to check as well, this is just preliminary, I'll be digging into this a lot deeper after later weeks
[01:09:29 CEST] <Zexaron> https://mega.nz/#F!ufxmmQKb!DXxB8LxfrIiw8ra6-lmryg
[01:25:27 CEST] <Zexaron> JEEB: Actually the inital thing other people pointed why it's not right is because AVI doesn't support VFR, but now I'm figuring out, that technically dumping frames doesn't even have the VFR aspect, there's no time-between-images saved anywhere, you'd have to pick a fixed FPS manually and get a smooth file out, no slowdowns would be visible
[01:26:54 CEST] <Zexaron> So if the current implementation doesn't actually do it like this and attempts to go with timecodes to make it like a real video, that may be the fundamental issue, unless they wanted it that way for some reason which I'm figuring out now why ...
[01:31:17 CEST] <cryptodechange> @JEEB according to this https://patchwork.ffmpeg.org/patch/9032/
[01:31:32 CEST] <cryptodechange> FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \ opencl=ocl at va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \ vaapi -i INPUT -filter_hw_device ocl -filter_complex \ '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \ [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 OUTPUT
[01:31:47 CEST] <cryptodechange> Something to do with tonemapping vaapi codecs
[01:32:25 CEST] <JEEB> yea, that basically I think is what intel is trying to make possible with that stuff
[01:32:36 CEST] <JEEB> a full vaapi-based flow without taking the images back into RAM :P
[01:32:43 CEST] <JEEB> so of course their example is all about that
[01:39:22 CEST] <cryptodechange> now to build ffmpeg and figure out how to change the filter chain
[02:04:12 CEST] <fahadash> https://www.irccloud.com/pastebin/PTOUQbMi/
[02:04:50 CEST] <fahadash> What does this error mean? I am trying to  concat 4 inputs together, They are exact same frame width and height, first and last has audio, the middle 2 does not have any audio
[08:36:13 CEST] <haasn> is there any good downloader tool for imgur?
[08:36:19 CEST] <haasn> youtube-dl doesn't support image albums :/
[09:09:08 CEST] <Adcock> Is it possible to encode OGV video with VP9 codec?
[09:22:30 CEST] <haasn> Adcock: doesn't seem like it
[09:22:41 CEST] <haasn> use something like webm instead
[09:23:18 CEST] <Adcock> haasn: It has an unusual name.
[09:23:34 CEST] <haasn> what do you mean?
[09:23:39 CEST] <Adcock> Is it suitable for everyday use?
[09:23:49 CEST] <haasn> webm is probably the most widely used container format
[09:23:51 CEST] <Adcock> I am talking about webm.
[09:24:18 CEST] <haasn> I'd guess either webm or mp4 (both support VP9 btw)
[09:24:23 CEST] <Adcock> Oh.
[09:25:31 CEST] <haasn> actually I guess the most popular container format is whatever netflix uses internally :p
[09:25:44 CEST] <Adcock> :D
[09:27:06 CEST] <Adcock> I will try mp4 then.
[09:30:00 CEST] <haasn> if you have a choice I would personally use webm
[09:30:08 CEST] <haasn> just because it's free whereas mp4 is patent encumbered
[09:30:53 CEST] <Adcock> Then how is it open format?
[09:30:57 CEST] <nate> webm was mostly a chrome thing, firefox eventually implemented some support but others need a codec installed
[09:31:16 CEST] <nate> Adcock: Just because something is patented doesn't mean it's not openly available
[09:31:56 CEST] <nate> Adcock: 3/4 of the things you use on a daily basis likely have a patent related to them, just not everyone enforces patents for profit
[09:32:11 CEST] <Adcock> Oh
[09:32:48 CEST] <nate> But yeah if you're trying to be largely-supportive, MP4 is going to likely be your main focus, as it's support is far more vast (and mostly due to it's ability to handle 'copyright' material)
[09:33:30 CEST] <haasn> what browsers handle VP9-in-MP4 but not VP9-in-WebM?
[09:34:02 CEST] <haasn> I don't know of anything that bothers to have VP9 support but not WebM
[09:34:40 CEST] <Adcock> Okay.
[09:34:46 CEST] <Adcock> MKV-VP9?
[09:36:49 CEST] <haasn> WebM is a subset of MKV
[09:37:16 CEST] <Adcock> What, I just learned!
[09:39:43 CEST] <Adcock> Oh.
[09:40:07 CEST] <Adcock> Atleast, I like .mkv more than .webm :D
[09:40:25 CEST] <Adcock> I just hate that name.
[09:41:11 CEST] <haasn> encode as webm and rename to .mkv :D
[09:41:40 CEST] <Adcock> :D
[09:49:23 CEST] <Adcock> Okay. Thanks guys. I will inform you on  results.
[09:59:33 CEST] <nate> haasn: VP9 w/ MP4 is exceptionally unusual to see, MP4 in browsers will almost always be H.264
[10:03:18 CEST] <Adcock> https://superuser.com/questions/705579/convert-video-with-vp9-codec-using-ffmpeg/901702
[10:03:32 CEST] <Adcock> I can't understand the 2 pass thing.
[10:03:44 CEST] <Adcock> Can someone explain, please?
[10:04:13 CEST] <Adcock> Btw, my vp9/ogg/mp4 is ready.
[10:04:26 CEST] <Adcock> The audio quality is similar.
[10:04:43 CEST] <Adcock> But video quality lags a bit.
[10:04:50 CEST] <Adcock> Here and there.
[10:05:14 CEST] <Adcock> Looks like it tried to encode correctly.
[10:05:39 CEST] <Adcock> So, some scenes are totally hight resolution.
[10:06:07 CEST] <Adcock> But I still want to give mkv/webm and vp9 a try.
[10:06:21 CEST] <Adcock> With a second pass.
[10:06:32 CEST] <Adcock> But what is a second pass.
[10:06:33 CEST] <Adcock> ?
[10:07:39 CEST] <haasn> 2 pass encoding splits up the encoding into a data-gathering pass and an encoding pass
[10:07:53 CEST] <haasn> (or technically I think it's just two encoding passes)
[10:08:03 CEST] <Adcock> Okay.
[10:08:29 CEST] <Adcock> But do I use two commands like shown in the link?
[10:08:48 CEST] <Adcock> I mean:
[10:09:01 CEST] <Adcock> Do I need to do this:
[10:09:13 CEST] <Adcock> fmpeg -y -i input.mkv -c:v libvpx-vp9 -b:v 2000k -pass 1 -an -f webm /dev/null
[10:09:18 CEST] <Adcock> before doing this :
[10:09:30 CEST] <Adcock> fmpeg    -i input.mkv -c:v libvpx-vp9 -b:v 2000k -pass 2 -c:a opus -b:a 64k -f webm output.webm
[10:09:31 CEST] <Adcock> ?
[10:09:37 CEST] <haasn> seems about right I'd guess
[10:09:57 CEST] <Adcock> :)
[10:11:05 CEST] <Adcock> I will notify you of the results.
[10:20:43 CEST] <grosso> hi
[10:22:47 CEST] <grosso> i'm trying to stream from ffmpeg to vlc, using mpegts over udp
[10:23:14 CEST] <grosso> audio is aac, video is h264... audio works, video don't
[10:25:39 CEST] <Adcock> https://pastebin.com/wA5qp8km
[10:45:39 CEST] <Adcock> Okay.
[10:45:42 CEST] <Adcock> I got it.
[10:45:45 CEST] <Adcock> :)
[10:57:52 CEST] <pl0q> hello guys, I tried to compress real-time stream via h264_amf and I got next error when I try to decode this: non-existing PPS 0 referenced / decode_slice_header error / no frame! i can't find anything bad in logs (server_log - https://pastebin.com/hSpPY7dc , client_log - https://pastebin.com/cmJqyfB7). But when i switch to default encoder (AV_CODEC_ID_H264) it works well. Could someone tell me, what did I do wrong?
[11:08:28 CEST] <th3_v0ice> Can anyone explain how to properly change pixels of the YUV420P AVFrame? I tried changing the pixels with pixels from another AVFrame, but they are not in the right position. Luma component is, but the other two are off, like they need to be divided by 2.
[11:11:39 CEST] <Mavrik> Well yes.
[11:11:45 CEST] <Mavrik> That's what 420 means :P
[11:11:54 CEST] <Mavrik> The chroma components are subsampled and have 1/2 of resolution
[11:37:31 CEST] <Zexaron> Anyone familiar if the Cracki guy is still around ?
[11:37:39 CEST] <Zexaron> not here right now but in general
[11:55:09 CEST] <Zexaron> Anyway, he's the one that took a look into the code, we assumed all wrong that the system is (or has to) creating an actual video, VFR, but it's not, it's only suppose to concat frames, individual images, as they're output, without any timecode/pts information whatsoever, into a manual fixed FPS i presume, but I'm not sure 100% on that (some games are 60, but most are 30, or 25 and 50 for PAL)
[11:56:17 CEST] <Zexaron> So he mentioned some kind of "ticks" variable, and well ofcourse it didn't make sense for VFR ... but it's not suppose to be VFR, so that means the code is okay, or it can be improved in the correct direction ?
[11:56:31 CEST] <Zexaron> https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/AVIDump.cpp
[11:56:45 CEST] <Zexaron> and https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/RenderBase.cpp
[11:58:56 CEST] <Zexaron> Apparently, my understanding is right now, that it's simply dumping frames into one file, as a video, same way you'd be doing offline merge of a bunch of images, with the convenience it does all that in one step, that's quite different than early assumptions
[13:57:32 CEST] <illuminated> what does mean volume/max volume mean on the volumedetect audio filter mean?
[14:12:41 CEST] <durandal_1707> illuminated: max volume to give to volume filter and not cause clipping
[14:14:00 CEST] <illuminated> I assume, then, that's what 'max volume' means.  What is 'mean volume'?
[14:31:16 CEST] <durandal_1707> illuminated: mean volume of or bins taking in account probably
[14:31:26 CEST] <durandal_1707> s/or/all
[14:33:05 CEST] <illuminated> I guess it just means the 'average' volume.
[16:15:03 CEST] <zivanovicb> Working on transcoding on the fly with nodejs & ffmpeg where file should get uploaded & transcoded at the same time. So far it's cool on local machine where upload is actually fast, but on the remote servers, ffmpeg is so much faster than upload and it simply exits when there is no data coming from pipe.
[16:15:06 CEST] <zivanovicb> Any thoughts how to solve this?
[16:16:33 CEST] <BtbN> It should just block when reading from stdin if no data is available but the pipe still open
[16:19:55 CEST] <zivanovicb> so there is a way i can tell ffmpeg how to deal with a stream? now, only thing i do is: ffmpeg pipe:0 and everything else is handled by ffmpeg itself
[16:20:21 CEST] <zivanovicb> not sure what you mean by "block when reading from stdin"
[17:27:30 CEST] <grosso> VLC unable to play udp/mpegts/h264 stream
[17:34:45 CEST] <cryptodechange> Am I able to pipe mpv's hdr tonemapping into ffmpeg? (sorry I just messaged this question, I disconnected and wasn't sure it was sent)
[17:57:25 CEST] <JEEB> cryptodechange: I don't think so since the encoding part of mpv is rather separate from the video rendering part. there's a path from the renderer to a bitmap though since we do screenshots through the renderer
[18:00:13 CEST] <cryptodechange> I'm assuming opencl tonemapping requires hardware acceleration (-hwaccel vaapi)
[18:00:27 CEST] <JEEB> it shouldn't require vaapi
[18:00:28 CEST] <JEEB> at all
[18:00:31 CEST] <JEEB> only opencl
[18:00:44 CEST] <JEEB> the example posted by the intel dude unsurprisingly has vaapi there
[18:00:49 CEST] <cryptodechange> Oh ok - https://patchwork.ffmpeg.org/patch/9032/
[18:00:55 CEST] <cryptodechange> Yeah, I guess he just used it as an example
[18:01:01 CEST] <cryptodechange> But does it require intel integrated graphics?
[18:01:03 CEST] <JEEB> because what they want is a no-software pipe line
[18:01:06 CEST] <JEEB> no, it does not
[18:01:09 CEST] <JEEB> it's opencl
[18:01:18 CEST] <JEEB> anything that can run opencl (including your CPU)
[18:01:22 CEST] <JEEB> can run cpu
[18:01:26 CEST] <JEEB> *can run opencl
[18:03:24 CEST] <cryptodechange> -filter_hw_device ocl -filter_complex \ '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \ [x1]hwmap=derive_device=vaapi:reverse=1'
[18:03:33 CEST] <cryptodechange> Just trying to decipher this
[18:03:42 CEST] <JEEB> it takes the video from input 0
[18:03:45 CEST] <JEEB> [0:v]
[18:03:53 CEST] <JEEB> then it does hw mapping (whatever that is)
[18:04:14 CEST] <JEEB> runs the tonemap, and does a hwmap in reverse into vaapi?
[18:04:42 CEST] <JEEB> and then the output is whatever implicit thing there is for video, probably
[18:07:18 CEST] <cryptodechange> Aha, so -filter_complex '[0:v]...' is the equivelant to -filter:v:0
[18:08:06 CEST] <cryptodechange> I'll give it a go
[18:08:46 CEST] <JEEB> well not really, since I don't think -filter is a thing like that
[18:09:03 CEST] <JEEB> but yes, the complex filter chain starts with 0:v as the input
[18:09:07 CEST] <cryptodechange> I presume I use 'tonemap_opencl=t=bt2020:tonemap=linear:format=p010' to replace 'zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0'
[18:09:38 CEST] <cryptodechange> Actually, what filter does mpv use?
[18:09:46 CEST] <cryptodechange> linear, hable, etc
[18:10:09 CEST] <JEEB> https://mpv.io/manual/master/#options-tone-mapping
[18:10:22 CEST] <JEEB> default is hable as far as I can tell
[18:11:17 CEST] <cryptodechange> Yeah looks like it
[18:12:20 CEST] <cryptodechange> So to convert bt2020 to bt709 via. tonemap_opencl, 'tonemap_opencl=t=bt709:tonemap=hable:format=p010'
[18:12:25 CEST] <cryptodechange> not sure what the format part is
[18:12:30 CEST] Action: cryptodechange checks github
[18:12:45 CEST] <JEEB> yea, that's not hte format filter but a parameter for the tonemap_opencl filter
[18:13:02 CEST] <JEEB> whatever that means. p010 is the format that hw decoders output for 10bit video
[18:13:42 CEST] <JEEB> so most likely it has something to do with the input? although you'd really have to look at the help inside the filter code (or if you built with it, I think ffmpeg.c can output it as well)
[18:14:11 CEST] <cryptodechange> "format",    "output pixel format"
[18:14:19 CEST] <JEEB> oh, output
[18:14:30 CEST] <cryptodechange> av_log(avctx, AV_LOG_WARNING, "format not set, use default format NV12\n");
[18:14:31 CEST] <JEEB> interesting, so the example also encodes in 10bit
[18:14:42 CEST] <JEEB> lol, nv12 as default. makes sense for HW
[18:14:52 CEST] <JEEB> but most of the software stack takes in yuv420p
[18:14:58 CEST] <JEEB> or other fully planar formats
[18:15:11 CEST] <JEEB> (depending on the usage NV12 can be useful though, x264 for example internally takes in NV12)
[18:15:16 CEST] <cryptodechange> hm, the only options are apparently p010 or nv12
[18:15:17 CEST] <cryptodechange> av_log(avctx, AV_LOG_ERROR, "unsupported output format," "only p010/nv12 supported now\n");
[18:15:22 CEST] <JEEB> ok
[18:15:27 CEST] <JEEB> then it's just those two
[18:15:37 CEST] <JEEB> nv12 at least has unpacking to yuv420p
[18:15:44 CEST] <JEEB> p010... also, maybe?
[18:18:23 CEST] <Mavrik> Why does HW love their nv12 so much?
[18:22:38 CEST] <cryptodechange> tonemap_opencl todo list, according to the comments
[18:22:41 CEST] <cryptodechange> separate peak-detection from tone-mapping kernel to solve one-frame-delay issue, import colorspace matrix generation from vf_colorspace.c, more format support
[18:24:58 CEST] <JEEB> Mavrik: the packing of the chroma planes seems to help with some stuff
[18:25:09 CEST] <JEEB> also that's the reason why x264 went internally NV12
[18:25:27 CEST] <JEEB> as it helped with just CPU stuff as well specifically in case with x264
[18:25:36 CEST] <JEEB> (so if you feed x264 planar stuff it will internally pack the stuff)
[18:36:05 CEST] <cryptodechange> tonemap_opencl is just part of libavfilter right? nothing special I need to enable from master?
[18:36:50 CEST] <durandal_1707> cryptodechange: opencl support compiled in
[18:39:26 CEST] <cryptodechange> [AVFilterGraph @ 0x5a3c940] No such filter: 'tonemap_opencl'
[18:48:19 CEST] <Mortir> Hi
[18:48:49 CEST] <Mortir> Could somebody clarify to me what's the difference between these two commands: https://privatebin.net/?bb7647b8856ee60b#Bugq4J7Oys6fcDnYhgAIjkmbsGhQ8HEtOvfkm81EBL4=
[18:49:32 CEST] <Mortir> I've already used them and obtained apparent equivalent results.
[19:08:01 CEST] <Hello71> is this one of them ridiculous javascript pastebins
[19:13:19 CEST] <cryptodechange> btw I tried using today's git static build from johnvansickle.com
[19:15:06 CEST] <cryptodechange> https://johnvansickle.com/ffmpeg/
[19:15:08 CEST] <furq> Mortir: there is no difference
[19:19:22 CEST] <relaxed> cryptodechange: my builds lack opencl support
[19:22:13 CEST] <cryptodechange> relaxed, do you have time to compile a git build with opencl? I'll be sure to drop a BTC donation
[19:24:00 CEST] <Mortir> furq: Understood, thanks.
[19:32:46 CEST] <Mortir> Hello71: It does uses javascript, but is mainly built with PHP as far as I know.
[20:38:00 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libvorbis output.ogg
[20:38:14 CEST] <Adcock> This creates a file with theora.
[20:38:25 CEST] <Adcock> But input is an audio flac file.
[20:38:58 CEST] <Adcock> Stream 0 contains theora.
[20:39:03 CEST] <Adcock> Please help.
[20:44:39 CEST] <furq> Adcock: -vn
[20:44:52 CEST] <Adcock> Oh.
[20:45:24 CEST] <furq> cover art is treated as video by ffmpeg, which works great if it's a format that doesn't also support video
[20:46:14 CEST] <Adcock> Hmmm.
[20:46:21 CEST] <Adcock> :D
[20:47:26 CEST] <JEEB> I think there was an option to not take in cover art into mention
[20:47:37 CEST] <JEEB> cover art handling is kind of unfortunate in FFmpeg at the moment
[20:56:54 CEST] <Adcock> JEEB: Thanks. Things are normal now.
[20:56:56 CEST] <Adcock> :)
[20:59:01 CEST] <Adcock> Opps.
[20:59:09 CEST] <Adcock> Need help again.
[20:59:32 CEST] <Adcock> Ogg chooses its bitrate on its own.
[20:59:45 CEST] <Adcock> It uses vbr I think.
[20:59:56 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libvorbis -vn -q:a 10 -ar 22050 output.ogg
[21:00:39 CEST] <Adcock> But opus needs a bitrate to be defined.
[21:00:43 CEST] <Adcock> Why?
[21:00:46 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libopus -vn -vbr on -compression_level 10 output.opus
[21:00:54 CEST] <kepstin> because they're different codecs that take different options
[21:00:58 CEST] <furq> pretty much that
[21:01:14 CEST] <furq> they both use a similar vbr system iirc
[21:01:25 CEST] <furq> just vorbis has -q mapped to nominal bitrates and opus uses the nominal bitrates directly
[21:01:28 CEST] <furq> which honestly makes more sense
[21:01:37 CEST] <Adcock> When vbr is on why would it ask me for bitrate?
[21:01:41 CEST] <kepstin> the "-q:a 10" option basically just picks a vbr bitrate automatically depending on channel count, sample rate, etc.
[21:01:45 CEST] <furq> because vbr has a nominal bitrate
[21:01:46 CEST] <kepstin> in libvorbis
[21:02:03 CEST] <furq> or a target bitrate in other codecs
[21:02:03 CEST] <kepstin> but opus doesn't have a preset system like that, so you have to specify a bitrate directly.
[21:02:16 CEST] <furq> it's basically still the same thing
[21:02:16 CEST] <Adcock> Anything like that for opus?
[21:03:05 CEST] <furq> https://wiki.hydrogenaud.io/index.php?title=Recommended_Ogg_Vorbis#Recommended_Encoder_Settings
[21:03:09 CEST] <Adcock> I just want it to auto detect like vorbis.
[21:03:12 CEST] <Adcock> Can that be doen?
[21:03:15 CEST] <furq> vorbis doesn't autodetect
[21:03:31 CEST] <furq> -q 10 is basically the same as using -b:a 500k with opus
[21:03:38 CEST] <kepstin> when you specify the -q option for libvorbis, it looks up a target bitrate in a table, basically
[21:03:42 CEST] <furq> right
[21:03:47 CEST] <furq> the table is in the thing i just linked
[21:04:05 CEST] <kepstin> (although i think it handles multichannel stuff, so it'll pick a different rate automatically for e.g. stereo vs mono)
[21:04:27 CEST] <kepstin> that would be nice to have in libopus imo, but nobody's implemented it, so... it is what it is.
[21:05:14 CEST] <furq> also i don't think it's a target bitrate in either case, it's a nominal bitrate
[21:05:33 CEST] <furq> they encoded a test corpus with those settings and it came out at 128k, so these are the 128k settings
[21:05:44 CEST] <kepstin> ah, yeah.
[21:05:46 CEST] <furq> it won't actually attempt to hit 128k on your particular sample
[21:06:16 CEST] <kepstin> both codecs also have a abr mode that'll actually attempt to maintain a target bitrate.
[21:06:18 CEST] <furq> right
[21:06:22 CEST] <furq> and opus has a cbr mode iirc
[21:06:33 CEST] <furq> but the default ratecontrol is basically the same as vorbis -q
[21:07:00 CEST] <furq> except you don't have to remember what all the -q settings correspond to
[21:07:14 CEST] <furq> also it's worth mentioning that -q 10 is insane overkill
[21:07:44 CEST] <furq> 6 should be pretty much transparent
[21:07:45 CEST] <kepstin> you're usually better off using flac if you're considering -q 10, yeah :)
[21:10:42 CEST] <Adcock> What would -q 6 mean for opus?
[21:11:13 CEST] <Adcock> -b:a 220000?
[21:11:21 CEST] <furq> -b:a 192k
[21:11:49 CEST] <furq> i'd probably go even lower than that for opus
[21:12:17 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libopus -vn  -b:a 192k -ar 22050 -vbr on -compression_level 10 output.opus
[21:12:24 CEST] <kepstin> yeah, opus will generally sound better at the same bitrate as vorbis.
[21:12:25 CEST] <Adcock> not supported?
[21:12:27 CEST] <furq> you don't need -vbr on
[21:12:34 CEST] <kepstin> Adcock: also, why are you downsampling to 22kHz?
[21:12:35 CEST] <furq> and also opus doesn't support 22.05k
[21:12:45 CEST] <furq> only multiples of 8k
[21:13:06 CEST] <furq> and yeah you definitely don't need 192kbps for 22.05k
[21:13:12 CEST] <furq> (or 24k)
[21:13:19 CEST] <Adcock> Humans cant only hear upto 20KHz on average.
[21:13:39 CEST] <Adcock> Maybe 22KHz.
[21:13:47 CEST] <Adcock> More than that is just over kill.
[21:13:55 CEST] <kepstin> Adcock: you need >40KHz sampling rate to reproduce 20KHz audio
[21:13:57 CEST] <Adcock> Loss of space.
[21:14:00 CEST] <furq> what he said
[21:14:36 CEST] <furq> the actual audible frequency of pcm is half the sampling rate
[21:14:40 CEST] <furq> highest
[21:14:52 CEST] <furq> https://en.wikipedia.org/wiki/Nyquist_frequency
[21:16:56 CEST] <Adcock> Oh.
[21:17:28 CEST] <Adcock> So it means I give in 40K but I actually get 20K
[21:17:30 CEST] <Adcock> ?
[21:17:30 CEST] <kepstin> Adcock: anyways, nyquist/shannon sampling theorem explains why sampling rates like 44.1KHz or 48KHz are typically used - it's enough to reproduce up to 20KHz audio accurately, plus some headroom for audio filters to use.
[21:18:00 CEST] <Adcock> Wait.
[21:18:05 CEST] <kepstin> you specify the sampling rate with the -ar option. Any given sampling rate can reproduce frequencies up to 1/2 the sampling rate.
[21:18:30 CEST] <Adcock> It has got nothing to do with hearing directly.
[21:18:59 CEST] <Adcock> So what you mean is 20K will reprodude only 10K or lower but not 15K?
[21:19:04 CEST] <furq> yes
[21:19:15 CEST] <Adcock> Hmmm.
[21:19:52 CEST] <Adcock> That still doesn't make sense why I should not make 22k audios?
[21:20:01 CEST] <furq> because it'll cut off everything above 11khz
[21:20:17 CEST] <Adcock> What?
[21:20:44 CEST] <kepstin> a 22KHz sampling rate can reproduce frequencies up to 11KHz.
[21:20:57 CEST] <kepstin> people can hear frequencies up to around 20KHz normally.
[21:21:02 CEST] <Adcock> Even when decoding?
[21:21:34 CEST] <furq> when else would it be reproducing it
[21:21:46 CEST] <kepstin> decoding/encoding has nothing to do with it, this is a mathematical property of how discrete sampling works.
[21:22:34 CEST] <Adcock> Hmmm.....
[21:22:56 CEST] <Adcock> So I should always use 40K or higher, I guess.
[21:23:05 CEST] <Adcock> This only means bigger sizes.
[21:23:18 CEST] <Adcock> Thanks guyz.
[21:23:25 CEST] <kepstin> no reason to use anything higher than 44.1KHz or 48KHz tho
[21:23:25 CEST] <Adcock> I didn't know that.
[21:23:27 CEST] <furq> well you were using 500kbps vorbis anyway
[21:23:44 CEST] <furq> which is at least twice as big as it would need to be for 48khz
[21:24:08 CEST] <kepstin> yeah. Use a higher sample rate, and lower encoding bitrate, and you'll have files the same size or smaller which sound better.
[21:24:15 CEST] <Adcock> So thats why I didn't feel any lags?
[21:25:08 CEST] <Adcock> SO I WAS A AUDIO HACKER / AUDIO THIEF?
[21:25:10 CEST] <Adcock> :d
[21:25:16 CEST] <kepstin> reducing the sampling rate to 22KHz (cutting off frequencies above 11KHz) will give most music a kind of "muddy" low fidelity sound.
[21:25:41 CEST] <Adcock> Oh.
[21:25:50 CEST] <Adcock> Again.
[21:26:22 CEST] <Adcock> So what would be the correct way?
[21:27:39 CEST] <kepstin> there's no single "correct" way, but using a sample rate or 44.1KHz or 48KHz and a libvorbis "-q:a" setting around 6 or a libopus bitrate around 128-160kbps is generally good for most stereo music.
[21:28:01 CEST] <Adcock> :)
[21:28:10 CEST] <Adcock> Thank you.
[21:28:12 CEST] <kepstin> I'm probably specifying a libopus bitrate a bit higher than you need, tbh
[21:29:11 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libopus -vn  -b:a 128k -ar 48000 -vbr on -compression_level 10 output.opus
[21:29:18 CEST] <Adcock> I just did this.
[21:29:28 CEST] <Adcock> VLC Won't show bitrate.
[21:29:30 CEST] <Adcock> Why?
[21:29:42 CEST] <kepstin> i dunno, vlc bug?
[21:29:47 CEST] <Adcock> :D
[21:29:57 CEST] <furq> that's generally a safe answer
[21:31:14 CEST] <kepstin> note that "-compression_level" option defaults to 10 on libopus, no reason to specify it.
[21:32:00 CEST] <furq> same with -vbr on
[21:32:29 CEST] <Adcock> 10 means best compression, right?
[21:33:22 CEST] <furq> yeah
[21:33:34 CEST] <kepstin> Adcock: options are documented at https://www.ffmpeg.org/ffmpeg-codecs.html#libopus-1
[21:35:02 CEST] <Adcock> I knew.
[21:35:26 CEST] <Adcock> But when an expert says something, I get confused.
[21:35:30 CEST] <Adcock> :(
[21:36:09 CEST] <Adcock> Anyway, ffmpeg can tell who uses what bitrate.
[21:36:18 CEST] <Adcock> That I guess will do.
[21:36:24 CEST] <Adcock> :)
[21:36:45 CEST] <furq> i take it from %INPUT% that you're on windows
[21:36:51 CEST] <furq> in which case fb2k will tell you the bitrate
[21:37:48 CEST] <Adcock> Why?
[21:38:04 CEST] <Adcock> Wouldn't it tell me on linux?
[21:38:12 CEST] <furq> no because it's windows-only
[21:38:25 CEST] <furq> i guess it could tell you in wine but there are easier ways to do it then
[21:39:04 CEST] <Adcock> Seriously.
[21:39:17 CEST] <Adcock> Why, oh why devs would do that?
[21:40:26 CEST] <furq> it's been around since 2002
[21:40:34 CEST] <furq> idk if wx or qt or anything like that even existed then
[21:44:31 CEST] <Adcock> At last, it seems ogg vorbis make files smaller that Opus.
[21:46:21 CEST] <kepstin> you can make the opus files smaller, just choose a lower bitrate...
[21:46:34 CEST] <kepstin> size is something you control
[21:46:41 CEST] <Adcock> Quality?
[21:47:32 CEST] <kepstin> in almost all cases, an opus file will sound better than a vorbis file at the same bitrate (the lower the bitrate, the bigger the difference)
[21:48:00 CEST] <kepstin> so for the same quality, you can normally use a lower bitrate for opus than you used for vorbis.
[21:48:07 CEST] <kepstin> (aka lower file size)
[21:48:51 CEST] <Adcock> Opus defaults to 96k for bitrate.
[21:49:03 CEST] <Adcock> What do you think about it?
[21:49:20 CEST] <kepstin> that's probably a fairly reasonable bitrate for stereo music.
[21:49:31 CEST] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png
[21:49:33 CEST] <furq> you tell me
[22:54:59 CEST] <Zexaron> hey furq do you remember when I talked about the ffmpeg integration with dolphin, the AVI stuff
[22:55:17 CEST] <Zexaron> not sure if you seen my msgs yesterday, but that talk was like early summer
[22:56:02 CEST] <Zexaron> It turns out that it's not using VFR ... nor an image slideshow with a fixed framerate
[22:58:38 CEST] <Zexaron> but some kind of emulated wall time
[23:00:31 CEST] <Zexaron> is this anywhere familiar to you guys
[00:00:00 CEST] --- Tue Oct 16 2018