[00:00:56 CET] <atomnuker> daddesio: I'm still doubting the decoder is correct, after that fiasco [00:01:20 CET] <atomnuker> can you check the opus decoder does the same the reference does, minus rounding error? [00:01:20 CET] <daddesio> are you talking about my RFC6716 patches? [00:01:23 CET] <atomnuker> yeah [00:01:34 CET] <daddesio> I think the Opus decoder was never RFC6716-compliant to begin with. [00:01:44 CET] <daddesio> sadly elenril has been away due to finals [00:02:16 CET] <daddesio> I only did the SILK decoding functions back in 2012; elenril picked up after me. [00:06:41 CET] <cone-349> ffmpeg 03Jun Zhao 07master:a31a48261164: lavc/vaapi_encode: give a debug message if attrs unsupported. [00:07:47 CET] <daddesio> here's what I got when I ran opus_compare on the avconv/ffmpeg output on Dec 07: [00:07:49 CET] <daddesio> 17:20 <daddesio> here is the script I ran: https://pastebin.mozilla.org/9074295 [00:07:51 CET] <daddesio> 17:21 <daddesio> and output: https://pastebin.mozilla.org/9074296 [00:08:18 CET] <daddesio> Basically it passes only 10 of the 12 test vectors--and even then, the calculated "Opus quality metric" is pretty low most of the time. [00:09:39 CET] <daddesio> When you open the decoded files in Audacity, it basically looks like there are random time-shifts in our output, compared to the libopus output. [00:09:48 CET] <daddesio> idk [00:09:58 CET] <atomnuker> I don't care about silk, just celt [00:10:16 CET] <daddesio> It nails the first test, which I think is SILK-only. [00:10:22 CET] <daddesio> er, CELT-only maybe [00:10:36 CET] <atomnuker> the output is 90%+ compliant, so same as reference (which is also not 100% compliant, lol) [00:10:56 CET] <daddesio> a lot of the outputs are like 17% or 6% [00:11:28 CET] <atomnuker> the error is probably due to the resampler [00:11:33 CET] <atomnuker> (ours is better) [00:11:36 CET] <daddesio> ah :p [00:11:58 CET] <daddesio> is it worth investigating? [00:13:36 CET] <atomnuker> dunno, when does the resampler run on celt? [00:13:41 CET] <atomnuker> always or only on hybrid mode [00:16:28 CET] <daddesio> looks like CELT supports NB to FB audio. [00:16:39 CET] <daddesio> https://tools.ietf.org/html/rfc6716#section-2 [00:22:14 CET] <atomnuker> that only adjusts the end band, not the samplerate, its always 48000hz in celt [00:47:59 CET] <daddesio> ah [00:48:22 CET] <daddesio> then in theory, only SILK should need resampling to 48kHz, before finally resampling to the user-requested sampling rate. [03:56:22 CET] <cone-421> ffmpeg 03Stefan Pöschel 07master:c94b09485811: configure: Fix case of static libmp3lame [04:10:42 CET] <wm4> durandal_1707: did you give up on the J pixfmt crap? [04:10:50 CET] <wm4> (that is, crap removal) [04:28:18 CET] <TimothyGu> I remember J pixfmt cleanup as one of the first patches I sent to FFmpeg... [04:33:21 CET] <wm4> well they're still here, and we're sort of trying to get rid of them [12:44:28 CET] <Chloe> why does av_bsf_next() use a pointer as a integer counter? [12:44:53 CET] <Chloe> void** instead of just int* [12:47:47 CET] <Chloe> atomnuker: were you planning on removing linked lists without changing the API? There still has to be some internal state unless you want to iterate all the items every single avcodec_next call, right? [12:48:10 CET] <atomnuker> yes, the API can't change [12:48:47 CET] <atomnuker> we can change how lists are done internally though [12:49:04 CET] <atomnuker> you're free to add an api to avoid having an internal state, we could deprecate the old one [12:49:46 CET] <Chloe> the reason bsf is able to do lists as arrays internally is because of the external api from what I can see [12:50:16 CET] <Chloe> it passes in the state every av_bsf_next() call [13:05:41 CET] <durandal_1707> what about filter that reports if input is vfr or cfr? [13:09:04 CET] <Chloe> are you looking for filter ideas? [13:09:56 CET] <durandal_1707> yes [13:12:51 CET] <Compn> durandal_1707 : filter idea https://trac.ffmpeg.org/ticket/2104 [13:13:35 CET] <durandal_1707> Compn: if you want to get sued? sure [13:14:05 CET] <Compn> durandal_1707 : this filter would be used far and wide, you would be a hero to these people [13:14:18 CET] <durandal_1707> and in jail [13:14:23 CET] <Compn> no jail [13:15:15 CET] <durandal_1707> docs that describes how to implement it is hidden very badly [13:15:16 CET] <atomnuker> I think the lgpl gets us out of jail (or having to move to china) [13:16:55 CET] <Compn> durandal_1707 : use scene detection from automatic commercial removing algorithms, then add contrasting colors in a short amount of time [13:17:43 CET] <Compn> durandal_1707 : or try just change the white flash to a black fade out [13:18:15 CET] <durandal_1707> but it is not what paper describe [13:19:13 CET] <Compn> if you just want to implement other work [13:19:18 CET] <Compn> then port avisynth filters :P [13:19:31 CET] <Compn> just the top10 popular ones [13:38:40 CET] <durandal_1707> so does it make sense to do such filter or not? i do not want to nicolas come around saying its no go [13:39:23 CET] <Chloe> durandal_1707: what about a shader filter? [13:40:40 CET] <atomnuker> no, I'm doing that one [13:42:35 CET] <durandal_1707> Chloe: are you against vfrdet filter? [13:43:11 CET] <Chloe> what's the point of it? [13:43:21 CET] <kierank> durandal_1707: how can you detect vfr [13:43:26 CET] <Chloe> what can you do if you know if it's vfr/cfr [13:43:29 CET] <kierank> you can have 100000 cfr frames and 1 vfr frame [13:43:48 CET] <kierank> also what is the duration of the last frame [13:46:07 CET] <durandal_1707> last frame is not used [13:48:03 CET] <durandal_1707> kierank: how one guess video is cfr/vfr by inspecting timestamps? [13:48:13 CET] <kierank> measure delta [13:48:18 CET] <kierank> if delta is constant then cfr [13:48:27 CET] <kierank> but obviously you have problems with 720p59.94 in mpegts and similar [13:48:29 CET] <kierank> because of 90khz [13:48:35 CET] <kierank> and ntsc in flv [13:49:49 CET] <durandal_1707> kierank: what delta do these cases have? [13:49:56 CET] <kierank> they jitter [13:50:01 CET] <kierank> because of lack of timestamp precision [13:50:08 CET] <kierank> can't remember the exact numbers [13:50:11 CET] <durandal_1707> by 1? [13:50:12 CET] <kierank> 1505/1506 or whatever [13:50:13 CET] <kierank> yes [14:05:57 CET] <cone-732> ffmpeg 03Paul B Mahol 07master:cfd52094c027: avfilter/vf_psnr: add more gbrap formats [17:54:58 CET] <wm4> Chloe: just subtract pointers to get an index [18:07:40 CET] <Chloe> wm4: I did think about that but I thought it was a dirty solution, if you think it's alright then I guess it's fine [18:11:52 CET] <wm4> it's the only solution that avoids mutable data [22:41:14 CET] <cone-732> ffmpeg 03sfan5 07master:05c1c79d3779: libavcodec/hevcdec: implement skip_frame [22:41:15 CET] <cone-732> ffmpeg 03Sasi Inguva 07master:58a25aeb8e69: lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header. [00:00:00 CET] --- Thu Dec 21 2017