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

[burek]

[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