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

[burek]

[00:31:05 CET] <SortaCore> I'm completely bricked from using my project because of this atomic bug
[00:31:52 CET] <nevcairiel> dont use git master if you cant deal with occasional breakage =p
[00:34:57 CET] <SortaCore> I expected quality control, and I am just feeling sooooo victimised here!
[00:35:58 CET] <SortaCore> more to the point, if it breaks my project, it could potentially break a lot of projects
[00:36:02 CET] <JEEB> report the issue on the trac and/or on the -devel ML if you know at least some specifics
[00:36:21 CET] <Compn> SortaCore : not many projects use git master ffmpeg
[00:36:23 CET] <SortaCore> I figured atom made the changes so he could investigate easier than anyone else
[00:36:45 CET] <JEEB> yea, if he comes around.
[00:37:08 CET] <Compn> SortaCore : just git pull back a few revisions and stick with that
[00:37:20 CET] <Compn> no use in complaining about what is broke (sorry) :)
[00:37:22 CET] <nevcairiel> the issue is being discussed on the ML already
[00:37:25 CET] <JEEB> well yes, that is the short time workaround
[00:37:28 CET] <JEEB> nevcairiel: ah
[00:37:30 CET] <JEEB> good then
[00:37:47 CET] <Compn> and yes, no one is supposed to break git master, but it does happen
[00:37:59 CET] <JEEB> yea, the main part is to try and start flagging breakages
[00:38:11 CET] <Compn> rarely i would say
[00:38:11 CET] <Compn> monthly ?
[00:38:13 CET] <JEEB> because if no-one knows it's never going to be fixed
[00:38:27 CET] <nevcairiel> especially on some compilers that only few people use on a daily basis
[00:38:32 CET] <Compn> SortaCore : remember we are all volunteer army here :)
[00:39:02 CET] <Compn> did anyone ever reply to the amd guy about moving nvidia headers to a new repo ?
[00:39:59 CET] <JEEB> Compn: lately breakages have been the addition of windows.h to a lot of stuff, the HEVC NEON SIMD breaking clang on 32bit ARM and seemingly also gcc with aarch64?
[00:40:07 CET] <SortaCore> volunteers huh
[00:40:19 CET] <SortaCore> I could accidentally slip some money to a random paypal address
[00:40:36 CET] <JEEB> the windows.h stuff quickly got stuff on the ML as far as I can see, but not sure if that got fixed
[00:40:53 CET] <JEEB> the NEON thing I tried to bring up on the ML, but seems like not many cared
[00:41:21 CET] <nevcairiel> not yet, but hopefully soon
[00:42:48 CET] <JEEB> rcombs: have you hit this one btw? https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221518.html
[00:42:57 CET] <JEEB> I remember you poking android
[00:43:15 CET] <JEEB> and/or if it just happened to be something that would get fixed with R16
[00:43:32 CET] <rcombs> my fork's a bit behind right now, but I haven't seen that so far
[00:44:17 CET] <vicky_> ==============
[00:44:18 CET] <vicky_> File : /home/ppxyz/public_html/clip/files/thumbs/2017/12/07/1512668598dc0ae-768x432-1.jpg  ====== End : Thumbs Generation =======    Conversion Completed --------------------   Time Took : 1.4912 seconds   conversion_status : failed 
[00:44:20 CET] <vicky_> =================
[00:44:21 CET] <nevcairiel> did you try asking wbs about that?
[00:44:26 CET] <vicky_> How we can fix this issue?
[00:44:39 CET] <JEEB> nevcairiel: I guess I'll build what he cares about (libav) and see if it's broken there
[00:45:07 CET] <jdarnley> What issue?  I see no error message.
[00:45:24 CET] <vicky_> conversion_status : failed
[00:45:27 CET] <nevcairiel> he is a reasonable guy, he might be able to help no matter what =p
[00:45:33 CET] <nevcairiel> finding out which commit caused it might help
[00:45:47 CET] <rcombs> so, does anyone have any input on this thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221880.html
[00:45:48 CET] <JEEB> it was one of the semi-recent merges, that much I remember
[00:45:52 CET] <vicky_> I'm getting this error "conversion_status : failed" only
[00:45:54 CET] <Compn> vicky_ : ask in #ffmpeg , not here
[00:46:16 CET] <vicky_> ok, tx
[00:46:18 CET] <JEEB> I don't think that's on-topic even for #ffmpeg
[00:46:18 CET] <rcombs> tl;dr I'm trying to deal with users who get corrupted data back from their tuners
[00:46:30 CET] <Compn> JEEB : shhhhhhhh
[00:46:36 CET] <JEEB> since it's not FFmpeg itself
[00:46:47 CET] <tmm1> rcombs: two options sound reasonable
[00:46:55 CET] <JEEB> rcombs: that makes total sense and I guess the third timestamp @ upipe is for that
[00:47:22 CET] <rcombs> upipe?
[00:47:40 CET] <JEEB> the live/MPEG-TS centric multimedia framework
[00:47:43 CET] <JEEB> they have three timestamps IIRC
[00:47:56 CET] <nevcairiel> rcombs: i always wondered about the error bit, i mean if its just corrupt data, is there any guarantee that the flag is set and not just the data corrupted?
[00:48:16 CET] <JEEB> one for coded timestamp, another for "fixed to be actually usable" timestamp and then the receipt timestamp
[00:48:29 CET] <rcombs> nevcairiel: that bit is supposedly set _by the tuner_
[00:48:32 CET] <JEEB> if I recall correctly
[00:48:33 CET] <rcombs> rather than coming in OTA
[00:48:52 CET] <nevcairiel> so the tuner knows stuff is broke?
[00:48:55 CET] <rcombs> specifically, it's supposed to be set if applying FEC resulted in uncorrectable errors
[00:49:19 CET] <rcombs> i.e. there were more than N bitflips
[00:49:23 CET] <rcombs> JEEB: ah
[00:50:30 CET] <tmm1> what was the behavior when one of those was encoutered before the patch?
[00:50:52 CET] <rcombs> you'd just get a corrupted packet, and the timestamp may have had bitflips
[00:51:11 CET] <tmm1> i see, so the ts could be totally incorrect and would affect playback etc
[00:51:18 CET] <rcombs> timestamp bitflips are about the worst thing that can happen in a lavf/ffmpeg pipeline
[00:51:43 CET] <rcombs> so, let's say one timestamp comes in that's ridiculously high
[00:51:58 CET] <rcombs> ffmpeg.c will see that as the "last known timestamp"
[00:52:07 CET] <rcombs> and then correct _all future timestamps to be monotonically increasing from there_
[00:52:14 CET] <tmm1> oh yea, ick
[00:52:26 CET] <rcombs> so your output has a giant discontinuity, followed by every timestamp increasing by 1
[00:52:32 CET] <JEEB> yup
[00:52:55 CET] <rcombs> also, I'm taking input from a tuner and writing output using segment.c
[00:53:11 CET] <rcombs> so the segment.c output manifest would have that segment as absurdly long
[00:53:32 CET] <tmm1> nasty
[00:53:41 CET] <rcombs> I used to make the mistake of feeding that data back into another lavf as HLS
[00:53:57 CET] <rcombs> turns out if hls.c encounters a timestamp of 12 hours, it& waits 12 hours before refreshing the manifest
[00:54:14 CET] <JEEB> ayup
[00:54:39 CET] <rcombs> which is stupid in itself; I need to patch that to use FFMAX(last_seg_duration, target_duration)
[00:54:45 CET] <SortaCore> why does hwcontext_qsv.c have a bunch of serious-looking error message with "verbose" level instead of error?
[00:55:21 CET] <JEEB> ok, so libav isn't affected with the HEVC NEON stuff (´4@)
[00:55:52 CET] <tmm1> wow i finally figured out this yadif + hlsenc timestamp issue
[00:55:54 CET] <JEEB> might try to check which merge it was
[00:56:00 CET] <JEEB> but not tonight
[00:56:29 CET] <SortaCore> tonight he parties
[00:57:09 CET] <JEEB> no, I just used up my time with another project putting acceptable PRs in :P
[00:57:37 CET] <JEEB> LOL
[00:57:51 CET] <JEEB> on the ML I find a patch from eleks.com for seemingly to fix the build error
[00:58:37 CET] <tmm1> link?
[00:59:14 CET] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221881.html
[00:59:25 CET] <JEEB> (I like the bog-standard e-mail footer)
[00:59:46 CET] <tmm1> oh i think i saw that earlier and didn't boether clicking through
[01:00:02 CET] <tmm1> is there an easy way to map ffmpeg-devel message url to the patchwork url?
[01:00:24 CET] <JEEB> in this case the patch is an attachment so it's linked there
[01:00:46 CET] <JEEB> so you can get the patch from pipermail
[01:01:02 CET] <tmm1> yea but my browser tries to download it and then i have to go view it on disk
[01:01:21 CET] <JEEB> "Fixed by added "ltorg" directive after the function end, allowing compiler to allocate the local storage just after the function code if neccessary."
[01:01:36 CET] <JEEB> tmm1: I got recommended an extension for that by wm4
[01:01:50 CET] <JEEB> https://github.com/Rob--W/open-in-browser
[01:02:05 CET] <tmm1> cool
[01:02:22 CET] <tmm1> huh i just clicked it and it showed as text in the browser this time
[01:02:32 CET] <JEEB> vOV
[01:02:46 CET] <tmm1> looks like an easy enough fix
[01:02:52 CET] <JEEB> yup
[01:10:34 CET] <jamrial> JEEB: did you see vlc's commit d14c813b19?
[01:10:50 CET] <JEEB> not yet
[01:11:10 CET] <jamrial> it fixes something related to hevc in arm in ffmpeg
[01:11:30 CET] <jamrial> no idea what neon failure you're talking about above, but maybe it's related?
[01:15:35 CET] <tmm1> phew, two days of head-scratching for a 20 byte patch
[01:32:21 CET] <Chloe> turing codec is back
[01:33:02 CET] <Chloe> meanwhile, literally none of the issues blocking it previously have been resolved
[01:34:47 CET] <JEEB> tmm1: yea I kind of guessed that it might actually solve it after seeing it the first time :D
[01:37:19 CET] <tmm1> JEEB: hah!
[01:37:58 CET] <tmm1> i'll send you an invoice for my gray hairs
[01:40:48 CET] <JEEB> that was after I linked it to you, that is
[01:40:57 CET] <JEEB> and I didn't test it :D
[01:41:00 CET] <JEEB> but glad it does work
[01:41:24 CET] <JEEB> and yea, I wish I knew enough NEON to catch that one myself :P
[01:41:51 CET] <JEEB> looking at the patch and explanation it was just one of those "d'oh" moments where I bet it would fix it if it was this simple
[02:12:16 CET] <atomnuker> daddesio: nope, doesn't fix the errors
[02:13:08 CET] <atomnuker> SortaCore: I don't know what weird system you're compiling on but the logic's solid
[02:19:14 CET] <SortaCore> Windows mingw64
[02:19:37 CET] <SortaCore> static library used in 32-bit
[02:38:09 CET] <daddesio> atomnuker: it does on my end. I'll submit my patch on the ML.
[02:39:24 CET] <atomnuker> +            int offset = (8 << f->size) * ff_celt_freq_bands[i];
[02:39:26 CET] <atomnuker> +            int count = (8 << f->size) * (ff_celt_freq_range[i] - ff_celt_freq_range[i-1]);
[02:39:39 CET] <atomnuker> is your patch basically this?
[02:47:17 CET] <atomnuker> daddesio: could you reduce the diff from libopus by allocating 1 band's worth of coeffs?
[02:47:31 CET] <atomnuker> maybe it'll speed it up even
[04:23:40 CET] <SortaCore> atomnuker: it's because you use _Bool for exp, and on non-gcc atomic_bool is defined to intptr_t
[04:25:03 CET] <SortaCore> there's also no initialising for ff_avcodec_locked, like there is for entangled_thread_counter, that may be a factor too
[04:27:10 CET] <wm4> I didn't really follow this atomic stuff, but the compat wrapper defines atomic_bool to intptr_t because there's no other way to support the "generic" atomic_ macros
[04:27:17 CET] <wm4> which in real C11 are compiler magic
[04:27:54 CET] <SortaCore> well, I replaced that and it works
[04:29:41 CET] <daddesio> atomnuker: int offset = ff_celt_freq_bands[i] << f->size and int count = (ff_celt_freq_range[i] - ff_celt_freq_range[i-1]) << f->size.
[04:29:51 CET] <daddesio> In fact, then offset = band_offset :P
[04:30:39 CET] <daddesio> I could rewrite the function to always use 8x indexing, but there's no real need
[04:30:51 CET] <daddesio> I don't see how one way is faster than the other.
[04:32:48 CET] <atomnuker> you save having to copy an entire stack's worth of coefficients?
[04:33:09 CET] <daddesio> then isn't our way faster? since we're using the minimal indexing possible
[04:33:21 CET] <atomnuker> no, indexing is cheap
[04:33:22 CET] <daddesio> e.g. 4x indexing when f->size = 2.
[04:33:52 CET] <daddesio> actually, where does that copy take place, that you're referring to?
[04:33:52 CET] <atomnuker> and indexing is basically free on x86
[04:34:09 CET] <daddesio> my memcpy?
[04:35:08 CET] <atomnuker> that and the is/ds switch
[04:37:07 CET] <daddesio> well our Special Hybrid Folding memcpy will be faster than libopus (once we correct the patch to << f->size instead of * 8), since our version of norm[] uses tighter indexing.
[04:37:40 CET] <daddesio> libopus always multiply by 8. we do a shift by 0, 1, 2, or 3.
[04:37:46 CET] <daddesio> multiplies*
[04:39:56 CET] <daddesio> if libopus wanted it to do it faster, they could have done a for loop with a stride of 8 >> f->size.
[04:42:25 CET] <atomnuker> ok, this works, I'll run fate to make sure the tests pass without deviation and push it
[04:43:33 CET] <daddesio> Yeah, don't forget, you can get rid of the "int offset" variable and replace it with band_offset.
[05:15:11 CET] <SortaCore> can anyone confirm switching the variable type inside the lock/unlock fixes it?
[05:15:47 CET] <wm4> can you paste a diff?
[05:16:12 CET] <wm4> (you probably posted it on the ML, but I'm not following this discussion closely)
[05:16:19 CET] <wm4> just getting curious why it's such a problem
[05:17:57 CET] <SortaCore> it does "atomic var == expected var" check with an atomic function
[05:18:06 CET] <SortaCore> and it fails, because expected var type doesn't match atomic var type
[05:18:56 CET] <wm4> which atomic function?
[05:19:26 CET] <SortaCore> atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 1)
[05:19:48 CET] <SortaCore> I would post a diff but my version is packed with av_log stuff to see how it broke
[05:20:19 CET] <jamrial> ff_avcodec_locked is _Atomic _Bool and exp is _Bool, so they are the same type
[05:20:45 CET] <SortaCore> nah, atomic_bool is intptr_t
[05:20:58 CET] <SortaCore> ...well, I'd check at runtime, if there was a way to do that
[05:21:03 CET] <jamrial> are you using msvc?
[05:21:09 CET] <SortaCore> just replace the _Bool variable with atomic_bool, around line 1953 and the exchange works as expected
[05:21:12 CET] <wm4> jamrial: those are not the same type
[05:21:13 CET] <SortaCore> otherwise assert fails
[05:21:21 CET] <SortaCore> yea, msvc
[05:21:36 CET] <SortaCore> although, only gcc has atomic_bool typedef'd to _Bool, the rest have it to intptr_t
[05:22:18 CET] <wm4> static inline int atomic_compare_exchange_strong(intptr_t *object, intptr_t *expected,
[05:22:18 CET] <wm4>                                                  intptr_t desired)
[05:22:22 CET] <wm4> oh yeah, this is horseshit
[05:22:28 CET] <SortaCore> it's a problem because when you go to open a codec, any codec, the lock fails, so you can't use it
[05:22:39 CET] <wm4> it's directly in conflict what stdatomic requires
[05:22:44 CET] <jamrial> all the wrappers except the one for old gcc are kinda hacky, yeah
[05:22:55 CET] <wm4> in particular this " intptr_t *expected"
[05:23:10 CET] <wm4> this just can't work, it's simply the wrong pointer type
[05:23:28 CET] <wm4> SortaCore: so congratulations, you found a design bug
[05:23:37 CET] <SortaCore> yay, what do I win
[05:23:38 CET] <jamrial> nah, it's been found before
[05:23:46 CET] <jamrial> there's a patch in the ml for the msvc case
[05:23:52 CET] <jamrial> doing what he suggested
[05:23:54 CET] <SortaCore> @.@
[05:24:14 CET] <SortaCore> when was the patch posted?
[05:24:14 CET] <wm4> since the actual pointer is never passed to some other functions and just dereferenced in the inline fn, it could be made a macro
[05:24:15 CET] <jamrial> it's still, well, hacky
[05:24:32 CET] <SortaCore> this only turned up since atom's commits like max two weeks ago
[05:24:52 CET] <wm4> in mpv we also have a stdatomic emulation, but it requires a gnu extension now
[05:25:12 CET] <wm4> what was the patch to fix this?
[05:25:50 CET] <jamrial> "fix MSVC compilation errors" by Mateusz
[05:26:07 CET] <SortaCore> there wasn't a compilation error, though
[05:26:15 CET] <SortaCore> it was just at runtime the problem turned up
[05:27:07 CET] <SortaCore> [01:13] <@atomnuker> SortaCore: I don't know what weird system you're compiling on but the logic's solid
[05:27:21 CET] <SortaCore> <.<
[05:27:25 CET] <jamrial> it is
[05:27:32 CET] <jamrial> the wrapper just isn't correct
[05:27:40 CET] <SortaCore> solid as pumice rock
[05:28:18 CET] <jamrial> nope
[05:28:18 CET] <wm4>     av_assert0(atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 0));
[05:28:23 CET] <wm4> man what the fuck is this
[05:28:46 CET] <wm4> is this the thing that breaks it?
[05:29:11 CET] <jamrial> nevcairiel argues it could maybe not even use atomics at all
[05:29:29 CET] <wm4> the proposed fix (is there even a patch or is it just informally copied into the mail) is wrong too
[05:29:40 CET] <SortaCore> yes, the exp above is wrong type
[05:29:41 CET] <wm4> the stdatomic function expects bool*, not _Atomic bool*
[05:29:59 CET] <wm4> and the emulation wrapper expects intptr_t*, which is also wrong
[05:30:18 CET] <SortaCore> although msvc seems happy to use _Bool as a variable type, intptr_t is what I'm guessing it's using instead
[05:30:27 CET] <wm4> so the existing code is correct (just ridiculously absurd and dumb, wtf is with that assert), and the emulation wrapper is wrong
[05:30:36 CET] <jamrial> wm4: that code was added in 590136e78d
[05:30:43 CET] <wm4> I suggest turning the emulation atomic_compare_exchange_strong into a macro
[05:30:47 CET] <SortaCore> also, above that where ff_avcodec_locked is declared, it's not intiialised
[05:30:59 CET] <SortaCore> not sure if that's important
[05:31:55 CET] <jamrial> the wrapper for old gcc uses a macro and __typeof__ magic, but i suppose that can't be done for msvc
[05:33:18 CET] <wm4> that's probably challenging
[05:33:28 CET] <SortaCore> wm4: doesn't that break the "put stack variables first" rule
[05:34:06 CET] <wm4> the new code is the only thing that uses these functions
[05:40:39 CET] <SortaCore> I'm gonna get to bed, y'all have a good one
[05:42:50 CET] <cone-915> ffmpeg 03Rostislav Pehlivanov 07master:c67c7191b1c2: fate-opus: run and test inactive samples
[05:42:50 CET] <cone-915> ffmpeg 03Rostislav Pehlivanov 07master:4678339e745d: opus: fix hybrid folding indexing during band quantization
[08:15:08 CET] <liyou>  i want to link static-ffmpeg into so file, how can i do it?
[08:23:59 CET] <atomnuker> daddesio: any progress on replacing the silk lpc?
[10:35:49 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:561e276899bb: ffserver: Fix off by 1 error in path
[10:35:50 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:7ff156b11285: tests/ffserver.regression.ref: update checksums to what ffserver currently produces
[10:35:51 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:1c931d5ab99a: avcodec/jpeglsdec: Check ilv for being a supported value
[10:35:52 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:7a23220bf947: avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line()
[10:35:53 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:b3bdb0ddc15b: avcodec/aacdec_fixed: Fix integer overflow in predict()
[10:35:54 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:dccead84c658: avcodec/aacdec_fixed: Fix integer overflow in apply_dependent_coupling_fixed()
[10:35:55 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:6be60aedcb76: avcodec/xan: Improve overlapping check
[10:35:56 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:66e65e0a686a: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add()
[10:35:57 CET] <cone-365> ffmpeg 03Luca Barbato 07release/3.4:78b8aeee585b: avformat: Free the internal codec context at the end
[10:35:58 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:0ee2cb866c02: avcodec/exr: fix undefined shift in pxr24_uncompress()
[10:35:59 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3ca4f1868d66: avcodec/xan: Check for bitstream end in xan_huffman_decode()
[10:36:00 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:56ce961cc3dd: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add()
[10:36:01 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3f2be02b4d77: avutil/softfloat: Add FLOAT_MIN
[10:36:02 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:8ec1ff14fe88: avcodec/aacsbr_fixed: Fix division by zero in sbr_gain_calc()
[10:36:03 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:87f39642f329: avcodec/sbrdsp_fixed: Fix integer overflow in shift in sbr_hf_g_filt_c()
[10:36:04 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:ed87b8b61fcd: avcodec/cngdec: Fix integer clipping
[10:36:05 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3a143bfa19a3: avcodec/snowdec: Fix integer overflow in header parsing
[10:36:06 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:168ee582559d: avcodec/mdct_*: Fix integer overflow in addition in RESCALE()
[10:36:07 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:db82e4f1e059: avcodec/aacdec_fixed: Fix undefined shift
[10:36:08 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:44fb1201123e: avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c()
[10:36:09 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:6ccf19198b36: avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu
[10:36:10 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:d25736dc871b: avcodec/h264dec: Fix potential array overread
[10:36:11 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:7b16eacf81dc: avcodec/vc2enc: Clear coef_buf on allocation
[10:36:12 CET] <cone-365> ffmpeg 03Fredrik Hubinette 07release/3.4:53715eb13ee1: avformat/mov: Check size of STSC allocation
[10:36:13 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:77cfc820cfb5: avcodec/snowdec: Check intra block dc differences.
[10:36:14 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:23d5f15b42fd: avcodec/snowdec: Check for remaining bitstream in decode_blocks()
[10:36:15 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:ecf2755a41b4: avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb()
[10:36:16 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:0ba93614cf22: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0()
[10:36:17 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:cc9d1bb83922: avcodec/zmbv: Check that the buffer is large enough for mvec
[10:36:18 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:4942de6f9385: avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output()
[10:36:19 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:2e58db3db00b: avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v()
[10:36:20 CET] <cone-365> ffmpeg 03Jacob Trimble 07release/3.4:8aabc4fdb56c: avformat/mov: Propagate errors in mov_switch_root.
[10:36:21 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:9a00ce0ff864: Fix leak of frame_duration_buffer in mov_fix_index().
[10:36:22 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:50c93ce5ef71: Use ff_thread_once for fixed, float table init.
[10:36:23 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:f8fcb6bbf0e6: Fix undefined shift on assumed 8-bit input.
[10:36:24 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:35c7a1df8ae5: Close ogg stream upon error when using AV_EF_EXPLODE.
[10:36:25 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:154989003586: avcodec/mpeg4videodec: Check also for negative versions in the validity check
[10:36:26 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:de20dad15e42: avcodec/sbrdsp_fixed: Fix integer overflow
[10:36:27 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:f2f0273588ed: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*
[10:36:28 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3ae71b648ad0: avformat/aacdec: Fix leak in adts_aac_read_packet()
[10:36:29 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:e56f691283f0: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression
[10:36:30 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:983d119c9b73: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add
[10:36:31 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:ed87667bd3d4: avcodec/mlpdsp: Fix signed integer overflow, 2nd try
[10:36:32 CET] <cone-365> ffmpeg 03John Stebbins 07release/3.4:f7357facd833: lavf/mov: fix huge alloc in mov_read_ctts
[10:36:33 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:0ccbbf034dc0: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h()
[10:36:34 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:17f05ff656ff: avcodec/j2kenc: Fix out of array access in encode_cblk()
[10:36:35 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:36db62ca984b: avformat/utils: Prevent undefined shift with wrap_bits > 64.
[10:36:36 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:23319f77645d: avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead.
[10:36:37 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:c147aefc3ecd: avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u.
[10:36:38 CET] <cone-365> ffmpeg 03Nikolas Bowe 07release/3.4:a749f4864e48: avcodec/extract_extradata_bsf: Fix leak discovered via fuzzing
[10:36:39 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3a6140e4cf89: avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97*
[10:36:40 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:b2169c8bcc43: avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED()
[10:36:41 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:c741095eecee: Update for 3.4.1
[10:50:20 CET] <durandal_1707> now mjpeg fate passes after yuvj removal
[10:50:37 CET] <durandal_1707> \o/
[10:52:51 CET] <wm4> are these formats really dying?
[10:53:00 CET] <wm4> don't forget to deprecate-deprecate them
[10:53:20 CET] <wm4> they were deprecated for years, but everyone had to use them, so it can't be justified to remove them immediately
[10:53:31 CET] <atomnuker> yeah they can
[10:58:01 CET] <durandal_1707> wm4: they are not removed from lavu, just from lavc codebase
[10:59:15 CET] <nevcairiel> so how do I know now that mjpegenc wants a fullrange image? Previously it used to tell me this through .pix_fmts
[11:00:06 CET] <wm4> even more, mjpegenc failed to init if you didn't give it a J format
[11:00:11 CET] <wm4> and now it's the reverse?
[11:02:18 CET] <durandal_1707> you set color_range option
[11:03:02 CET] <wm4> but you don't know what the encoder wants
[11:03:11 CET] <wm4> or is there now an AVCodec.color_ranges[]
[11:03:28 CET] <durandal_1707> patch welcome
[11:03:45 CET] <nevcairiel> you want to replace yuvj formats, you need to provide replacements for their functionality
[11:04:13 CET] <wm4> yes, so it's not "patch welcome" but "patch rejected"
[11:04:44 CET] <wm4> to be fair last time we tried to do this, it failed because of libavfilter
[11:07:32 CET] <durandal_1707> wm4: i fixed lavfi and ffmpeg, look at the patch and review it, dont  be lazy
[11:10:34 CET] <wm4> that's only for vf_scale
[11:12:41 CET] <durandal_1707> no, its not
[11:17:58 CET] <wm4> weren't there filters which require full or half range
[11:18:01 CET] <wm4> ubitux should know
[11:23:29 CET] <ubitux> wm4: we don't have a filter that convert from one to another? :p
[11:24:30 CET] <ubitux> vf_kerndeint.c:                            // y <- 235, u <- 128, y <- 235, v <- 128
[11:24:35 CET] <ubitux> vf_lut.c:        max[Y] = 235 * (1 << (desc->comp[0].depth - 8));
[11:24:41 CET] <ubitux> vf_pseudocolor.c:    s->var_values[VAR_YMAX] = 235 * (1 << (depth - 8));
[11:24:51 CET] <ubitux> a few matches for "235"
[11:25:01 CET] <ubitux> probably related one way or another to mpeg range
[11:32:06 CET] <durandal_1707> ubitux: scale and zscale
[11:32:46 CET] <durandal_1707> lut works with both
[11:32:54 CET] <ubitux> so they have to query these specific formats in inlink and outlink i guess
[11:33:20 CET] <durandal_1707> and checking color range in inlink is easy
[11:33:58 CET] <durandal_1707> i just concentrated on lavc side of things
[12:15:04 CET] <durandal_1707> added color range to mjpeg encoders
[12:25:33 CET] <wm4> probably could argue that you should keep yuvj support in the encoder for now (and print a warning if it's used)
[12:33:30 CET] <cone-365> ffmpeg 03Paul B Mahol 07master:299a62229766: avfilter/vf_waveform: add default case when picking input formats
[12:34:53 CET] <durandal_1707> wm4: no
[12:50:57 CET] <atomnuker> this is going to be a huge bump anyway
[12:51:28 CET] <atomnuker> with ffserver being dropped, loads of deprecated stuff being removed, new hwaccel code to handle things for you...
[12:51:40 CET] <nevcairiel> thats no excuse to break all the things w hen it would be trivial to keep it working
[12:52:41 CET] <atomnuker> that's pretty much the point of a bump
[12:52:48 CET] <atomnuker> and the removal of deprecated things
[16:10:03 CET] <cone-365> ffmpeg 03Paul B Mahol 07master:a41a5db79766: avformat: add NSP demuxer
[16:12:12 CET] <cone-365> ffmpeg 03Vittorio Giovara 07master:bc38c8f44249: vf_zscale: Fix alpha destination graph for floating point pixel formats
[16:47:46 CET] <daddesio> atomnuker: i'm not going to replace the LTP synthesis or LPC synthesis for loops, since they both clamp y[] to +/- 1.0f. since they're IIR filters, I'm hesitant to just remove that clamping.
[16:49:01 CET] <daddesio> erm, actually only the LPC filter does the clamping.
[16:49:30 CET] <daddesio> but there is no "LTP synthesis" function in libavcodec/libavutil. remember, LTP is technically a huge-ass filter with hundreds of zero coeffs in the middle of a[].
[16:55:57 CET] <daddesio> actually, it looks like libopus doesn't do that clamping. https://github.com/xiph/opus/blob/master/silk/PLC.c#L342
[17:05:41 CET] <daddesio> wait, that's the packet-loss concealment code
[17:23:11 CET] <daddesio> the actual LPC code is here. and again, it does not do clamping: https://github.com/xiph/opus/blob/master/silk/decode_core.c#L198
[17:26:56 CET] <atomnuker> so it can replace the non-clamping lpcs?
[17:28:29 CET] <daddesio> it seems SILK does LPC with fixed-point arithmetic with no clamping, while FFmpeg does LPC with floating-point arithmetic with clamping to +/- 1.0.
[17:30:07 CET] <daddesio> SILK does it with Q14 integers (2 integer bits, 14 fractional bits) which means it works with numbers in the range [-2.0, 2.0).
[17:30:47 CET] <daddesio> I don't see any saturating macros in SILK's code
[17:32:06 CET] <daddesio> Aha
[17:32:47 CET] <daddesio> RFC6716 says this:
[17:32:50 CET] <daddesio> "Then, the signal is clamped into the final nominal range: out[i] = clamp(-1.0, lpc[i], 1.0)
[17:32:52 CET] <daddesio> This clamping occurs entirely after the LPC synthesis filter has run. The decoder saves the unclamped values, lpc[i], to feed into the LPC filter for the next subframe, but saves the clamped values, out[i], for rewhitening in voiced frames."
[17:33:43 CET] <daddesio> so we should be able to get rid of the clamp()s. the question is, do we want to convert it to fixed-point like SILK?
[17:36:33 CET] <durandal_1707> michaelni: does in your system hflip pixfmt test passes?
[17:37:56 CET] <michaelni> durandal_1707, all tests pass except the newly added
[17:47:54 CET] <daddesio> ... again, I'm an idiot. FFmpeg only clips the output (lpc[j] = sum; dst[j] = av_clipf(sum, -1.0f, 1.0f);.
[17:49:08 CET] <daddesio> So FFmpeg is doing the right thing. But now, that means we can replace the for loop with ff_celp_lp_synthesis_filterf which might be faster (since it's unrolled), but we'll still have to clamp the output afterwards.
[17:52:43 CET] <daddesio> erm, no, we can't use ff_celp_lp_synthesis_filterf because that uses the Direct-Form coefficients a[i] = -lpc[i] (so the for loop uses a subtraction instead of an addition). we have to use ff_celp_lp_zero_synthesis_filterf--which has not been unrolled, as of yet.
[18:03:53 CET] <daddesio> meh. I say the existing code is fine.
[18:05:39 CET] <daddesio> to use ff_celp_lp_zero_synthesis_filterf, you'll have to create a tmp1[] array with the excitation signal premultiplied by sf[i].gain and a tmp2[] array to hold the output. then call the LPC filtering function. then copy it over to out[] (with clamping).
[18:09:44 CET] <cone-365> ffmpeg 03Jacob Trimble 07master:2fdc9f7c4939: avcodec/nvdec: Fix capability check with old drivers.
[18:25:25 CET] <durandal_1707> if yuvj changes are ok i will split patches in smaller chunks
[18:37:45 CET] <durandal_1707> we should move on, or dont ever mention yuvj shit to me again
[18:55:19 CET] <jamrial> if it works then sure
[20:03:22 CET] <cone-365> ffmpeg 03sfan5 07master:a428f2fcd959: libavcodec/hevc_filter: move AVDISCARD_NONREF switch-case into function
[20:03:23 CET] <cone-365> ffmpeg 03Mark Reid 07master:ad2641c36bf6: avformat/mxfenc: use track count to generate component instance uuid
[20:03:24 CET] <cone-365> ffmpeg 03Mark Reid 07master:901d87aa83aa: avformat/mxfenc: write reel_name if metadata key is present
[20:03:25 CET] <cone-365> ffmpeg 03Mark Reid 07master:0091a54f6487: fate/mxf: add reel name test
[20:03:26 CET] <cone-365> ffmpeg 03Michael Niedermayer 07master:b404d41b1962: fate: Fix fate-mov-bbi-elst-starts-b on ARM
[20:39:01 CET] <cone-365> ffmpeg 03Paul B Mahol 07master:713f9c5b5d64: avfilter/vf_scale: add more aliases for "range" options
[21:24:59 CET] <durandal_170> what about gl filter wrapper that can apply custom shaders?
[21:34:16 CET] <durandal_170> michaelni: thank you for your comments,  they are very helpfull
[21:42:33 CET] <Compn> gl filter wrapper eh
[21:42:38 CET] <durandal_170> obviously i tested only mjpeg so it can pass fate
[21:42:38 CET] <Compn> sounds complicated :)
[21:43:10 CET] <durandal_170> Compn: kill mplayer project when?
[21:43:44 CET] <JEEB> well, you at got to something passing o/
[21:44:22 CET] <Compn> durandal_170 : ehhhh still works for me playing the files i have :p
[21:45:16 CET] <durandal_170>  we must change ffmpeg in way that breaks mplayer in so many ways that devs give up developing it
[21:46:17 CET] <Compn> durandal_170 : quite a few ffmpeg and even vlc devs use mplayer :P
[21:47:51 CET] <durandal_170> its like mencoder, ignorant people use it
[21:54:06 CET] <Compn> ignorant youtube :)
[21:54:29 CET] <Compn> youtube keeping us afloat
[21:59:58 CET] <durandal_170> michaelni: perhaps nasm misinterprets asm somehow?
[22:00:36 CET] <gnafu> YouTube uses mencoder?
[22:04:08 CET] <durandal_170> it is secret
[22:04:14 CET] <Compn> for binary codec support gnafu
[22:04:28 CET] <jamrial> durandal_170, michaelni: https://pastebin.com/SK5NPxxv
[22:04:29 CET] <Compn> durandal_170 : so , your misson, get binary codec support in ffmpeg
[22:04:34 CET] <Compn> durandal_170 : that will kill mencoder finally
[22:04:50 CET] <Compn> durandal_170 : binary codec support , as long as you dont use mplayer code, will be accepted to ffmpeg :)
[22:05:01 CET] <durandal_170> Compn: never, fix your brain already
[22:05:11 CET] <jamrial> nasm 2.13 vs 2.10
[22:05:25 CET] <jamrial> no idea if that makes any difference
[22:05:34 CET] <Compn> durandal_170 : i'm serious though, binary codec support (only a few wine files in total) will kill mplayer 100%
[22:07:41 CET] <durandal_170> Compn: vfw must be abandoned,  same for dshow,  qt and similar incarnations
[22:09:48 CET] <gnafu> Compn: Oh, right.  I remember seeing that mentioned before (probably in here).  It's a shame there's any need for that at this point.
[22:09:56 CET] <Compn> durandal_170 : sure, when you RE every codec...
[22:10:00 CET] <Compn> bit exact too
[22:11:30 CET] <durandal_170> Compn: relevant ones are already reversed, remainder are already dead or not supported by mplayer conf
[22:16:24 CET] <durandal_170> and emulator code is far from stable or perfect
[22:23:33 CET] <thardin> use there a way to make the paletteuse filter use the literal palette in a file?
[22:25:49 CET] <durandal_170> thardin: what format of palette in file?
[22:26:10 CET] <thardin> I have two options actually: either grab the palette in an 8-bit BMP or use a JASC palette
[22:26:38 CET] <thardin> maybe I can trick gimp into generating a png with indexes 0..255 and apply the JASC palette to it..
[22:26:45 CET] <Compn> thardin : probably not since we would have to map each palette format and how to convert it ...
[22:26:56 CET] <durandal_170> thardin: and BMP is 16x16?
[22:27:10 CET] <thardin> no the bmp is any size. 40x96 in this case
[22:27:12 CET] <Compn> thardin : what are you trying to do ?
[22:27:28 CET] <thardin> I want a bunch of pngs to use the exact same paalette as a bmp file I have
[22:27:30 CET] <thardin> same indexes
[22:27:39 CET] <thardin> and also convert them to bmp of course
[22:27:57 CET] <Compn> i mean, why not use image magick to do the heavy lifting then just use ffmpeg later on ?
[22:28:22 CET] <thardin> that is also an option
[22:29:15 CET] <Compn> i'm not telling you how to do it, just saying i've seen people struggle for hours trying to get some weird setup working when you could just add another scriptable step and be done with it quickly
[22:30:01 CET] <thardin> in the worst case I'll do it by hand in gimp. but that can't be scripted
[22:30:32 CET] <thardin> or maybe you can? hmm
[22:30:50 CET] <durandal_170> thardin: i still do not understand what you need?
[22:31:15 CET] <Compn> i mean, why would you want to reuse a palette ? why are you dealing with palettes at all ?
[22:31:16 CET] <thardin> I want to convert a series of images to bmp, using a given palette
[22:31:24 CET] <thardin> the palette is fixed
[22:31:31 CET] <thardin> to a specific 8-bit platform
[22:31:40 CET] <Compn> palettes are for old image things that no one uses anymore
[22:31:46 CET] <Compn> :P
[22:31:54 CET] <thardin> exactly! :]
[22:32:11 CET] <durandal_170> and palette is custom image with different layouts?
[22:32:50 CET] <Compn> https://en.wikipedia.org/wiki/Palette_(computing)
[22:32:51 CET] <thardin> no I just have the palette in two formats. both as the colormap in a bmp and as a jasc palette
[22:33:12 CET] <Compn> durandal_170 : custom color palette, e.g. this image will only use these colors
[22:33:14 CET] <Compn> i think ?
[22:33:23 CET] <durandal_170> thardin: how that colormap looks like?
[22:33:57 CET] <durandal_170> Compn: dont think. act.
[22:34:03 CET] Action: Compn runs
[22:34:09 CET] <thardin> lol
[22:34:45 CET] <thardin> I'm converting graphics for atari 2600
[22:34:55 CET] <thardin> and want a little pipeline for it
[22:35:42 CET] <durandal_170> send link to bmp colormap
[22:36:51 CET] <thardin> http://härdin.se/40x96-boring.bmp
[22:38:13 CET] <durandal_170> is that some kind of lut?
[22:38:32 CET] <thardin> no, just the palette is in the palette
[22:38:53 CET] <thardin> the damn palette chunk in the bmp
[22:39:07 CET] <thardin> the pixels are irrelevant
[22:39:08 CET] <durandal_170> really strange format/layout
[22:39:39 CET] <thardin> let's see if convert -remap does what I want. I suspect not
[22:39:57 CET] <durandal_170> i guess you are left to code it by hand
[22:40:40 CET] <thardin> possibly
[22:40:44 CET] <durandal_170> thardin: so you saying that bmp is actually pal8 format?
[22:40:56 CET] <thardin> yes
[22:41:19 CET] <durandal_170> thardin: tried showpalette?
[22:41:39 CET] <durandal_170> does our bmp decoder supports pal8?
[22:42:16 CET] <thardin> zomg
[22:42:26 CET] <thardin> except it's the wrong size
[22:42:47 CET] <durandal_170> you can change that i think...
[22:43:12 CET] <thardin> nearest neighbour in gimp
[22:43:34 CET] <thardin> interesting that it doesn't use pal8 for showpalette output
[22:44:32 CET] <durandal_170> i mean showpalette filter supports 1x1 size for each item
[22:45:06 CET] <thardin> this works well enough. thanks! :]
[22:45:39 CET] <Compn> durandal_170 says vfw is outdated and then helps thardin with atari 2600 stuffs... ok
[22:45:43 CET] Action: Compn runs faster
[22:47:09 CET] <durandal_170> video for winblows = vfw
[22:47:42 CET] <durandal_170> *d
[22:50:12 CET] <thardin> of course it tosses the indexes around
[22:50:41 CET] <thardin> sorts them it seems. wonderful
[22:55:42 CET] <wbs> jamrial: JEEB: about the .ltorg patch for arm asm; if you diff the hevc_idct*.S between libav and ffmpeg, the only diffrence is one function at the start of the ffmpeg file; if you move that to the end of the file instead of having it at the start, the current .ltorg should line up fine, so that might result in less maintainance
[22:56:51 CET] <jamrial> wbs: ok, let me check
[22:57:30 CET] <wbs> JEEB: also, that issue shouldn't relate to aarch64 whatsoever; if there's an issue with aarch64 builds, it's something else
[22:58:15 CET] <BBB> durandal_170: THANK YOU!!!!!!!!!
[22:58:23 CET] <BBB> durandal_170: (for yuvj* removal)
[22:58:28 CET] <BBB> you are amazing
[22:58:34 CET] <JEEB> :)
[22:58:55 CET] <wbs> jamrial: that _might_ require a .ltorg before the added function though, but that should be more maintainable at least, to have the common code end up aligned in the same way
[22:59:15 CET] <durandal_170> BBB: now pay me $$$$ or give me your vp9 encoder
[22:59:21 CET] <BBB> lol
[22:59:24 CET] <BBB> ehm...
[22:59:27 CET] <BBB> hm...
[22:59:33 CET] <BBB> what country are you in again?
[23:00:10 CET] <durandal_170> im just kidding
[23:01:00 CET] <BBB> Im not
[23:01:03 CET] <BBB> what country are you in?
[23:01:23 CET] <durandal_170> and yuvj removal only started, need to check more things
[23:04:08 CET] <BBB> youre not answering my genuine question ;(
[23:04:17 CET] <jamrial> wbs: like this? https://pastebin.com/YE8vGCg9
[23:04:30 CET] <jamrial> includes the extra .ltorg
[23:05:01 CET] <jamrial> can't test so i'm doing this blindly :p
[23:05:49 CET] <wbs> jamrial: yep, that one should be the least extra maintainance going forward, and should fix the issue
[00:00:00 CET] --- Sat Dec  9 2017