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

[burek]

[01:40:13 CEST] <philipl> Lynne: It works well enough on Intel that I could implement vaapi/vulkan interop in mpv
[01:40:52 CEST] <philipl> The dma_buf import works and while the format modifier extension is still missing, you can get away with it because both sides agree on the layout of common formats that matter for vaapi
[01:43:10 CEST] <J_Darnley> Anyone else get a dodgy looking email from "reasearchers in Brazil"?
[01:43:16 CEST] <philipl> yep.
[01:43:25 CEST] <philipl> I don't know what a highly configurable system is
[01:43:30 CEST] <philipl> and google won't tell me
[01:44:05 CEST] <philipl> (I mean, I could read one of those papers but I won't)
[01:44:33 CEST] <J_Darnley> durandal_1707: what do you need uploaded?  new fate samples?
[01:45:37 CEST] <J_Darnley> oh, I see the related email
[01:51:53 CEST] <nevcairiel> that went straight to the bin for me, stupid mass-mailings
[01:52:06 CEST] <Lynne> philipl: well that interop is kinda broken on my machine
[01:52:21 CEST] <Lynne> random artifacts when seeking, which does hint there's no sync
[01:53:49 CEST] <Lynne> but seeking does also show random image from the swapchain which leads me to think libplacebo is doing something wrong
[01:55:47 CEST] <philipl> You'd have to discuss that part with haasn. There is certainly no explicit sync mechanism available.
[01:58:17 CEST] <haasn> What code is this in the context of?
[01:58:40 CEST] <Lynne> vaapi -> vulkan
[01:58:52 CEST] <haasn> in ffmpeg?
[01:58:54 CEST] <Lynne> yes
[01:59:19 CEST] <haasn> can you point me at the part in ffmpeg where it does this interop?
[01:59:23 CEST] <Lynne> having read the libva docs they do tell you sync after you export is up to you, but you can call vaSyncSurface() just before you export to hopefully complete all pending ops
[01:59:34 CEST] <Lynne> which didn't fix my issues
[02:00:51 CEST] <haasn> and yes the proper way to do this would be to have a shared semaphore which you can use from both APIs
[02:01:01 CEST] <haasn> I don't know anything about vaapi but that's what we do on the vulkan side of things
[02:02:15 CEST] <haasn> also currently in libplacebo the only way to use semaphores is to create them in vulkan and them import them in the other API
[02:02:52 CEST] <haasn> but it sounds like that is possible?
[02:03:01 CEST] <Lynne> nnnope
[02:03:35 CEST] <Lynne> only halfway
[02:04:13 CEST] <Lynne> you can export a vulkan semaphore to a drm sync object fd, but that's about as far as you'll get as nothing accepts drm sync objects or just plain exported semaphore fds
[02:05:18 CEST] <haasn> also I'm confused as to whether or not you're talking about ffmpeg or mpv here; the vaapi/vulkan interop in mpv is implemented in mpv
[02:05:26 CEST] <philipl> (and to be explicit, intel vulkan driver cannot doesn't support semaphore import)
[02:06:34 CEST] <Lynne> it does, signalled here on my machine and worked... with the fault it didn't error if I gave it a random fd and specified its temporal
[02:06:59 CEST] <Lynne> it did error with "invalid fd" if I said its non-temporal
[02:07:07 CEST] <philipl> Lynne: at least the driver doesn't set the "I support semaphore import" flag.
[02:08:07 CEST] <Lynne> does here, VK_KHR_external_semaphore_fd, version 1
[02:08:21 CEST] <philipl> There's a separate support flag for import and export
[02:08:25 CEST] <philipl> Only the export flag is set
[02:08:57 CEST] <haasn> also yes looking at the mpv code there is indeed no sync code at all
[02:09:06 CEST] <haasn> in the vaapi vulkan interop
[02:09:11 CEST] <philipl> There is not.
[02:09:52 CEST] <Lynne> I thought it checked that, maybe not
[02:10:46 CEST] <haasn> for some reason I didn't realize that when looking at the PR
[02:10:58 CEST] <haasn> Otherwise I would have said to not merge it until synchronization is added x_x;
[02:11:13 CEST] <haasn> I think as it is right now there's no chance that code works except by miracle/luck/coincidence
[02:11:32 CEST] <philipl> Lynne: sorry, ignore. libplacebo doesn't query import caps because it doesn't implement actually importing and using such a semaphore.
[02:11:33 CEST] <haasn> but what needs to change for us to be able to add synchronization here?
[02:11:48 CEST] <haasn> does libplacebo need semaphore import support?
[02:12:00 CEST] <philipl> haasn: there's no way to import or export a semaphore on the vaapi side
[02:12:07 CEST] <philipl> so there's no sync primitive available.
[02:12:13 CEST] <haasn> so how do they expect us to synchronize?
[02:12:43 CEST] <philipl> It's fairly clear they don't expect us to use the feature at all. But I did anyway :-)
[02:12:52 CEST] <haasn> fair enough
[02:12:57 CEST] <haasn> is it at least documented as "this doesn't work yet?"
[02:13:58 CEST] <haasn> I mean something we could do is synchronized on the CPU side
[02:13:58 CEST] <philipl> The 'luck' I was relying on was not trying to re-use resources, and hoping that the vaExport is internally complete before I hand it to vulkan.
[02:14:05 CEST] <haasn> Which sounds slightly ridiculous given that the data never leaves the GPU
[02:14:09 CEST] <philipl> At least visually, that seems to work
[02:14:33 CEST] <haasn> But we could block on the CPU until the GPU operations have completed
[02:14:43 CEST] <haasn> If vaapi has an API like that
[02:15:08 CEST] <philipl> That's what vaSyncSurface would do
[02:15:18 CEST] <philipl> "
[02:15:18 CEST] <philipl> This function blocks until all pending operations on the render target have been completed. Upon return it is safe to use the render target for a different picture.
[02:15:38 CEST] <haasn> "This does not perform any synchronisation. If the contents of the surface will be read, vaSyncSurface() must be called before doing so. If the contents of the surface are written, then all operations must be completed externally before using the surface again by via VA-API functions."
[02:15:41 CEST] <haasn> *shrug*
[02:16:42 CEST] <philipl> So I could add a vaSyncSurface after the export, but Lynne noted it had no visible effect earlier.
[02:17:01 CEST] <haasn> so vaSyncSurface before pl_tex_create does not help?
[02:17:06 CEST] <haasn> maybe it was in the wrong place
[02:17:36 CEST] <philipl> It's unclear what exactly the artifacts-on-seek are. I've noticed them too. You get one frame that looks wrong and then it's back to normal.
[02:17:39 CEST] <haasn> I see we recreate the pl_tex for every frame, so I guess there's no need for sync in the other direction
[02:17:50 CEST] <philipl> That's why i did the recreation, to avoid that need.
[02:18:06 CEST] <haasn> actually where do we pl_tex_destroy
[02:18:21 CEST] <haasn> oh, in the ra tex destroy
[02:18:43 CEST] <philipl> Yes
[02:19:06 CEST] <haasn> it might be UB to reimport the same DRM fd to several vulkan images
[02:19:25 CEST] <haasn> if you pl_tex_create() twice on th same fd the first one might still be in use internally
[02:19:44 CEST] <haasn> there's also the issue of libplacebo possibly still reading from it when you reuse that DRM fd
[02:20:47 CEST] <haasn> if you want to omit synchronization in the other direction then you need to create a new drm buffer for every frame as well
[02:20:59 CEST] <haasn> and only clean the old ones up once libplacebo is fully done using it
[02:21:05 CEST] <haasn> which, incidentally, I'm not even sure how we guarantee, currently
[02:22:08 CEST] <haasn> (I think, technically, in your uninit function you have to be sure to call pl_gpu_finish() before destroying any buffers that were imported to libplacebo)
[02:22:09 CEST] <Lynne> fds are refcounted, so I don't think importing them multiple times is a problem as long as you close() them
[02:22:50 CEST] <haasn> ra_tex_free() doesn't mean it's safe to start calling vaReleaseBufferHandle / vaDestroyImage
[02:23:18 CEST] <haasn> unless you pl_tex_export() first
[02:23:24 CEST] <haasn> but that requires sync objects be working (for obvious reasons)
[02:24:00 CEST] <haasn> so both your mapper_map() and mapper_unmap() currently just ignore synchronization and hope they get lucky
[02:24:43 CEST] <haasn> Lynne: even if it is defined behavior, it would still be defined behavior to the point where the result is undefined if you try writing to an fd via one image while reading from it via another
[02:24:48 CEST] <haasn> Without any synchronization between the two
[02:25:40 CEST] <haasn> so yeah there's just no way this can work unless vaapi gets support for either importing or exporting semaphores; and if vaapi can only export then we'll need to add import support in libplacebo (which can also currently only export)
[02:25:54 CEST] <haasn> which isn't too difficult, probably like 10-20 lines of boilerplate that need to be added
[02:26:00 CEST] <haasn> plus a new API function
[02:26:58 CEST] <philipl> haasn: well, considering how the format modifier extension has made zero progress for years, I wouldn't be expecting much on sync.
[02:27:03 CEST] <Lynne> vaapi can't export, you can sync on when you export the image but before you release it you'll need to wait on a barrier
[02:27:15 CEST] <haasn> wait on a barrier how? CPU side?
[02:27:23 CEST] <haasn> If so we can add a CPU-blocking way to wait until an image is no longer in use
[02:27:38 CEST] <haasn> which we currently don't have becuase that's just idiotic for the most part
[02:27:47 CEST] <Lynne> yeah, it is
[02:28:17 CEST] <Lynne> you can ask libva devs to support it but good luck with its glacial pace
[02:30:41 CEST] <haasn> if you want a quick work-around for testing purposes, you can do a pl_tex_download() of the first pixel and wait for that to complete in mapper_unmap()
[02:31:07 CEST] <haasn> actually the easiest way to test would be to pl_gpu_finish() at the start of mapper_unmap()
[02:31:15 CEST] <haasn> and vaSyncSurface() before pl_tex_create()
[02:31:21 CEST] <haasn> add those two function calls and see if that fixes it
[02:32:07 CEST] <haasn> that will stall the entire GPU and make performance bad, probably
[02:32:11 CEST] <haasn> but it shouldn't cause any glitches
[02:32:46 CEST] <haasn> (pl_tex_download would be a hacky way that doesn't require stalling the entire GPU; but if we confirm this fixes it I can also add an synchronous way of stalling like pl_tex_poll())
[02:33:32 CEST] <haasn> (we can literally just copy/paste the code for pl_buf_poll and make pl_tex_poll, but its use would have to be heavily disincentivized)
[02:34:16 CEST] <philipl> i will try shortly
[02:56:24 CEST] <philipl> annoyingly, I cannot reproduce the visual artifacts now. I saw them, recompiled with vaSyncSurface, stopped seeing them, recompiled without again, and still don't see them. annoying.
[03:04:48 CEST] <philipl> haasn: OK. So maybe I can still get the artifacts to appear. and vaSyncSurface, I think, gets rid of them.
[03:05:04 CEST] <haasn> with or without the gpu finish?
[03:05:13 CEST] <philipl> without gpu_finish
[03:05:46 CEST] <philipl> I don't fully understand why the sync in unmap is needed. The VA Image resources are not reused. They are freed and a new one allocated on the next export.
[03:06:12 CEST] <philipl> So, as long as ra_tex_destroy doesn't pull the VkImage out from under vulkan, it should be ok, shouldn't it?
[03:06:17 CEST] <philipl> (and it doesn't)
[03:07:25 CEST] <philipl> So I would not expect vaapi to be exporting a new surface into an existing image and corrupting something on the vulkan side
[03:08:42 CEST] <Lynne> its not corrupting a codec reference frame at least, none of the artifacts look like that and they disappear within a few output frames
[03:11:59 CEST] <philipl> Right.
[03:12:24 CEST] <philipl> Lynne: so you still see artifacts with vaSyncSurface after export, and with our without the pl_gpu_finish?
[03:14:00 CEST] <philipl> I think the sync-in-unmap should not be required. vaExportSurface returns a new fd each time (or at least a new fd for each exported surface. Re-export probably does re-use the fd). That fd is then owned by the caller, and is held by libplacebo/mpv until the ra_tex_destroy, which is internally ensured to be delayed until the tex is no longer in use.
[03:14:23 CEST] <philipl> So if you export the next surface while still in use, it will use a different fd. The fd will not be free for re-use until the ra_tex_destroy really completes.
[03:14:51 CEST] <philipl> The only way you'd get overlapping reads/writes here is if the underlying memory for the exported surface is re-used independent of the fd, which seems insane.
[03:22:18 CEST] <Lynne> dunno, give me a diff to test
[03:26:08 CEST] <philipl> Lynne: https://github.com/philipl/mpv/commit/bedbd3447b5ac7fe26b03082052a586dd9a4559f
[03:26:16 CEST] <philipl> Uncomment the pl_gpu_finish to test that part.
[04:06:09 CEST] <haasn> philipl: I'm more worried about vaDestroyImage pulling the image contents out from underneath the VkImage
[04:06:19 CEST] <haasn> before the GPU is done reading from them
[04:08:25 CEST] <haasn> but it's possible it will work in practice if the actual buffer is refcounted internally
[04:08:42 CEST] <haasn> and the image contents will stick around until both the vaapi *and* the VkImage views have been destroyed
[04:09:45 CEST] <haasn> it depends on whether or not the vaapi side of things internally knows that the same area of memory is still being accessed by vulkan too
[04:10:14 CEST] <haasn> because in theory vaapi's acquire/write/release loop doesn't have any dependence on vulkan currently
[04:10:22 CEST] <haasn> if there is one, it must be internal to the driver somehow?
[04:13:16 CEST] <philipl> vaDestroyImage doesn't actually get called in the vulkan path
[04:13:21 CEST] <philipl> It's there for GL only
[06:26:31 CEST] <haasn> ah
[06:26:39 CEST] <haasn> so when does the image get freed in the vulkan path?
[07:49:37 CEST] <philipl> haasn: There is no VA Image in the vulkan path. There is the surface, which is exported, and then the fd which is transferred to the caller. so it is freed when the pl tex is finally destroyed.
[09:15:18 CEST] <haasn> ah, I see
[09:15:23 CEST] <haasn> so ownership of the memory moves to libplacebo
[09:15:26 CEST] <haasn> seems fine then
[10:05:11 CEST] <durandal_1707> i gonna write msrle encoder for fun
[10:10:54 CEST] <thardin> huh, both bmp and avi can be msrle
[10:13:40 CEST] <thardin> 00 02 05 01             Move 5 right and 1 down
[10:13:41 CEST] <thardin> funky
[11:11:41 CEST] <Lynne> philipl: vaSyncSurface() alone fixes pretty much everything
[12:42:07 CEST] <philipl> Lynne: thanks. I'll make that a proper PR
[14:24:12 CEST] <durandal_1707> kierank: you no more active, why?
[14:24:59 CEST] <kierank> durandal_1707: ?
[14:26:08 CEST] <durandal_1707> with developing and chatting
[14:27:14 CEST] <kierank> No interesting projects in ffmpeg any more
[14:27:49 CEST] <kierank> There is interlaced mpeg-4 sstp but trust would involve changing masterpiece that is mpeg4video code
[14:28:59 CEST] <kierank> that*
[14:30:52 CEST] <durandal_1707> rewrite it from scratch
[15:03:37 CEST] <Lynne> its fine, someone is implementing 608 captioning in av1, the codec built specifically for the modern internet
[15:06:02 CEST] <Lynne> I give it no more than 2 years until someone figures out how to signal in-band interlacing
[15:14:53 CEST] <durandal_1707> noooooo
[15:16:57 CEST] <kierank> Lynne: 608 is mandatory by law in the usa
[15:17:03 CEST] <kierank> you can go to jail if you don't use it
[15:17:41 CEST] <durandal_1707> country?
[15:22:22 CEST] <kierank> durandal_1707: ?
[15:22:31 CEST] <nevcairiel> silly subtitle metadata at least doesnt influence the video in any way otherwise
[15:23:19 CEST] <durandal_1707> kierank: country in usa with that law?
[15:23:30 CEST] <kierank> usa is the country
[15:23:31 CEST] <nevcairiel> usa is the country
[15:23:33 CEST] <nevcairiel> :D
[15:23:38 CEST] <J_Darnley> Subtitles should only ever be an external ass file.
[15:23:48 CEST] <kierank> the fcc disagrees
[15:24:20 CEST] <kierank> and as you know the fcc won't let me be
[15:24:27 CEST] <nevcairiel> the US is so terribly plaged by legacy rules and regulations, they'll never be able to shake those off because they are entirely stagnant
[15:24:33 CEST] <nevcairiel> plagued*
[15:25:06 CEST] <kierank> europe isn't any better
[15:25:09 CEST] <kierank> sunday trading laws anyone
[15:26:31 CEST] <durandal_1707> kierank: so its global to whole usa and not state specific?
[15:26:36 CEST] <kierank> yes
[15:27:24 CEST] <Lynne> is it only a requirement if the signal carries some public tv or something, so twitch and youtube are exempt?
[15:27:49 CEST] <nevcairiel> its broadcast, not internet...yet
[15:27:56 CEST] <kierank> it's a requirement if you have a tv in a public place
[15:27:59 CEST] <kierank> or any form of stream
[15:28:22 CEST] <kierank> https://www.fcc.gov/consumers/guides/captioning-internet-video-programming
[15:29:42 CEST] <nevcairiel> doesnt that basically just say that you cant remove captions if its a reproduction of TV content
[15:30:14 CEST] <kierank> exactly so they need a way to have it in av1
[15:31:37 CEST] <kierank> you can say, whatever I only watch anime like most people in OSS but 99% of the world watch sports and whatever
[15:31:46 CEST] <kierank> OSS multimedia*
[15:49:03 CEST] <JEEB> captions and alert messages and all that jazz
[15:50:11 CEST] <JEEB> but yea, at least the caption crap is just additional packets in the video stream, only affects rate control :p
[16:18:29 CEST] <cone-480> ffmpeg 03Stefan Schoenefeld 07master:39a5c0ac0651: avcodec/h263dec: fix hwaccel decoding
[16:18:29 CEST] <cone-480> ffmpeg 03Stefan Schoenefeld 07master:ad97be9fa30d: avcodec/h263dec: enable nvdec hwaccel
[16:19:48 CEST] <cone-480> ffmpeg 03Stefan Schoenefeld 07release/4.2:af3541fc7ec0: avcodec/h263dec: fix hwaccel decoding
[16:19:50 CEST] <cone-480> ffmpeg 03Stefan Schoenefeld 07release/4.2:e33ea0f50374: avcodec/h263dec: enable nvdec hwaccel
[16:22:50 CEST] <cone-480> ffmpeg 03Stefan Schoenefeld 07release/4.1:a12e40e0213f: avcodec/h263dec: fix hwaccel decoding
[16:23:54 CEST] <cone-480> ffmpeg 03Stefan Schoenefeld 07release/4.0:1687b067dd58: avcodec/h263dec: fix hwaccel decoding
[16:25:38 CEST] <cone-480> ffmpeg 03Stefan Schoenefeld 07release/3.4:31161bc96931: avcodec/h263dec: fix hwaccel decoding
[17:33:25 CEST] <BtbN> I'm surprised how nobody ever noticed h263 hwaccel was broken that deep back
[17:34:02 CEST] <nevcairiel> i noticed that it was broken a long time ago
[17:34:12 CEST] <nevcairiel> i just didnt care, flagged it as disabled and moved on
[17:34:24 CEST] <BtbN> The fix was fairly simple
[17:34:40 CEST] <nevcairiel> fixes are always simple, finding them is the hard part :D
[17:34:51 CEST] <BtbN> But yeah, hwaccel for anything but h264/hevc/vp9 isn't overly important
[17:35:07 CEST] <BtbN> Well, and AV1, eventually
[17:41:52 CEST] <BtbN> michaelni, would backporting the clang-for-cuda-filters patch be fine to backport to 4.2? It's not a fix, but a worthy addition to have in a release imo.
[17:46:07 CEST] <BtbN> hm, git am refuses to apply the patch. No common ancestor. What.
[17:46:24 CEST] <BtbN> patch -p1 happily takes it
[17:49:57 CEST] <jamrial> BtbN: as long as it's not an api change that would require a version bump (and thus make a mess), it should be good IMO
[17:50:01 CEST] <jamrial> 4.2 is not yet released, just cut into a branch
[17:50:07 CEST] <jamrial> the whole "fixes only" is for point releases
[17:50:16 CEST] <BtbN> It's just an addition to configure
[17:50:28 CEST] <jamrial> since those should not differ feature wise compared to the .0
[17:51:00 CEST] <jamrial> then it should be ok
[17:51:00 CEST] <BtbN> I just need to find a good way to autodetect clang
[18:27:45 CEST] <J_Darnley> I recently had the same problem with `git am`
[18:28:01 CEST] <J_Darnley> Has git tried to become too smart?
[18:28:26 CEST] <J_Darnley> Apply the diff and commit using the message and author provided.
[19:00:14 CEST] <BtbN> J_Darnley, yeah, that's what I ended up doing. Super weird. Even git am -3, which usualy fixes those kind of issues, didn't work.
[19:04:49 CEST] <J_Darnley> I wasn't trying to instruct you, I was trying to instruct git am
[19:05:44 CEST] <BtbN> clang compiled CUDA kernels work fine btw.
[19:05:47 CEST] <BtbN> at least on a 1050
[19:16:20 CEST] <cone-480> ffmpeg 03Rodger Combs 07master:01994c93db43: build: add support for building CUDA files with clang
[19:22:52 CEST] <cone-480> ffmpeg 03Rodger Combs 07release/4.2:86de65fbf074: build: add support for building CUDA files with clang
[20:42:09 CEST] <taliho> Hello, is anyone available to have a quick look at this patch? http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247525.html 
[20:43:37 CEST] <taliho> It allows multiple clients to connect to a single streaming instance 
[20:49:14 CEST] <durandal_1707> michaelni: give me access to ffmpeg security mailing list!
[20:53:47 CEST] <kierank> durandal_1707: ask on ml
[21:11:38 CEST] <durandal_1707> taliho: im not much in protocols, but it looks fine
[21:19:27 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:9cb0da0bfef9: avcodec/utils: fix leak of subtitle_header on error path
[21:19:28 CEST] <cone-480> ffmpeg 03Matt Wolenetz 07release/4.2:907027a4f26d: lafv/wavdec: Fail bext parsing on incomplete reads
[21:19:29 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:598496e50cfd: avcodec/brenderpix: Check input size before allocating image
[21:19:30 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:8d2e23508f20: avcodec/assdec: undefined use of memcpy()
[21:19:32 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:6b04a5dd2d7f: avcodec/eatgv: Check remaining size after the keyframe header
[21:19:33 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:8a03611020b9: avcodec/eatqi: Check for minimum frame size
[21:19:33 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:5fa0b18c95a0: avformat/mpc: deallocate frames array on errors
[21:19:34 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:a33fd082661f: avcodec/apedec: Fix multiple integer overflows and undefined behaviorin filter_3800()
[21:19:35 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:f30d67341e19: avcodec/apedec: make left/right unsigned to avoid undefined behavior
[21:19:36 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:a2c8df28c9c6: avcodec/truemotion2: Fix several integer overflows in tm2_motion_block()
[21:19:37 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:4739a6245105: avcodec/vc1_block: Fix integer overflow in ff_vc1_pred_dc()
[21:19:38 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:7f71ebded4be: avcodec/vc1_pred: Fix invalid shift in scaleforsame()
[21:19:39 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:7821480db5e3: avcodec/vp3: Check that theora is theora
[21:19:40 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:44119e5ad6ca: avcodec/vp3: Check for end of input in vp4_unpack_vlcs()
[21:19:42 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:4f57240859fb: avformat/vividas: Check if extradata was read successfully
[21:19:42 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:c9322598f4e9: avformat/vividas: Check buffer size before allocation
[21:19:44 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:c8dea60fcab5: avcodec/clearvideo: fix invalid shift in tile size check
[21:19:44 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:7ce1e57c016d: avformat/vividas: forward errors from track_header()
[21:19:45 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:c74712dae39c: avformat/vividas: Check that value from ffio_read_varlen() does not overflow
[21:19:47 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/4.2:d09370b06088: avcodec/hnm4video: Forward errors of decode_interframe_v4()
[21:20:15 CEST] <taliho> durandal_1707: thanks for looking over the code. maybe i'll try to ping some of the maintainers if i don't get a reply 
[23:29:05 CEST] <kierank> durandal_1707: what do you think of michaelni response?
[23:29:27 CEST] <kierank> michaelni: why is having access to public samples server a "security risk"
[23:30:18 CEST] <durandal_1707> you should not ever question leader  opinion
[23:37:32 CEST] <michaelni> kierank, there are many other things on the same server
[23:37:55 CEST] <kierank> surely if someone has git push access there is worse they can do
[23:41:44 CEST] <kierank> michaelni: can you give durandal_1707 access to security and to uploads
[23:42:31 CEST] <kierank> he is both cia and fsb spy
[23:42:34 CEST] <kierank> so it's fine
[23:43:57 CEST] <durandal_1707> i think i have access to uploads already
[23:44:21 CEST] <durandal_1707> unless i was removed
[00:00:00 CEST] --- Mon Aug  5 2019