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

[burek]

[00:30:29 CET] <atomnuker> jamrial: how the hell to replace avpriv_atomic_ptr_cas?
[00:30:58 CET] <jamrial> atomnuker: http://en.cppreference.com/w/c/atomic/atomic_compare_exchange
[00:31:09 CET] <atomnuker> no, that's not the problem
[00:31:24 CET] <atomnuker> its equal to atomic_compare_exchange(ptr, old, new); return old;
[00:31:39 CET] <atomnuker> the issue is that the function itself takes void *, void * and a void *
[00:31:59 CET] <atomnuker> but the atomic_compare_exchange_strong takes a const non-pointer for the new value (desired)
[00:32:52 CET] <atomnuker> the options are to either scrap the function and do the exchange manually which works in all but two cases (both in utils.c)
[00:33:10 CET] <atomnuker> or to I dunno, make a macro?
[00:33:25 CET] <jamrial> i think you can declare them as _Atomic type*
[00:34:25 CET] <jamrial> so for av_register_codec_parser() you can use static _Atomic AVCodecParser *av_first_parser or so 
[00:34:36 CET] <jamrial> not sure how the compat wrappers will handle that, though
[00:35:36 CET] <atomnuker> do we need the compat macros at all?
[00:35:49 CET] <atomnuker> my plan is to put the function in libavutil/internal.h
[00:36:07 CET] <atomnuker> and remove all files that mess with avpriv_atomic
[00:36:13 CET] <jamrial> no, i mean the compat/ folder wrappers for c11 atomics on compilers that don't support them
[00:36:25 CET] <atomnuker> oh, hm
[00:36:49 CET] <jamrial> i think they handle _Atomic attribute just fine, but nothing uses it in the code right now
[00:37:28 CET] <jamrial> ignore them for now and focus on writing valid c11 atomics code
[00:38:28 CET] <jamrial> also, not sure what function you want to put in lavu/internal.h
[00:39:00 CET] <jamrial> the idea here is to replace all the lavu avpriv_atomic_ functions with the c11 atomics that are compiler builtins
[00:40:20 CET] <jamrial> replace all their uses, i mean, so the functions can be safely removed
[00:40:31 CET] <atomnuker> I have 2 patches which remove all avpriv_atomic usage except for avpriv_atomic_ptr_cas
[00:41:10 CET] <atomnuker> and I think we should move avpriv_atomic_ptr_cas into internal.h
[00:43:22 CET] <atomnuker> ah, I see, so you want to avoid having that function altogether
[00:44:07 CET] <jamrial> atomnuker: also, as i said the other day, you could probably revert 133fbfc7811 and ec464c96831 to simplify some of the register functions if needed
[00:44:26 CET] <atomnuker> doesn't help really
[00:45:04 CET] <atomnuker> besides, wouldn't someone object if I did revert it?
[00:45:41 CET] <jamrial> those changes were to make the register functions slightly faster
[00:45:52 CET] <jamrial> registering codecs is far from anyone's bottleneck
[00:46:12 CET] <jamrial> so if said changes get in the way of porting them to c11 atomics, they can be reverted
[00:47:04 CET] <jamrial> especially when one of them is reported to be "slighty more complex" than necessary just to keep it ABI compatible back in 2013
[00:47:56 CET] <atomnuker> reverting 133fbfc7811 really doesn't help
[00:49:01 CET] <atomnuker> if I change the parser register function to have an _Atomic prefix I also have to change its definition in avcodec.h
[00:50:24 CET] <atomnuker> ec464c96831 wouldn't help either, that cas function is still used inside a loop
[00:50:37 CET] <atomnuker> seems I have no choice but to manually rewrite the loops
[00:54:25 CET] <jamrial> the _Atomic prefix would not be for the function, but the atomic variables
[00:55:21 CET] <jamrial> static variables like av_first_parser in parser.c, and first_avcodec in utils.c
[00:56:12 CET] <atomnuker> I've been looking at these register functions for some time now and I have _no_ idea how the operate
[00:56:38 CET] <atomnuker> bloody linked lists
[01:06:45 CET] <SortaCore> linked lists are so annoying
[01:07:10 CET] <atomnuker> michaelni: how would you implement ec464c96831ac in less lines like it says in the description?
[02:34:59 CET] <cone-187> ffmpeg 03Michael Niedermayer 07master:12a511f2c265: avcodec/sbrdsp_fixed: Fix integer overflow
[02:34:59 CET] <cone-187> ffmpeg 03Karthick J 07master:a1f8f1340acc: avformat/dashenc: Associate mpd extension with dash muxer
[02:34:59 CET] <cone-187> ffmpeg 03John Stebbins 07master:bdddcb7b030d: lavf/mov: fix crash in mov_read_sidx
[02:34:59 CET] <cone-187> ffmpeg 03Mikulas Patocka 07master:279d2599dd6b: ffmpeg libopusdec: fix missing include file in libopusdec.c
[02:58:09 CET] <atomnuker> jamrial: what's the difference between laxer and stricter atomics?
[03:05:18 CET] <jamrial> atomnuker: performance, mostly. it affects how non-atomic memory accesses behave around the atomic operation
[03:05:48 CET] <jamrial> don't ask me about specifics as it's far from my area of expertise :p
[03:06:10 CET] <jamrial> BBB might be able to
[03:25:18 CET] <atomnuker> with name like "strong" or "weak" I thought it would behave in a non-atomic manner in some conditions
[03:38:44 CET] <jamrial> ah, i was talking about the memory order parameter, not the weak/strong variants of atomic_compare_exchange
[03:38:57 CET] <jamrial> i have no idea what those do
[03:39:32 CET] <jamrial> the memory order is available when you use the _explicit variants
[03:39:53 CET] <jamrial> it's orthogonal to what you're trying to do anyway
[10:05:47 CET] <cone-893> ffmpeg 03Richard Ling 07master:7d4fe0c5cb95: avfilter: add normalize filter
[12:06:26 CET] <nevcairiel> atomnuker: weak can spuriously fail, its only good use that I know of is when you implement a tight loop with an atomic exit condition triggered externally, and a few more iterations due to lack of forced synchronization don't hurt, for a performance advantage (note: on x86 there is no difference, but on arm and ppc there might be)
[13:59:13 CET] <durandal_1707> ubitux: gonnna do this http://www.ipol.im/pub/art/2017/201/ ?
[15:19:27 CET] <ubitux> durandal_1707: nope, go for it
[15:19:42 CET] <ubitux> feel free to add modes to dctdnoiz if it makes sense btw
[15:38:43 CET] <kierank> durandal_1707: probably fixed in https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d2917501c252d999e5478c4b804e326ac77cf37b
[15:39:37 CET] <cone-893> ffmpeg 03Li, Zhong 07master:136e7cf64ce9: qsv/hevcdec: Load hw plugin by default on non-windows os
[15:39:39 CET] <cone-893> ffmpeg 03Mark Thompson 07master:b26dd5ae2fb9: Merge commit '136e7cf64ce9e78de7158d6720539d51cb96b743'
[16:12:01 CET] <jamrial> why was that closed as wont fix?
[16:12:57 CET] <jamrial> i mean the gopro one
[16:13:10 CET] <jamrial> and for that matter, that libvmaf as invalid as well...
[16:13:33 CET] <nevcairiel> the vmaf one probably because its a dupe
[16:13:40 CET] <jamrial> ah
[16:13:52 CET] <jamrial> wonder why carl didn't mention that, then
[16:16:02 CET] <cone-893> ffmpeg 03Mark Thompson 07master:e1d192442780: lavu/pixfmt: Remove gap in the middle of enum AVPixelFormat
[16:16:03 CET] <cone-893> ffmpeg 03Mark Thompson 07master:89216895757c: doc/APIchanges: Fix lavu versions for OpenCL changes
[16:21:13 CET] <jkqxz> nevcairiel:  Do you have any comment on <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219795.html>?
[16:22:08 CET] <nevcairiel> i still wonder why the entire function uses adapter2 in the first place, but thats unrelated =p
[16:22:53 CET] <nevcairiel> is %ls portable?
[16:23:48 CET] <JEEB> jkqxz: btw does this look alright for you? segfault that seemed to get fixed by this is linked in the next post https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220750.html ?
[16:24:53 CET] <jkqxz> nevcairiel:  With C99, yes.  I've no idea if it works in every crazy Windows setup, though :P
[16:25:31 CET] <nevcairiel> microsoft certainly doesnt document %ls, they use %S, and even claim that %S is ISO C
[16:26:57 CET] <jkqxz> Not in the copy I have.
[16:27:52 CET] <jkqxz> The Linux docs say "S      (Not in C99 or C11, but in SUSv2, SUSv3, and SUSv4.)  Synonym for ls.  Don't use."
[16:27:53 CET] <nevcairiel> "An ls, lS, ws or wS type specifier is synonymous with S in printf functions", there it is, they do mention it afterall =p
[16:29:32 CET] <jkqxz> JEEB:  Change is fine, I think.
[16:29:41 CET] <jkqxz> device_uninit being called twice is rather nasty, though.
[16:30:55 CET] <JEEB> well, the case is that you allocate the hwdevice, then you try init'ing it, and it fails. that calls uninit once. then you unref the buffer and it gets called again
[16:31:10 CET] <JEEB> https://github.com/mpv-player/mpv/blob/master/video/decode/d3d.c#L97..L113
[16:31:12 CET] <JEEB> basically
[16:31:26 CET] <jkqxz> It does makes sense in the hwcontext generic code.
[16:31:32 CET] <jkqxz> Yeah.
[16:32:28 CET] <jkqxz> Looking through other implementations, they all look safe except OpenCL.  Oops.
[16:32:43 CET] <nevcairiel> dxva2 probably has the same issue as d3d11
[16:33:10 CET] <jkqxz> It doesn't have a device_uninit function at all.
[16:33:38 CET] <nevcairiel> oh right, it shoves that in the free callback for r easons
[16:36:25 CET] <jkqxz> <http://sprunge.us/HRiA>
[16:44:04 CET] <cone-893> ffmpeg 03James Almer 07master:4af050c46e2a: configure: remove superfluous cuvid and nvdec checks
[17:08:44 CET] <cone-893> ffmpeg 03Mark Thompson 07master:8bbf2dacbfb4: hwcontext_d3d11: Log adapter details on device creation
[17:08:45 CET] <cone-893> ffmpeg 03Mark Thompson 07master:f4e319d8a946: hwcontext_opencl: Reset internal command queue on device_uninit
[17:11:59 CET] <cone-893> ffmpeg 03Mikulas Patocka 07master:fbdd78fa3e99: avcodec/fft: fix INTERL macro on 3dnow
[17:13:06 CET] <atomnuker> 3dnow?
[17:13:09 CET] <jamrial> 3dnow without sse means athlon thunderbird or older
[17:13:15 CET] <jamrial> i'm amazed such cpus still work today
[17:38:38 CET] <atomnuker> jamrial: do you know why "extern volatile int ff_avcodec_locked;" is exposed in internal.h?
[17:38:45 CET] <atomnuker> nothing else seems to be using it
[17:39:53 CET] <jamrial> atomnuker: not really. maybe it was meant to be used outside utils.c but didn't happen, and then it was left as is?
[17:40:32 CET] <atomnuker> removed it and replaced it with proper atomics
[17:49:27 CET] <jamrial> atomnuker: you still forgot the error_count initialization in ff_er_frame_start()
[17:49:42 CET] <jamrial> according to michaelni it should be safe to use atomic_init() there
[17:52:39 CET] <cone-893> ffmpeg 03Jan Ekström 07master:f6d49a0dc84a: hwcontext_d3d11va: properly reset values after release/close
[17:57:44 CET] <atomnuker> ah, bloody hell, I thought I checked them all
[18:41:16 CET] <Compn> approved a patch to the mailing list
[18:41:21 CET] <Compn> deleted some spam
[18:41:23 CET] <Compn> mod queue empty
[18:53:22 CET] <durandal_1707> Compn: good job!
[19:05:06 CET] <atomnuker> this month the ml has had the most traffic since january of last year (which had 2300 emails)
[19:25:11 CET] <durandal_1707> atomnuker: is that bad?
[19:35:10 CET] <atomnuker> no, its good, alot of nice patches this month from people who never posted before
[20:01:27 CET] <cone-893> ffmpeg 03Martin Vignali 07master:07e427aa5655: avcodec/texturedsp : add rgtc1u gray decoding
[20:01:28 CET] <cone-893> ffmpeg 03Martin Vignali 07master:21c06c4095f5: avcodec/hapdec : use gray8 for HapAlphaOnly decoding instead of RGB0
[20:01:29 CET] <cone-893> ffmpeg 03Martin Vignali 07master:8794e0c0372c: fate/hapAlphaOnly : add test for hap alpha only decoding
[21:16:50 CET] <SortaCore> what is QSV's RecoveryPointSEI?
[21:18:44 CET] <SortaCore> also, I figured out how to access RTSP's SOCKET
[21:18:51 CET] <SortaCore> socket = (SOCKET)*(*(*(((int ***)rtsp_format_context->priv_data) + 1) + 2) + 1);
[21:19:07 CET] <SortaCore> healthy code (thumbsup)
[21:24:27 CET] <omerjerk> how do I mark an encoder as experimental? 
[21:26:54 CET] <jkqxz> Put AV_CODEC_CAP_EXPERIMENTAL in AVCodec.capabilities.
[21:35:01 CET] <omerjerk> thanks.
[22:01:22 CET] <tmm1> SortaCore: thats an h264 sei
[22:28:26 CET] <SortaCore> which sei tho
[22:28:38 CET] <nevcairiel> the recovery point sei, obviously
[22:28:54 CET] <nevcairiel> there is one with that name =p
[22:29:08 CET] <SortaCore> I keep getting those unrecognised SEIs for 229
[22:29:25 CET] <SortaCore> apparently it's dodgy Chinese cameras
[22:29:37 CET] <SortaCore> (secretly giving the camera commands from Chinese government)
[22:31:59 CET] <JEEB> AVC didn't have a generic IRAP NAL units for open gop which is why I think that SEI was utilized to tell the client "from this point on you can play"
[22:32:49 CET] <SortaCore> is there a way to turn those off?
[22:33:25 CET] <JEEB> set your thingamajig to not use open gop? libavcodec should be able to handle those fine, though.
[22:34:11 CET] <SortaCore> is the jig the camera?
[22:34:20 CET] <SortaCore> yea, I just get a warning, or it might be an error?
[22:34:31 CET] <SortaCore> I modified the log callback to discard them
[22:41:36 CET] <BtbN> atomnuker, this audio glitch has been going on on Twitch for a while now. Since most streams use OBS, which uses the ffmpeg aac encoder, could this be a glitch in our aac encoder? https://clips.twitch.tv/NicePopularPorcupineCurseLit
[22:42:17 CET] <BtbN> It is triggered by various high pitched noises. Alttp has a bunch of them, and it's happening over and over again, and it's highly annoying.
[22:48:36 CET] <BtbN> https://btbn.de/public/glitch.mp4 here it's as raw mp4
[22:51:02 CET] <atomnuker> I wish most would use the ffmpeg aac encoder...
[22:51:16 CET] <BtbN> Every stream running with OBS uses it
[22:51:23 CET] <BtbN> which is the absolute majority on Twitch
[22:51:53 CET] <atomnuker> its been *5* years since I used obs but I remember it needed an ffmpeg.exe
[22:52:07 CET] <atomnuker> and I think most compilations used libfdk_aac
[22:52:08 CET] <BtbN> it never needed an ffmpeg.exe oO
[22:52:25 CET] <atomnuker> I thought I remembered you had to download it
[22:52:30 CET] <BtbN> The old OBS, which was 5 years old, uses libvo_aac or something
[22:52:59 CET] <BtbN> The current, new OBS uses libav*, and by default, that is if you don't build it with fdk yourself, it uses the ffmpeg native encoder
[22:54:01 CET] <BtbN> So I'm pretty sure that glitched clip there was encoded with the ffmpeg aac encoder
[22:54:24 CET] <BtbN> And I'd like to know if it's a bug on ffmpegs end
[22:56:16 CET] <atomnuker> do you know often it occurs?
[22:57:03 CET] <BtbN> not all the time. But specially when there's a lot of high pitched noises(In Link to the past, the sound of the spike-things or the boomerang hitting a wall is very trigger happy there)
[22:57:22 CET] <BtbN> I'd say once or twice every couple hours, with alttp
[22:59:32 CET] <atomnuker> hm, I know kierank's using the encoder in production and he hasn't seen anything like this
[23:00:04 CET] <atomnuker> though he doesn't use aac_pns because it was unstable
[23:00:23 CET] <kierank> Yes
[23:00:23 CET] <BtbN> This is going on on Twitch for almost a year now according to some people. I have only noticed in the last couple months
[23:00:52 CET] <atomnuker> if I knew this many people use the encoder I'd have made the fast coder the default
[23:01:23 CET] <BtbN> By now, with obs, it's several tens of thousands of people using it all the time
[23:01:40 CET] <BtbN> if not more
[23:01:50 CET] <BtbN> over 90% of the streams on Twitch are made with it
[23:02:34 CET] <JEEB> yup
[23:02:44 CET] <atomnuker> I really doubt it, I don't watch twitch streams often but every time I do I look at the spectrum
[23:02:53 CET] <atomnuker> and I see that 15khz bandwidth limiting fdk does
[23:03:10 CET] <BtbN> None of the popular streaming software use fdk though
[23:03:24 CET] <BtbN> You also have to look at the source stream. Not one of their transcodes.
[23:03:29 CET] <atomnuker> I thought people downloaded special builds to have it
[23:03:34 CET] <JEEB> https://twitter.com/marcan42/status/873241816434221056
[23:03:35 CET] <BtbN> That might be using fdk, but I have no idea.
[23:03:40 CET] <JEEB> kind of reminds me of this
[23:03:51 CET] <sfan5> obs can't ship with fdk because of the licensing anyway, can it?
[23:03:52 CET] <JEEB> although he uses some heavy words there :P
[23:04:06 CET] <JEEB> sfan5: as long as you don't put it together with (L)GPL stuff you can distro it
[23:04:10 CET] <JEEB> like ubuntu does, or debian
[23:04:21 CET] <sfan5> but x264 is gpl and i'm sure they ship that
[23:04:56 CET] <JEEB> yup. in anothoer process, IIRC
[23:05:16 CET] <BtbN> no
[23:05:22 CET] <JEEB> oh, ok
[23:05:24 CET] <BtbN> nothing is done in another process, except for qsv
[23:05:28 CET] <JEEB> ah, right
[23:05:59 CET] <BtbN> But I don't think obs ships with fdk by default
[23:06:09 CET] <BtbN> And I'm not aware of any widely used custom builds with it
[23:06:19 CET] <BtbN> most people who use obs don't even know what aac is
[23:09:06 CET] <atomnuker> I'll run the lttp soundtrack through the encoder for a few hours and I'll use af_volumedetect to see if anything bad does appear
[23:09:17 CET] <BtbN> It's not in the soundtrack
[23:09:21 CET] <BtbN> it's the in game sound effects
[23:09:55 CET] <JEEB> can someone provide a simple enough test case that can be utilized?
[23:10:06 CET] <JEEB> for repeating it
[23:10:12 CET] <BtbN> So far I have not been able to reproduce it intentionally
[23:10:42 CET] <BtbN> https://www.twitch.tv/speedgaming/videos/all and https://www.twitch.tv/speedgaming2/videos/all have a huge bunch of hour+ long gameplay
[23:11:23 CET] <JEEB> yea, would be nice if someone could cap audio from one of those things that seems to make it happen and then that thing could be looped for testing
[23:12:34 CET] <nevcairiel> to really be reproducible you need the original audio though, so thats a bit harder
[23:12:37 CET] <atomnuker> well, I haven't really played through the entire lttp, maybe I should do that tomorrow and record the audio
[23:13:06 CET] <JEEB> nevcairiel: yea that's why I was requesting :/
[23:13:18 CET] <JEEB> atomnuker: was lttp the SNES one?
[23:13:23 CET] <BtbN> it was
[23:13:38 CET] <JEEB> right, I should now finally be able to play it with the little SNES box I got :V
[23:13:52 CET] <BtbN> it emulates pretty perfectly
[23:13:57 CET] <atomnuker> it sure does
[23:14:18 CET] <atomnuker> I wish saturn games would emulate perfectly too...
[23:14:27 CET] <rcombs> tfw I can't find my snes
[23:14:56 CET] <BtbN> The hookshot sound is also very trigger-happy
[23:15:04 CET] <BtbN> and hookshot hitting the wall is very easy to do
[23:16:18 CET] <JEEB> rcombs: I need to find my Megadrive from Russia
[23:26:03 CET] <atomnuker> the megadrive was so ahead of its time
[23:26:48 CET] <atomnuker> had a nice, generic cisc cpu
[23:27:00 CET] <atomnuker> wasn't until the xbox that a console used a cisc cpu again
[23:27:22 CET] <JEEB> my father's sister's kids never really understood how nice the segamega was :<
[23:27:33 CET] <JEEB> so if they still keep that box around, I will take it back
[23:43:52 CET] <BtbN> atomnuker, https://btbn.de/public/lttp.flac some lossless recording of a bit lttp messing around
[23:49:17 CET] <atomnuker> jesus christ, 27x realtime isn't nice at all
[23:51:29 CET] <iive> atomnuker: you mean, playing games at 27x speed?
[23:52:02 CET] <BtbN> Pretty sure he means that the aac encoder is too slow for his liking
[23:52:35 CET] <iive> hum, 27x is acceptable speed. or maybe it doesn't produce good quality at that speed?
[23:58:02 CET] <atomnuker> the native opus encoder is 200x realtime if you disable most searching, libopus is like 96x realtime
[23:58:33 CET] <atomnuker> though the speed would plummet if I implemented support for the pitch prefilter
[23:58:55 CET] <atomnuker> (or maybe it wouldn't, its a FIR filter IIRC so it can be SIMDd)
[00:00:00 CET] --- Sun Nov 26 2017