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

[burek]

[00:26:59 CEST] <cone-164> ffmpeg 03Michael Niedermayer 07master:b6b9ac5698c8: avcodec/vp56rac: delay signaling an error on truncated input
[00:27:00 CEST] <cone-164> ffmpeg 03Michael Niedermayer 07master:0e4a0e962cb0: avcodec/mpeg4videodec: Fix integer overflow in mpeg4_decode_studio_block()
[00:27:01 CEST] <cone-164> ffmpeg 03Michael Niedermayer 07master:ec749ed2225e: avcodec/aacps: Fix integer overflows in hybrid_synthesis()
[00:27:02 CEST] <cone-164> ffmpeg 03Michael Niedermayer 07master:f1192736494a: avcodec/takdec: Fix integer overflow in decorrelate()
[00:27:03 CEST] <cone-164> ffmpeg 03Michael Niedermayer 07master:e1255789941d: avcodec/alsdec: Check k from being outside what our implementation can handle
[00:27:04 CEST] <cone-164> ffmpeg 03Michael Niedermayer 07master:39ff027fd811: avcodec/mpeg12enc: Add FF_CODEC_CAP_INIT_CLEANUP
[00:27:05 CEST] <cone-164> ffmpeg 03Michael Niedermayer 07master:b94cf549e2d9: avcodec/htmlsubtitles: Avoid locale dependant isdigit()
[01:06:55 CEST] <jamrial> Lynne: fate-checkasm-opusdsp is failing on win64
[01:07:25 CEST] <jamrial> and someone on the mailing list reports the same for his linux and mac systems
[01:07:48 CEST] <philipl> Lynne: I will look.
[01:13:05 CEST] <Lynne> jamrial: do you have links to the logs?
[01:13:29 CEST] <jamrial> what logs?
[01:14:03 CEST] <jamrial> if you mean the win64 fate clients, they haven't run in almost a month
[01:14:12 CEST] <jamrial> i just tried on my rig and saw the test segfaulted
[01:16:32 CEST] <jamrial> Lynne: https://pastebin.com/fqQx53gb
[01:16:45 CEST] <jamrial> looks like garbage on the upper 32 bits of grps
[01:17:47 CEST] <jamrial> yeah, clearing the high bits fixes it
[01:18:09 CEST] <jamrial> now i get comparison failures with the float values instead
[01:21:04 CEST] <jamrial> fixed that too. i had missed one gpr
[01:21:11 CEST] <jamrial> will send a patch in a minute
[01:27:03 CEST] <Lynne> was it an alignment issue?
[01:28:00 CEST] <jamrial> no, it was all 32bits arguments on 64bit gprs
[01:32:43 CEST] <Lynne> jamrial: patch LGTM
[01:33:12 CEST] <jamrial> Lynne: i could also replace the lea with shl + add
[01:33:21 CEST] <jamrial> it seems to be one byte shorter
[01:33:35 CEST] <Lynne> how did it ever run and not crash until now? I can almost believe no one uses the opus decoder, but that's still somewhat of a stretch
[01:34:02 CEST] <jamrial> because it's only an issue in checkasm
[01:34:07 CEST] <jamrial> it ensures all arguments come from stack
[01:34:40 CEST] <jamrial> in any other situation, both period and len are passed in gprs on win64 ABI
[01:39:22 CEST] <Lynne> ah, good to know. go ahead and replace the lea, its actually 2 bytes less apparently
[01:43:29 CEST] <cone-164> ffmpeg 03James Almer 07master:80444e23ac29: x86/opusdps: clear the high bits from some gprs
[01:53:06 CEST] <cone-164> ffmpeg 03James Almer 07master:1faedb9a119a: x85/opusdsp: enable the functions on all FMA3 CPUs
[03:19:30 CEST] <Lynne> 600 lines later and a lot of refactoring vf_overlay_vulkan works
[03:20:08 CEST] <Lynne> and I still don't have a solution to the chicken and egg semaphore issue other than maybe NIHing refcounting
[03:21:47 CEST] <Lynne> guess I'll have do it; philipl hold off on checking till tomorrow's patches, the freeze bug will probably get fixed by this
[03:23:10 CEST] <Lynne> can I just not care at all about orphaned CUexternalSemaphores?
[03:23:19 CEST] <BBB> "the test fails; let's remove it, here's a patch"
[03:23:21 CEST] <BBB> hm...
[03:23:35 CEST] <Lynne> which don't have a backing vksemaphore allocated anymore?
[03:24:09 CEST] <Lynne> otherwise I'll need to expose a public api to destroy semaphores which I really do not want
[03:24:51 CEST] <jamrial> BBB: it makes fate succeed. doesn't it count as a fix? :p
[04:34:30 CEST] <BBB> jamrial: rm -fr / also makes fate succeed
[04:55:08 CEST] <philipl> Lynne: I will hold off looking. If you can see it stop hanging by not freeing the CUexternalsemaphores, that's a good datapoint.
[04:56:38 CEST] <philipl> but you shouldn't be freeing it until the avframe is freed, and if that is still vulnerable to hanging, that means you're freeing the avframes when they might still be being used on the vulkan side (assuming a semaphore wait is still in the queue)
[04:57:37 CEST] <philipl> I would say you want to lazily export the semaphore on the first cuda export and then leave it until you free the frame. Maybe you are already doing that - I've not read the patch closely enough to map out the lifecycle yet.
[05:09:31 CEST] <philipl> Lynne: maybe you already read it but the docs are explicit: "Any outstanding signals or waits must have completed before the semaphore is destroyed. "
[05:09:36 CEST] <philipl> https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__EXTRES__INTEROP.html#group__CUDA__EXTRES__INTEROP_1g7f13444973542fa50b7e75bcfb2f923d
[05:13:32 CEST] <philipl> looks like your map_from_cuda tries to use a new semaphore each time. So I would switch to re-using the existing semaphore and see if that helps.
[05:17:55 CEST] <cone-190> ffmpeg 03Steven Liu 07master:307e0627dbdc: avformat/hlsenc: merge fmp4 and mpegts segment type m3u8 list AVIOConext
[05:17:55 CEST] <cone-190> ffmpeg 03Steven Liu 07master:5b809a8d4bc8: avformat/hlsenc: print warning at the end when upload the last segment failed
[05:17:55 CEST] <cone-190> ffmpeg 03Steven Liu 07master:9ff8fbda6598: avformat/hlsenc: fix memleak at hls_write_trailer
[05:17:55 CEST] <cone-190> ffmpeg 03Steven Liu 07master:e55018ee110b: avformat/dashdec: add startNumber parser for segmentlist
[06:03:57 CEST] <rcombs> would appreciate some design review on the (very small) patch I just sent; not so much on the 2-line diff, but more on the interaction it's dealing with
[06:04:43 CEST] <rcombs> basically, a lot of QSV code uses resolution values from inside the QSV-specific (but non-opaque) struct we pass around in data[3], rather than AVFrame
[06:05:31 CEST] <rcombs> this has the potential to subtly break a lot of things that assume that setting AVFrame->[width/height] will result in a crop
[06:06:06 CEST] <rcombs> in this case I'm just fixing that when mapping frames in from other hwcontexts, but there are potentially other cases where this could come up
[06:06:28 CEST] <rcombs> so I'm not sure if there's something more general that should be done here, or if there's a better place to put this
[06:08:38 CEST] <rcombs> but maybe there should be an API to update a hardware-API-specific struct from the AVFrame
[06:09:52 CEST] <rcombs> in other news, apparently DXVA requires HEVC surfaces to be aligned to mod-128 on both width and height, which feels ever so slightly excessive
[11:24:37 CEST] <nevcairiel> rcombs: the DXVA HEVC alignment requirement is documented in the DXVA HEVC spec, so yeah, it wants that. Presumably for some coding tools that can theoretically expand that for. For the QSV thing, it  feels rather awkward that QSV would access its own internal stuff instead of our official API, but its QSV, its all sorts of messed up, so its probably fine to just sync them up there
[11:27:26 CEST] <rcombs> nevcairiel: one might argue that the way QSV is integrated is bad
[11:27:36 CEST] <nevcairiel> no way?!?
[11:27:37 CEST] <nevcairiel> :D
[11:27:45 CEST] <rcombs> that the context shouldn't hold a pool of those structs
[11:28:05 CEST] <rcombs> instead just hold a pool of the actual surface pointers, and have code build the struct when needed
[11:28:15 CEST] <rcombs> not sure if that has other implications
[11:28:48 CEST] <nevcairiel> QSV integration was done by some company presumably paid by Intel, they hardly reacted on feedback, took forever to do anything, and disappeared after,  ie. typical hit-and-run contract
[11:28:56 CEST] <rcombs> ah,
[11:29:24 CEST] <rcombs> so yeah it'd probably make more sense for data[3] to just be the surface directly
[11:29:32 CEST] <rcombs> but, ABI
[11:29:52 CEST] <nevcairiel> i mean QSV was largely revised already since those days, but the roots are probably still there
[11:30:55 CEST] <rcombs> this reminds me, is there any higher-level windows framework that handles stuff like scaling, deinterlacing, overlays&?
[11:31:26 CEST] <nevcairiel> you mean other then d3d11 vpp?
[11:31:48 CEST] <rcombs> oh hmm there are apparently some MFTs for that
[11:32:08 CEST] <nevcairiel> MFTs are for apps too lazy to use the APII!
[11:32:12 CEST] <nevcairiel> -I
[11:32:31 CEST] <rcombs> well is there another encode API?
[11:33:07 CEST] <nevcairiel> thats not exactly an encode API, its a generic filtering mechanic that vendors tend to throw an encoder into
[11:35:09 CEST] <nevcairiel> but no, noone has tried to make a generic encode API, probably because encoders are just too different, so the best you can get is a MFT with a generic API but rather encoder-specific options
[11:35:32 CEST] <rcombs> sure, but all major GPU vendors have encoder MFTs accessible via the same API
[11:36:09 CEST] <rcombs> encoders may have different options but ultimately the way you use them is the same, configure options then pass in frames, maybe occasionally set flags on things
[11:37:37 CEST] <rcombs> I've got some code around here for MF encoding but it's not great because it requires copying frames around; I'm wondering if it'd be worth adding a hwcontext (and filters) for that, or if I should keep going with the separate APIs for each vendor on windows
[11:38:53 CEST] <nevcairiel> nvenc and amf are theoretically portable to linux as well (and while qsv may be, you are better off  using vaapi), so it seems advantageous to use those
[11:43:19 CEST] <nevcairiel> nvenc and amf (afaik) also take d3d11 input, unfortunately qsv is a bit broken in that regard (surprise!), so one could expand d3d11 functionality in ffmpeg for a full pipeline
[11:43:35 CEST] <nevcairiel> i've been meaning to work on that for $work, but the project was delayed
[11:43:55 CEST] <rcombs> with d3d11 filtering?
[11:44:18 CEST] <nevcairiel> i was planning on making a scale/deint filter
[11:44:33 CEST] <rcombs> neat
[11:46:01 CEST] <nevcairiel> i do theoretically also need overlay, but i've never used overlay through avfilter and I hear bad things
[11:46:04 CEST] <rcombs> hmm, assuming win7+, is there hardware that supports dxva2 but not d3d11?
[11:46:38 CEST] <rcombs> the biggest issue I have with overlay is that my use-case is bitmap subs and sub2video makes it horrifically expensive
[11:46:42 CEST] <nevcairiel> d3d11 decoding needs win8 to functiona reasonably
[11:46:57 CEST] <rcombs> mmmm, what about filtering?
[11:47:08 CEST] <rcombs> (and is dxva2 decode compatible with d3d11 filtering?)
[11:47:10 CEST] <nevcairiel> the problem with win7 is that it lacks 4:2:0 surface formats
[11:47:17 CEST] <rcombs> um.
[11:47:22 CEST] <nevcairiel> for d3d11
[11:47:47 CEST] <rcombs> what, d3d11.1?
[11:48:01 CEST] <nevcairiel> you can theoretically decode on win7 with d3d11, and then fitler it into rgb, that should work
[11:50:24 CEST] <nevcairiel> but this is the real problem: DXGI_FORMAT_NV12 [...] Direct3D 11.1:  This value is not supported until Windows 8.
[11:51:16 CEST] <rcombs> and it's not in the, uh, "Platform Update"?
[11:51:34 CEST] <nevcairiel> no
[11:51:48 CEST] <nevcairiel> I assume they couldn't change the driver interface to make these available
[11:51:54 CEST] <nevcairiel> or didnt want to, or whatever
[11:52:04 CEST] <rcombs> wonder how much longer I need to care about windows 7
[11:55:01 CEST] <nevcairiel> its end of life in 4 months
[11:55:08 CEST] <nevcairiel> thats always a good argument
[11:56:05 CEST] <nevcairiel> the good thing with these things is that you don't need to kill win7 support, you would only restrict it to software paths or whatever
[11:59:10 CEST] <rcombs> unfortunately they're still a really substantial portion of users, by the look of things
[12:00:16 CEST] <rcombs> but hey maybe that'll drop once it actually EOL's
[12:02:00 CEST] <nevcairiel> unfortunately many people dont really care about the security implications, people still on win7 right now are either too lazy to upgrade, and that won't change en-masse, or they are in the group that would rather still be on windows 2000 or so because it was "simple and easy", and also won't upgrade
[12:02:56 CEST] <nevcairiel> the only group finally moving off will be corporate
[14:10:39 CEST] <Lynne> I really wish mem.h had some talloc-like API
[14:11:25 CEST] <Lynne> anything using vulkan has an extremely dirty valgrind
[15:12:21 CEST] <robUx4> where do I send patches for nv-codec-headers ?
[15:12:43 CEST] <robUx4> the ffmpeg-dev ML ? The unofficial Github https://github.com/FFmpeg/nv-codec-headers ?
[15:13:19 CEST] <jamrial> robUx4: the ffmpeg-dev ml, or just poke philipl and BtbN here
[15:13:34 CEST] <robUx4> ok, the ML will do
[15:53:00 CEST] <BtbN> robUx4, you can also make a PR to the Github mirror, I can pull it from there.
[16:38:32 CEST] <kierank> durandal_1707: https://news.sky.com/story/big-carl-worlds-biggest-crane-begins-work-at-hinkley-point-in-somerset-11806956
[18:40:26 CEST] <cone-398> ffmpeg 03Paul B Mahol 07master:b4562301ee44: avfilter/vf_v360: fix M_PI_4 usage consistency
[18:40:27 CEST] <cone-398> ffmpeg 03Paul B Mahol 07master:801fd6e41031: avfilter/vf_v360: fix errors is comments
[18:40:28 CEST] <cone-398> ffmpeg 03Paul B Mahol 07master:24d4eea921aa: avfilter/vf_v360: fix setting default height for stereographic
[20:13:38 CEST] <cone-398> ffmpeg 03Paul B Mahol 07master:e1dd355b3d8b: avfilter/vf_v360: add dfisheye output
[21:27:59 CEST] <linuxjunkie999> how granular is the aarch and cpu configure variables and where do I get a list of what ffmpeg configure recognizes for those variables?
[21:28:40 CEST] <tmm1> look at the configure script?
[21:29:35 CEST] <linuxjunkie999> thanks 
[22:08:26 CEST] <Lynne> philipl: you can take a look at https://0x0.st/zyzu.patch https://0x0.st/zyzS.patch now
[22:09:31 CEST] <Lynne> I redid the syncronization system, now everything is done through vkevents, and semaphores are only used once to wait and then deleted
[22:10:23 CEST] <Lynne> the cuimportedsemaphore is left orphaned until the frame is deleted or reused
[22:11:25 CEST] <Lynne> but it still hangs at context pushes/pops, as if the semaphore isn't getting signalled
[22:38:59 CEST] <Lynne> I'm bored now so I'm going to write a raindrops filter for our deraindrop filter to have something to fail at removing
[23:03:18 CEST] <philipl> Lynne: I'll look but it'll be a couple of days before I get a chance. Sorry it can't be sooner.
[00:00:00 CEST] --- Fri Sep 13 2019