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

[burek]

[01:25:56 CEST] <cone-086> ffmpeg 03James Almer 07master:b4330a0e02fc: avformat/concatdec: fix the h264 annexb extradata check
[04:23:39 CEST] <YokoBR> hi folks
[04:23:40 CEST] <YokoBR> anybody using fluent-ffmpeg?
[05:20:57 CEST] <TimothyGu> nevcairiel: fatebeta restarted
[07:48:55 CEST] <alevinsn> for the following patch "[PATCH] avformat/hlsenc: fix CID 1405135"
[07:48:59 CEST] <alevinsn> what does CID mean?
[07:49:06 CEST] <alevinsn> CID 1405135 to be precise
[08:09:54 CEST] <atomnuker> Coverity ID
[08:12:10 CEST] <rcombs> alevinsn: more importantly, that patch is very broken
[08:13:50 CEST] <rcombs> that guy has written an impressive quantity of security bugs in patches lately
[08:15:12 CEST] <rcombs> I guess I can't expect someone to stick to just one vuln class; last time it was a printf with a data-controlled format-string, this time a buffer overflow&
[08:16:49 CEST] <alevinsn> admittedly, the buffer overflow is unlikely to occur--but, it would be easy to make it happen
[08:17:45 CEST] <alevinsn> I'm not sure I would say "very broken"
[08:17:53 CEST] <alevinsn> the original code is also broken too
[08:17:57 CEST] <alevinsn> in a similar way
[08:18:03 CEST] <alevinsn> since it could copy past the end of the string
[08:18:09 CEST] <alevinsn> and would almost certainly do so
[08:18:18 CEST] <rcombs> or, it's in the muxer, so I guess it's not strictly a security issue
[08:18:31 CEST] <rcombs> but wow that's some bad practice
[08:18:49 CEST] <rcombs> alevinsn: both strncpy and av_strlcpy only read until the source string's terminator at most
[08:19:28 CEST] <rcombs> using strlen() on the source string as the length arg indicates a failure to understand what that arg is for
[08:19:32 CEST] <alevinsn> hmm, is that true for strncpy()?  if it is, then I'm not sure what is wrong with the original code
[08:19:50 CEST] <rcombs> strncpy() doesn't terminate the destination if the source is too long
[08:20:01 CEST] <alevinsn> right
[08:20:05 CEST] <rcombs> which actually can't happen here anyway
[08:20:31 CEST] <alevinsn> why not?  key_url corresponds to a parameter passed in by the user
[08:20:45 CEST] <rcombs> oh whoops I was looking at the wrong member
[08:20:54 CEST] <rcombs> so yes it can happen
[08:21:01 CEST] <alevinsn> and key_basename is formed using filename
[08:21:06 CEST] <rcombs> with the old code it would've written up to the end of the buffer and not terminated
[08:21:15 CEST] <rcombs> with the modified code it would write past the end
[08:21:26 CEST] <alevinsn> so, I think it could be problem with key_basename as well
[08:21:38 CEST] <rcombs> since it doesn't actually pass in a maximum size to write
[08:21:58 CEST] <rcombs> probably not within lavf's threat model, since it's an AVOption string and not actual input data
[08:22:00 CEST] <rcombs> but still, wtf
[08:23:13 CEST] <alevinsn> yeah, new version is worse than the minor issue with the old version
[08:25:45 CEST] <alevinsn> perhaps more of any issue if it uses key_basename?
[08:25:48 CEST] <alevinsn> it forms it as follows:
[08:25:49 CEST] <alevinsn>     av_strlcpy(hls->key_basename, s->filename, len);
[08:25:49 CEST] <alevinsn>     av_strlcat(hls->key_basename, ".key", len);
[08:25:59 CEST] <alevinsn> I'm not sure where s->filename comes from
[08:26:07 CEST] <alevinsn> but perhaps that is user-specified?
[08:26:32 CEST] <rcombs> that's AVFormatContext::filename, which is consumer/user-specified, eys
[08:26:34 CEST] <rcombs> *yes
[08:26:40 CEST] <rcombs> it's a fixed-size buffer
[08:27:38 CEST] <alevinsn> also 1024 bytes
[08:27:43 CEST] <alevinsn> so, if full length used up
[08:27:51 CEST] <alevinsn> then, will definitely be larger than 1024 bytes
[08:28:29 CEST] <rcombs> tl;dr remember that the third arg to av_strl(cat|cpy) is the size of the destination buffer, NOT the length of the input string
[08:28:41 CEST] <rcombs> else you will be eaten by a grue
[08:29:17 CEST] <rcombs> also I sort of frown on fixed-sized buffers for filenames and URLs
[08:29:40 CEST] <rcombs> like, it's not as bad as Windows 260-byte paths, so I can't complain _too_ much, but still
[08:29:57 CEST] <rcombs> it's not like these functions get called in tight loops; we can afford the malloc
[08:31:33 CEST] <rcombs> (usually I figure it's worth trying to avoid a malloc if it happens once or more per frame, and likely not otherwise; maybe other people have other opinions though)
[08:31:46 CEST] <alevinsn> of course, then you have to worry about someone understanding pointers and memory allocations and deallocations and such :-)
[08:33:15 CEST] <alevinsn> regarding your comment regarding the log message for that patch, I wish people would spent more time writing detailed log messages
[08:33:24 CEST] <alevinsn> in general
[08:34:36 CEST] <alevinsn> that was one of the worst, but not everyone that might be able to review these patches
[08:34:51 CEST] <alevinsn> comes into this with detailed knowledge of the relevant code
[08:36:01 CEST] <alevinsn> anyway, think I will head to sleep, bye
[10:23:14 CEST] <atomnuker> rcombs: what's happening with the dash demuxer patch, did you test it?
[10:24:58 CEST] <rcombs> atomnuker: I sent an additional set of comments; patch author hasn't applied yet
[11:31:28 CEST] <BtbN> What the flying fuck... with the patch from nvidia applied, -hwaccel cuvid into nvenc _sometimes_ runs into "Failed locking bitstream buffer: invalid param (8)"
[11:31:44 CEST] <BtbN> But _only_ if I specify -bf 0 on the commandline
[11:32:08 CEST] <BtbN> Strange thing about that is, 0 is the default, and according to some debug prints I added, the values it affects are indeed identical
[11:54:14 CEST] <BtbN> philipl, ^
[11:54:28 CEST] <BtbN> This makes me wonder if setting -bf somehow causes memory corruption somewhere
[12:01:03 CEST] <sam> howdy
[12:01:17 CEST] <sam> I got a DMCA takedown notice for http://people.zoy.org/~sam/ISO-IEC-14496-2-2001.pdf
[12:01:27 CEST] <sam> so I'm probably going to remove it
[12:23:46 CEST] <BtbN> Gonna try to tackle this with an asan build
[12:23:58 CEST] <BtbN> But I somehow feel this is something bad happening in cuvid code
[12:24:11 CEST] <BtbN> valgrind reports a ton of "jump depends on uninitialized value" errors from there
[12:36:43 CEST] <BtbN> yeah, building ffmpeg with asan aborts immediately
[12:36:49 CEST] <BtbN> in libcuda...
[12:41:30 CEST] <BtbN> Is there a way to ignore external libs, or to at least continue instead of aborting?
[12:47:10 CEST] <ubitux> disable it at build time?
[12:52:51 CEST] <BtbN> ubitux, well, then I don't get asan?
[12:54:18 CEST] <ubitux> i mean disable libcuda
[12:54:53 CEST] <BtbN> Well, but I want to find out why it behaves so weird
[12:55:01 CEST] <BtbN> When using cuvid
[12:55:09 CEST] <BtbN> and nvenc, combined. https://bpaste.net/show/6881b5631b9b That's what it aborts on
[12:55:10 CEST] <ubitux> ah my bad, misunderstood
[12:55:43 CEST] <ubitux> are these false positive?
[12:55:48 CEST] <BtbN> Probably not
[12:55:59 CEST] <BtbN> but out of my scope to do anything about them, as they happen in driver code
[12:56:18 CEST] <ubitux> you can add ignores in the valgrind.supp thing
[12:56:26 CEST] <BtbN> That's gcc asan though
[12:56:28 CEST] <BtbN> not valgrind
[12:56:48 CEST] <ubitux> i know, but you mentioned valgrind earlier :p
[12:56:55 CEST] <BtbN> Yeah, I tried that as well
[12:57:01 CEST] <BtbN> but valgrind doesn't find anything serious
[12:57:05 CEST] <BtbN> asan does
[12:57:14 CEST] <BtbN> but i'd still like it to continue
[14:35:07 CEST] <cone-591> ffmpeg 03Anton Khirnov 07master:86157e6db2c7: hevc: decouple calling get_format() from exporting the SPS parameters
[14:35:07 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:76cc100afba2: Merge commit '86157e6db2c7a9222f77fa7e7f50fb9aebc3aa81'
[14:36:02 CEST] <cone-591> ffmpeg 03Derek Buitenhuis 07master:5c7f2cf81df0: h264_slice: Wait for refs to be available before we use them in error concealment
[14:36:03 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:9bc37352ded5: Merge commit '5c7f2cf81df06614f255f061850132355a01d75e'
[14:37:22 CEST] <cone-591> ffmpeg 03Derek Buitenhuis 07master:e94b9313b21c: fate: Add h264 test for frame num gaps
[14:37:23 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:a5ee1b617a17: Merge commit 'e94b9313b21c3d91a36ef064f7fe3e867616f47f'
[14:37:46 CEST] <wm4> atomnuker: was it you who complained about Libav bitstream API naming?
[14:38:18 CEST] <cone-591> ffmpeg 03Wan-Teh Chang 07master:343e28339946: pthread_frame: use better memory orders for frame progress
[14:38:19 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:964ae2db322c: Merge commit '343e2833994655c252d5236a3394bf6db7a4d8b1'
[14:39:19 CEST] <cone-591> ffmpeg 03Diego Biurrun 07master:554e55bbf0e4: decode.h: Add missing headers to fix standalone compilation
[14:39:20 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:40cc925f9321: Merge commit '554e55bbf0e4a3640a784cb512b816e776c56333'
[14:39:22 CEST] <BtbN> they renamed it?
[14:40:33 CEST] <cone-591> ffmpeg 03Diego Biurrun 07master:39929e55eb13: ppc: hevcdsp: Use shorthands for vector types
[14:40:34 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:3a033bc5cfae: Merge commit '39929e55eb13eeb8dfbe1bc99301fecf6b8942dd'
[14:40:38 CEST] <wm4> BtbN: well he objected to the naming in the first place (identifiers too long)
[14:41:07 CEST] <BtbN> yes, I know. What i meant is, that they now think the same way and renamed the new API
[14:42:15 CEST] <wm4> no I didn't mean that
[15:12:18 CEST] <durandal_1707> i see no patches for bitstream renaming
[15:12:47 CEST] <wm4> there aren't any
[15:13:20 CEST] <durandal_1707> so what is truth?
[15:14:31 CEST] <wm4> "Truth is most often used to mean being in accord with fact or reality,[1] or fidelity to an original or standard.[1] Truth may also often be used in modern contexts to refer to an idea of "truth to self," or authenticity."
[15:15:10 CEST] <wm4> anyway, I'm referring to the current Libav API, and the dislike of it by some ffmpeg developers
[15:15:41 CEST] <durandal_1707> wat, i asked if libav devs are going to rename it
[15:16:03 CEST] <wm4> no, why would you think that
[15:17:52 CEST] <durandal_1707> someone planted such idea in my brain waves
[16:25:09 CEST] <cone-591> ffmpeg 03Diego Biurrun 07master:ea7ee4b4e381: ppc: Centralize compiler-specific altivec.h #include handling in one place
[16:25:10 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:172b0e2e8883: Merge commit 'ea7ee4b4e381e0fa731458de0cbf740430eeb013'
[16:28:50 CEST] <cone-591> ffmpeg 03Diego Biurrun 07master:05a603a94e4b: ppc: Merge types_altivec.h into util_altivec.h
[16:28:51 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:06aafda03f1c: Merge commit '05a603a94e4b3eeefa5e18ae653a848001461e89'
[16:29:26 CEST] <cone-591> ffmpeg 03Janne Grunau 07master:2425d7329fdc: arm64: replace 'bic' with immediate with 'and' with inverted immediate
[16:29:27 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:0f00eb0e4ec1: Merge commit '2425d7329fdccfa9954faba748f3865151354f0c'
[16:33:28 CEST] <cone-591> ffmpeg 03Martin Storsjö 07master:cdcfa97dc49d: libavformat: Fix a faulty api deprecation guard in prepare_input_packet
[16:33:29 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:be6f6fce2e48: Merge commit 'cdcfa97dc49d83b5eefd0a651db6bb0a6f98e8f2'
[16:36:58 CEST] <cone-591> ffmpeg 03Michael Niedermayer 07master:a4fec9a7eab8: rtmppkt: Check for packet size mismatches
[16:36:59 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:65c3621d78c9: Merge commit 'a4fec9a7eab842ea5eea1b1ee98624356cb31422'
[16:38:40 CEST] <cone-591> ffmpeg 03Steve Lhomme 07master:ef9a711be718: configure: put d3d11 check in alphabetical order
[16:38:41 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:9c1b09f73ec3: Merge commit 'ef9a711be718ed3802a263d1d9ed340a4aaef224'
[16:41:20 CEST] <cone-591> ffmpeg 03Steve Lhomme 07master:f7174d7ed045: configure: fix linking with MSVC when using --disable-optimizations
[16:41:21 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:f9ecf5498c63: Merge commit 'f7174d7ed045445d00a6d557236737d09ad32343'
[16:42:46 CEST] <cone-591> ffmpeg 03Diego Biurrun 07master:1faffe7e8fab: configure: Disentangle vfw32 and user32 lib handling
[16:42:47 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:dfbfbbfa48ca: Merge commit '1faffe7e8fab21186a233011bc8a62f47962e2cd'
[16:51:15 CEST] <philipl> BtbN: I think it has to be in their code.
[16:51:28 CEST] <philipl> I mean, bf > 0 was already failing with cuvid. So with his patch it now fails with 0 sometimes?
[16:51:37 CEST] <BtbN> yes, but with a different error
[16:51:49 CEST] <BtbN> But it does not fail at all if you don't specify -bf at all, which defaults to 0.
[16:51:54 CEST] <BtbN> Only manually specifying -bf 0 fails.
[16:52:03 CEST] <philipl> Umm.
[16:52:06 CEST] <BtbN> And I'm completely baffled by that fact.
[16:52:27 CEST] <philipl> Terrifying
[16:52:51 CEST] <BtbN> This almost sounds to me like somewhere in ffmpeg, while parsing the -bf option, something writes somewhere where it's not supposed to write
[16:53:32 CEST] <BtbN> But I already checked the simple possibilities. max_b_frames is not smaller than an int or something
[17:04:37 CEST] <BBB> I Dont understand how the patch for pthread_frame.c changes behaviour
[17:04:46 CEST] <BBB> there is already this code in pthread_frame.c:decode_frame():
[17:04:47 CEST] <BBB>  530         if (p->result < 0)
[17:04:48 CEST] <BBB>  531             err = p->result;
[17:04:56 CEST] <BBB> so how can an error not be propagated already with this code?
[17:07:17 CEST] <BBB> oh I see were skipping over threads that failed to decode frames
[17:07:18 CEST] <BBB> hm...
[17:07:22 CEST] <wm4> it's anout the draining case
[17:07:25 CEST] <wm4> *about
[17:10:11 CEST] <philipl> BtbN: yuck. You tried valgrind yet?
[17:10:27 CEST] <BtbN> yes, lots and lots of stuff in cuda and cuvid libs
[17:10:30 CEST] <BtbN> nothing in ffmpeg
[17:10:38 CEST] <BtbN> gcc asan aborts imediately with a heap overflow in libcuda
[17:11:27 CEST] <BtbN> Just upgraded gcc and nvidia drivers, will try again with newer ones
[17:11:50 CEST] <BBB> wm4: so & about draining
[17:12:04 CEST] <BBB> wm4: if were draining, how does a decoder signal that draining is completed?
[17:12:14 CEST] <BBB> is it by return < 0 and *got_picture_ptr = 0?
[17:12:20 CEST] <BBB> or return = 0 and *got_picture_ptr = 0?
[17:13:25 CEST] <BBB> if we use the second, then the first could be used to transmit all error codes back to the user thread
[17:13:33 CEST] <BBB> which would be non-destructive
[17:13:42 CEST] <BBB> (not sure if thats an API change)
[17:16:32 CEST] <cone-591> ffmpeg 03Diego Biurrun 07master:ee480790c7ee: build: Add name parameter to check_lib() helper function
[17:16:33 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:7e503828b038: Merge commit 'ee480790c7eeb03c9cebd8971c46e0cb7db65277'
[17:16:41 CEST] <wm4> BBB: return=0 got_picture=0
[17:16:59 CEST] <BBB> so lets use < 0 as a non-drained case then?
[17:17:10 CEST] <wm4> I think that's how it's supposed to work anyway
[17:17:25 CEST] <wm4> some decoders can't get out of this state though (they'll never finish draining)
[17:17:36 CEST] <BBB> wdym?
[17:18:11 CEST] <wm4> currently we signal errors with "return < 0 and *got_picture_ptr = 0" at any time
[17:18:20 CEST] <wm4> during normal decoding and during draining
[17:18:35 CEST] <wm4> I'm not sure what pthread_frame.c does out of this
[17:20:56 CEST] <cone-591> ffmpeg 03Anton Khirnov 07master:0fea8555ae25: v4l2: use codec descriptors for mapping a codec name to id
[17:20:57 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:a0ffd66caaae: Merge commit '0fea8555ae25124c21f4c4f55a5fa76e9169aa03'
[17:24:16 CEST] <philipl> BtbN: Well, I desperately hope the nvidia gang can actually look at it. They're the only ones that can really do anything it seems
[17:24:51 CEST] <BtbN> Gonna drop some valgrind and asan outputs once this upgrade is done
[17:29:08 CEST] <cone-591> ffmpeg 03Anton Khirnov 07master:373fd76b4dbd: hevcdec: do not set decoder-global SPS prematurely
[17:29:09 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:84a368f6fec8: Merge commit '373fd76b4dbd9aa03ed28e502f33f2ca8c1ce19a'
[17:29:15 CEST] <ubitux> can anyone look into the next 2 pthread commits to merge?
[17:29:18 CEST] <ubitux> wm4 maybe?
[17:29:48 CEST] <wm4> hashes?
[17:29:56 CEST] <ubitux> 8dfba25ce8 pthread_frame: ensure the threads don't run simultaneously with hwaccel
[17:29:57 CEST] <ubitux> d4a91e6534 pthread_frame: do not run hwaccel decoding asynchronously unless it's safe
[17:30:15 CEST] <nevcairiel> we should have those
[17:30:29 CEST] <wm4> should have been fully merged, yes
[17:30:34 CEST] <ubitux> oh? my bad
[17:30:36 CEST] <ubitux> cool
[17:31:13 CEST] <ubitux> indeed
[17:31:15 CEST] <ubitux> sorry about the noise
[17:31:31 CEST] <jamrial> ubitux: in 76cc100afb, was the switch from ff_thread_get_format to ff_get_format intended?
[17:31:51 CEST] <ubitux> jamrial: oh, probably not
[17:31:53 CEST] <jamrial> libav never used ff_thread_get_format, and we used it even before 786032cad8
[17:31:55 CEST] <cone-591> ffmpeg 03Anton Khirnov 07master:8dfba25ce89b: pthread_frame: ensure the threads don't run simultaneously with hwaccel
[17:31:56 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:8c6f18e4449a: Merge commit '8dfba25ce89b62c80ba83e2116d549176c376144'
[17:32:04 CEST] <ubitux> jamrial: that's a mistake yes
[17:32:11 CEST] <jamrial> ah ok
[17:32:20 CEST] <ubitux> i'll fix it after a few tests
[17:33:09 CEST] <cone-591> ffmpeg 03Anton Khirnov 07master:d4a91e65343b: pthread_frame: do not run hwaccel decoding asynchronously unless it's safe
[17:33:09 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:540b8760e84c: Merge commit 'd4a91e65343be5d79a4afa61c791191e1b57499a'
[17:36:08 CEST] <cone-591> ffmpeg 03Clément BSsch 07master:78a5fc4579de: lavc/hevcdec: fix invalid use of ff_get_format()
[17:38:12 CEST] <ubitux> enough merges for me for today
[18:08:58 CEST] <uau> BBB: as for errors during draining being an API change, i think decoding applications using the old api may stop at first non-frame-return
[18:09:31 CEST] <uau> and perhaps new API too
[18:09:31 CEST] <BBB> I was afraid of that
[18:09:37 CEST] <BBB> maybe we should change that
[18:09:42 CEST] <BBB> (I know this isnt as easy as it sounds)
[18:10:45 CEST] <uau> i looked at the previous mpv code when this was discussed earlier, and IIRC it did stop decoding when feeding drain packet and getting no return frame (changed when moving to the new decode api, so current mpv doesn't do that)
[18:11:33 CEST] <uau> not sure how serious a compatibility break losing some frames at end is
[18:16:23 CEST] <wm4> I think a correct user of the old API could drain the decoder until no error or frame was returned
[21:07:37 CEST] <philipl> BtbN: just reading through the headers, I wonder if we need to use the cuvid video lock mechanism instead of push/pop ctx
[21:07:45 CEST] <philipl>  * NOTE: This is a safer alternative to cuCtxPushCurrent and cuCtxPopCurrent, and is not related to video
[21:07:48 CEST] <philipl>  * decoder in any way (implemented as a critical section associated with cuCtx{Push|Pop}Current calls).
[21:08:07 CEST] <BtbN> no, no reason to use them
[21:08:21 CEST] <philipl> I mean, given our cuvid vs nvenc weirdness
[21:08:36 CEST] <BtbN> They seem to be some wrapper around push/pop ctx, no additional functionality
[21:09:56 CEST] <BtbN> I don't get the point of that API at all
[21:10:10 CEST] <BtbN> cuvidCtxLock translates directly to PushCtx, and Unlock to Pop
[21:11:33 CEST] <BtbN> I think with the difference that it actually blocks if it's not already pushed?
[21:11:38 CEST] <BtbN> -not
[21:11:55 CEST] <BtbN> But as ffmpeg is single threaded, that should not be an issue
[21:56:01 CEST] <BtbN> philipl, wow, upgrading gcc to 5.4 from 4.9 actually did something
[21:56:23 CEST] <BtbN> https://bpaste.net/show/81e8befd95e1
[21:56:32 CEST] <JEEB> yea, 4.8 and 4.9 are meh
[21:56:48 CEST] <BtbN> this almost looks like something _is_ wrong in ffmpeg code
[21:56:58 CEST] <DHE> yeah the sanitizer is cool. like valgrind but without the 99% performance hit.
[22:04:38 CEST] <BtbN> I have a slight feeling I know what's happening
[22:04:44 CEST] <BtbN> And I wonder why I didn't _explode_ earlier
[22:07:39 CEST] <BtbN> Yeah, enabling memory poisoning with CUDA is a _bad_ idea
[22:08:05 CEST] <BtbN> libavutil/buffer.c:294 just assumes the pool is normal system memory, and memsets it
[22:09:07 CEST] <BtbN> so lets do that again, without memory poisoning
[22:09:12 CEST] <BtbN> no idea... is this a bug?
[22:11:40 CEST] <wm4> uh wut
[22:12:17 CEST] <wm4> so it clears the buffer memory
[22:12:20 CEST] <wm4> that should be fine?
[22:12:24 CEST] <wm4> why does it blow up with cuda?
[22:12:46 CEST] <BtbN> Because the memory buffer is CUDA device memory
[22:12:49 CEST] <BtbN> and not system memory
[22:12:52 CEST] <BtbN> can't just memset it
[22:13:23 CEST] <wm4> is it a pool with a custom allocator?
[22:13:35 CEST] <BtbN> yes, created by the hwcontext cuda stuff
[22:13:48 CEST] <wm4> oh yeah, then I agree the memset is a bug
[22:13:56 CEST] <wm4> it should work for opaque frames
[22:14:18 CEST] <wm4> but that memory poisoning stuff is hacky nonsense anyway
[22:14:19 CEST] <BtbN> guess it never blew up before cause everything still so happens to be system memory you can memset
[22:14:29 CEST] <wm4> memory sanitizer or valgrind should do this instead
[22:15:08 CEST] <BtbN> Yeah, pretty sure asan already takes care
[22:16:33 CEST] <BtbN> hm, kinda disappointed. Hoped for an actual bug there
[22:16:38 CEST] <BtbN> *the actual bug
[22:16:50 CEST] <BtbN> For why this whole thing behaves so strange
[22:22:27 CEST] <BtbN> hm, after updating gcc and the nvidia drivers, all the weirdness is gone
[22:22:37 CEST] <wm4> call it a day
[22:22:54 CEST] <BtbN> valgrind also does not support out-of-bounds writes in their driver anymore
[22:22:59 CEST] <BtbN> maybe they actually fixed them
[22:23:42 CEST] <philipl> BtbN: so new gcc == the errors went away?
[22:23:43 CEST] <philipl> terrifying
[22:23:54 CEST] <BtbN> I updated gcc and nvidia-drivers at the same time
[22:24:04 CEST] <philipl> gcc --version
[22:24:05 CEST] <philipl> gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
[22:24:13 CEST] <BtbN> I'm on 5.4 now
[22:24:16 CEST] <philipl> How are you stuck with 4.x or 5.x even?
[22:24:28 CEST] <BtbN> until a week ago, 4.9 was the stable gcc on Gentoo
[22:24:33 CEST] <BtbN> they recently updated to 5.4
[22:25:00 CEST] <BtbN> gcc 6 still miscompiles or straight up fails to build like a few dozen packages, so it's masked
[22:28:27 CEST] <jamrial> only package i saw miscompiled by gcc 6 was libvpx on mingw64
[22:28:30 CEST] <BtbN> Updated to 381.09 from 378.13.
[22:28:40 CEST] <BtbN> jamrial, actual miscompilation is a very small fraction
[22:28:55 CEST] <BtbN> most of them are failed builds because developers thought forcing -Werror in their build system is smart.
[22:30:19 CEST] <BtbN> philipl, the error on bf > 0 is still there like always
[22:30:27 CEST] <BtbN> only the weird random behavior is gone
[22:34:17 CEST] <philipl> BtbN: gotcha.
[22:34:34 CEST] <BtbN> Hope the new nvidia guy can look into that
[22:34:53 CEST] <BtbN> Will apply the patch now though, there's nothing wrong with it on its own.
[22:35:42 CEST] <philipl> yay
[22:36:01 CEST] <iive> BtbN: if the buffer is image buffer, why is it not been able to be written into?
[22:36:21 CEST] <BtbN> Because it's a CUdeviceptr
[22:36:25 CEST] <BtbN> and not actual memory
[22:36:55 CEST] <wm4> apropos, does cuvid support the hw_device_ctx API yet?
[22:37:12 CEST] <wm4> since the hw_frames_ctx API is broken (never was implemented correctly)
[22:37:36 CEST] <BtbN> Did that land?
[22:37:45 CEST] <cone-627> ffmpeg 03Ben Chang 07master:8de3458a0737: avcodec/nvenc: surface allocation reduction
[22:39:06 CEST] <wm4> BtbN: yes
[22:39:26 CEST] <BtbN> missed that, shouldn't be hard to convert
[22:44:50 CEST] <iive> BtbN: there seems to be a flag about buffer been writable, i guess this one should be checked before memory poison.
[22:44:57 CEST] <iive> on release.
[22:45:17 CEST] <BtbN> well, it _is_ writable. Just not with normal memory functions. cuMemset on it would work
[22:47:34 CEST] <iive> isn't there a flag signalling hw acceleration pixfmt?
[22:50:01 CEST] <BtbN> Not on a buffer pool
[22:51:50 CEST] <iive> if codecs use that pool for hw pixfmt, them maybe ...
[22:53:33 CEST] <wm4> just stop it... the buffer code shouldn't tamper with that memory no matter what
[23:06:06 CEST] <BtbN> that memset should be in the default free function
[23:06:11 CEST] <BtbN> not somewhere mangled into the buffer pool
[23:40:04 CEST] <iive> BtbN: i like that idea
[00:00:00 CEST] --- Thu Apr 27 2017