Start of #opus buffer: Sun Mar 24 20:21:05 2019
[18:26] * Now talking in #opus
[18:26] * Topic is 'https://opus-codec.org | IETF codec development and discussion | https://git.xiph.org/?p=opus.git | latest releases: opus 1.3, opus-tools 0.2, opusfile 0.11, libopusenc 0.2.1'
[18:26] * Set by mark4o on Fri Feb 01 22:28:39 2019
[18:27] <damdai> i was told opusenc  does not support  44.1khz : is this true?
[18:31] <+gmaxwell> No.
[18:32] <damdai> then why people in #ffmpeg say that
[18:33] <+gmaxwell> No idea.
[18:33] <damdai> <faLUCE> damdai: the available sample rates are      48000, 24000, 16000, 12000, 8000,
[18:34] <+gmaxwell> I wouldn't be shocked if _ffmpeg_ (not opusenc) didn't support 44100, but openenc happily does.
[18:34] <damdai> it's it same thing
[18:34] <damdai> don't they both use same lib
[18:35] <+gmaxwell> It's not the same thing, libopus is fairly low level and mostly centered on providing whats needed for realtime streaming.
[18:38] * Joins: faLUCE (~paolo@151.35.200.58)
[18:39] <faLUCE> hello
[18:39] <damdai> if it does support 44.1  why would somebody post this?  https://github.com/xiph/opus/issues/43
[18:39] <damdai> faluce welcome
[18:39] <faLUCE> maybe it has been added recently
[18:39] <faLUCE> in this case it would be easy to update ffmpeg
[18:40] <damdai> gmaxwell did 44.1 get added recently?
[18:40] <faLUCE> bu I suspect that openenc makes a resampling
[18:40] <damdai> faluce are you ffmpeg dev?
[18:40] <faLUCE> no, but I use libavcodec intensively
[18:41] <damdai> libavcodec? what is that? is that same thing as saying "i use ffmpeg intensively"
[18:41] * Joins: jcea (~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00)
[18:41] <faLUCE> no, I code with the library of ffmpeg
[18:41] <faLUCE> so I know how to modify the code
[18:41] <damdai> faluce so you don't actually use the ffmpeg binary ?
[18:42] <faLUCE> damdai: yes, I use it as well, but I use more the library
[18:42] <damdai> faluce i see
[18:42] <+gmaxwell> https://0bin.net/paste/QqX3c1N9SnGYArz6#W0wazxWh3q3i6RZrp+z1dCIKQAQLHKah2aPfKpLh4pg
[18:42] <faLUCE> if 44.1 has been added, I can patch ffmpeg
[18:43] <damdai> if you are not a ffmpeg dev, how?
[18:44] <faLUCE> damdai: it's simple. You get the source code of ffmpeg, then you modify a line of opusenc.c
[18:44] <faLUCE> then you compile it
[18:44] <+gmaxwell> damdai: opusenc has always done 44.1k, since long before opus was finished.  Now the functionality is in libopusenc.
[18:44] <damdai> if it does support 44.1  why would somebody post this?  https://github.com/xiph/opus/issues/43
[18:44] <damdai> and faluce thinks it doesn't support 44.1
[18:45] <faLUCE> damdai: maybe it was posted when the functionality was not in libopus
[18:45] <faLUCE> damdai: ffmpeg uses libopus
[18:45] <+gmaxwell> The whole issue is throughly confused.
[18:45] <damdai> gmaxwell agreed
[18:45] <faLUCE> and currently ffmpeg doesn't wrap 44.1
[18:45] <+gmaxwell> I mean that github issue is confused.
[18:45] <faLUCE> gmaxwell: yes, because it refers to libopus but talks about opus in general
[18:46] <faLUCE> anyway, it woule be  very simple to patch ffmpeg
[18:46] <faLUCE> damdai: if you need it, I can tell you how
[18:46] <damdai> faluce try first and see if it works
[18:47] <faLUCE> damdai: I'm pretty sure it will work
[18:47] <damdai> if you have time
[18:47] <faLUCE> it's one line change
[18:47] <+gmaxwell> The opus _format_ works at 'sampling rates' of 400Hz, 200Hz, 100Hz, or 50Hz.  Libopus gives an interface that outputs at 48k and harmonically related rates.  Libopusenc will happily work with whatever rate you want (and the exact sample duration is preserved)
[18:47] <faLUCE> but let's infor ffmpeg people about that
[18:48] <faLUCE> inform
[18:48] <damdai> faluce join #ffmpeg-devel then
[18:48] <faLUCE> gmaxwell: in this case you are saying that it resamples to 48k
[18:49] <faLUCE> I though that now it outputs to 44.1 too
[18:49] <faLUCE> thought
[18:49] <+gmaxwell> faLUCE: however it works internally isn't really any of the callers business, .opus files support 44.1k just file, preserve the sample rate, and the exact sample count duration.
[18:49] <faLUCE> gmaxwell: I see. you are saying that in != out
[18:50] <faLUCE> so, ffmpeg people must be informed
[18:50] <damdai> faluce you so passionate about ffmpeg, you should be ffmpeg dev
[18:50] <faLUCE> damdai: I already do other dev things
[18:50] <faLUCE> with other libs
[18:50] <damdai> what dev are you then?
[18:51] <faLUCE> damdai: I have my own libs, and I contributed with cimg, for example
[18:51] <damdai> if you don't mind me asking
[18:51] <+gmaxwell> Libopus itself exposes only a limited number of sampling rates because those are the most computationally efficient,  because the opus format frame rates are not integer fractions of 44100.
[18:52] <faLUCE> damdai: but I'm not a real passionate...
[18:57] <damdai> gmaxwell are you a opus dev?
[18:58] <faLUCE> gmaxwell: are you sure that the input is not resampled ?
[18:58] <faLUCE> (before processing, I mean)
[19:00] <+gmaxwell> damdai: I mostly wrote the original opusenc, though I haven't done much lately.
[19:00] <+gmaxwell> faLUCE: yes, it is as part of the processing, and?
[19:00] <damdai> i see, then you are a big deal to opus
[19:00] <faLUCE> gmaxwell: then ffmpeg people must be informed
[19:01] <faLUCE> gmaxwell: with a very simple patch libopus can be wrapped for  all the sample rates
[19:02] <faLUCE> I'll inform them tomorrow
[19:02] <+gmaxwell> I'm sure some people know.
[19:03] <faLUCE> maybe this has already been tracked
[19:03] <faLUCE> I made a zerolatency audio-video streamer with libopus and h264 and I find it excellent
[19:04] <faLUCE> I could not find any other audio encoder with so low latency
[19:04] <faLUCE> (open source)
[19:04] <damdai> faluce what other popular format/encoder has worst latency?
[19:05] <faLUCE> damdai: before opus I used aad, but it has 2 frames latency
[19:05] <faLUCE> about 40ms
[19:05] <faLUCE> AAC
[19:05] <damdai> which aac ?
[19:05] <faLUCE> ADTS-AAC
[19:05] <faLUCE> the one wrapped with ffmpeg
[19:05] <damdai> and opus has what ms  latency?
[19:05] <faLUCE> I used MP2 too, but it seems obsolete
[19:06] <faLUCE> damdai: I got even 5ms latency
[19:06] <damdai> wow, big difference
[19:06] <faLUCE> damdai: yes, for 30fps video it makes a big difference
[19:06] <damdai> how can opus have such a low latency?
[19:06] <faLUCE> damdai: I don't know but gmaxwell surely  knows :-)
[19:07] <faLUCE> gmaxwell: what's the secret of a so low latency ?
[19:07] <damdai> it's probably top secret
[19:07] <faLUCE> no, because it's all open
[19:08] <damdai> if opus is so open, why isn't  other opus encoders out there that are popular
[19:08] <damdai> isn't there*
[19:08] <faLUCE> damdai: open doesn't mean popular
[19:08] <+gmaxwell> why would there need to be? the original one is very good and free (both in cost and licensing) so everyone can use it.
[19:09] <+gmaxwell> And if someone wants to make it better they don't need to make their own, they can come collaborate.
[19:09] <damdai> because there are always people who thinks they can make it better and want to create their own
[19:10] <damdai> look at  ffmpeg  libav  feud
[19:10] <+gmaxwell> and some people try and find out that it's harder than they thought to beat a decade of work...
[19:10] <faLUCE> damdai: lot of people think the can make a video encoder better than h264
[19:10] <damdai> faluce you mean x264?
[19:11] <faLUCE> gmaxwell: like what it happened for h264. They though to beat decades of work and, at the end, the copied a subset
[19:11] <+gmaxwell> ffmpeg community has a long history of hot tempers too... most open source software doesn't split like that, it's not unheard of but it's not that common.
[19:11] <faLUCE> gmaxwell: what do you mean with "hot tempers" ?
[19:11] <faLUCE> rude people?
[19:12] <+gmaxwell> for formats like mp3/aac etc the reference encoders have not been good because of the business models of the authors... they kept their best encoders propritary. This contributes to a proliferation of encoders.
[19:12] <+gmaxwell> faLUCE: sometimes rude, sometimes easily angered, more often just being insensitive to other people even when they're right.
[19:12] <faLUCE> gmaxwell: I think this happened because ffmpeg is a huge project
[19:13] <faLUCE> I remember that for learing libavcodec I had to suffer
[19:13] <+gmaxwell> That contributes, but there are many huge projects which are more friendly. (and also, don't split :) )
[19:14] <+gmaxwell> I'm not even saying that there is anything wrong with that culture, but it's contributes to things like that forking.
[19:14] <faLUCE> gmaxwell: I see. I spent about 3 years in learning how libavcodec work
[19:14] <faLUCE> because of this kind of approach
[19:15] <faLUCE> gmaxwell: but  don't think other staffs of other libs are more kind
[19:15] <faLUCE> but they can also be very helpful
[19:16] <faLUCE> (ffmpeg people, I say)
[19:17] <faLUCE> honestly I find C people to be very rude, while C++ people more polite :-) :-)
[19:18] <damdai> lol , i wonder why that is
[19:20] <faLUCE> damdai: are you a developer too?
[19:20] <damdai> no
[19:21] <damdai> i am just a audiophile
[19:21] <faLUCE> I see
[19:22] <damdai> i am really interested in DSD these days
[19:22] <faLUCE> what is dsd
[19:22] <damdai> it's another format which is competition to PCM
[19:23] <damdai> it uses 1 bit  and 2.8mhz
[19:23] <damdai> instead of pcm which likes to use 16/24  48/96 khz
[19:24] <faLUCE> damdai: I won't go over the possibilities of human ears
[19:24] <faLUCE> :-)
[19:28] <damdai> if audio format has high latency, does it cause problem with video-audio-file.mp4  video and audio syncing?
[19:29] <faLUCE> damdai: what do you mean with "high latency" ?
[19:29] <damdai> well you said you like opus because it has low latency?
[19:30] <faLUCE> damdai: syncing issues have nothing to do with latency
[19:30] <damdai> then why is  high/low latency matter the most
[19:30] <damdai> then when is  high/low latency matter the most
[19:30] <faLUCE> damdai: for real time encoding/streaming
[19:31] <damdai> i see
[19:31] <faLUCE> for example, if you want to hear the encoded audio as soon as possible, without a delay
[19:31] <faLUCE> think about skype
[19:32] <damdai> so even if you have most powerful computer in the world,  if you use audio format with high latency, you would see delay    than somebody using  low latency audio format with non powerful computer?
[19:32] <faLUCE> damdai: more or less, yes
[19:33] <damdai> i see
[19:33] <faLUCE> a basic latency depends on the encoder specifications
[19:33] <faLUCE> encoding audio really doesn't require powerful/fast cpu
[19:34] <damdai> true, it's most video that is cpu intensive
[19:34] <damdai> these days at least
[19:34] <faLUCE> but even if it's cpu intensive, it has nothing to do with latency
[19:35] <damdai> faluce i see
[19:35] <damdai> so nothing beat opus in latency. at the moment?
[19:35] <faLUCE>  latency means how much data do you need before you produce the first encoded data
[19:36] <faLUCE> because encoders buffer input data before providing encoded data
[19:40] <damdai> skype had such superior quality against others  when skype first appeared
[19:41] <damdai> not sure about latency though
[19:44] <faLUCE> have to go to sleep
[19:44] <faLUCE> good night!