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

[burek]

[00:45:14 CEST] <cone-683> ffmpeg 03James Almer 07master:27df34bf1f7a: avcodec/libvpxenc: fix setting amount of threads used for encoding
[00:45:15 CEST] <cone-683> ffmpeg 03Thomas Volkert 07master:c24d247e2c2c: libavformat: add mbedTLS based TLS
[03:59:30 CEST] <tmm1> jamrial: valgrind test is back to green, thanks for the heads up
[11:22:44 CEST] <akravchenko188> hi guys. I have a question. I try to call av_hwdevice_ctx_create_derived twice with the same params(source device and target type). framework creates two different instances. is it possible to retrieve previously derived context?
[11:26:28 CEST] <jkqxz> It's only connected backwards.  Given "A = new(T1); B = derive(A, T2);", "derive(B, T1);" will return A.
[11:27:36 CEST] <jkqxz> But "derive(A, T2);" will not return B because it doesn't know about B.
[11:28:55 CEST] <jkqxz> I guess connecting forwards would be possible if we recorded that somewhere in I guess AVHWDeviceInternal?  I don't know if that's what you want in all cases, though.
[11:32:26 CEST] <akravchenko188> for example I have pipeline D3D11 decoder(out: d3D11) -> amf filter (in/out: D3D11 frames) -> amf encoder (in: D3D11 frame)
[11:33:20 CEST] <akravchenko188> amf filter and amf encoder could have same hwcontext_amf object, because both requests from the same D3D11 device
[11:39:40 CEST] <akravchenko188> there are possible pipeline in future AMF decoder(out: vulkan frames) -> amf filter (in/out: vulkan frames) -> amf encoder (in: vulkan frames)
[11:43:27 CEST] <jkqxz> It would work if you made derivation work in the opposite direction (e.g. "-init_hw_device amf=a:... -init_hw_device d3d11=d at a -hwaccel_device d ...").
[11:44:27 CEST] <jkqxz> I don't think I'm in favour of making derivation always return the same answer in the forward direction.  It's not at all obvious that two independent components want to be given e.g. the same OpenCL context.
[11:56:49 CEST] <akravchenko188> ok, thanks. if hwcontext_amf used to initialize d3d11, d3d9, opencl... and all others will be derived from, I think this is solution 
[12:23:54 CEST] <akravchenko188> jkqxz: is it true that to derive hwcontext_dxva2 from hwcontext_amf code should be added to hwcontext_dxva2.c or there is the way to do in hwcontext_amf?
[12:33:07 CEST] <akravchenko188> I mean it look like I need to extend hwcontext_dxva2 hwcontext_d3d11va hwcontext_opencl to derive from hwcontext_amf
[12:43:40 CEST] <nevcairiel> i'm not a fan of that idea
[12:50:55 CEST] <cone-862> ffmpeg 03Carl Eugen Hoyos 07master:15f50ccc6f3f: lavc/h264_parse: Remove a superfluous linebreak.
[12:56:12 CEST] <akravchenko188> nevcairiel: why?
[12:56:24 CEST] <nevcairiel> because it spreads vendor-specific stuff in all sorts of generic code
[12:56:50 CEST] <nevcairiel> amf/cuda/qsv stuff should ideally remain self-contained
[12:56:56 CEST] <cone-862> ffmpeg 03Carl Eugen Hoyos 07master:848ce6f0a607: lavc/jpeg2000dec: Use a define to clarify the meaning of a constant.
[12:56:57 CEST] <cone-862> ffmpeg 03Carl Eugen Hoyos 07master:1083808c48cd: lavc/jpeg2000dec: Move a variable declaration closer to its usage.
[12:58:31 CEST] <jkqxz> It probably wants to have functions derive_from and derive_to, like map_from and map_to.
[12:59:24 CEST] <nevcairiel> It also feels like a hack to work around an architecture short-coming
[12:59:42 CEST] <nevcairiel> ultimately from a logical standpoint, you have a ie. d3d11 device and derive the amf context from that device
[12:59:59 CEST] <nevcairiel> you just want it the opposite direction because of architecture, not because its the logical way to do it
[13:01:31 CEST] <jkqxz> I don't think saying that derivation should return the same device on a second call is desirable in general, though.
[13:01:44 CEST] <nevcairiel> how does qsv solve that? i guess it transforms frames into qsv frames as well and replaces the entire hwcontext with a qsv context?
[13:01:57 CEST] <jkqxz> Maybe these components want to take the AMF device explicitly.
[13:02:02 CEST] <nevcairiel> while amf has no "amf frames"?
[13:02:11 CEST] <jkqxz> Yes, qsv has a whole hwcontext implementation with the frames.
[13:02:51 CEST] <jkqxz> That hasn't been so good in general, but it does avoid this problem.
[13:04:49 CEST] <jkqxz> If the AMF device were passed explicitly then you would do "-init_hw_device d3d11=d:... -init_hw_device amf=a at d -filter_hw_device a -vf something..."
[13:08:27 CEST] <akravchenko188> this case filter should check if filter_hw_device has same D3D device with frame context
[13:10:25 CEST] <akravchenko188> I saw some components, they check hwframe context first, and if it NULL it tryes to use hw_device_ctx
[13:14:33 CEST] <akravchenko188> probably we need API to be extended. enumerate active derived contexts from particular device and target type
[13:28:02 CEST] <jkqxz> Maybe a single flag on av_hwdevice_ctx_create_derived(), maybe named AV_HWDEVICE_DERIVE_SHARED, which indicates that it should share the derived context with other callers?
[13:28:53 CEST] <jkqxz> Then keep track of the shared derived device for each type in AVHWDeviceInternal.
[13:53:33 CEST] <akravchenko188> so if you call 1) with shared 2) without shared 3) with shared 4) without shared; then here we have 3 different context objects. 1,3 points to same
[13:54:07 CEST] <akravchenko188> right/
[13:54:08 CEST] <akravchenko188> ?
[13:54:34 CEST] <nevcairiel> that would probably be the idea
[14:09:00 CEST] <jkqxz> Yeah, that's what I was thinking.
[14:20:52 CEST] <akravchenko188> thanks for the idea
[18:12:26 CEST] <durandal_1707> atomnuker: i think i got it, but cant guess what formula to use to rescale final output to match input volume
[20:39:10 CEST] <thardin> michaelni: https://trac.ffmpeg.org/ticket/7209  is clang5 a supported target?
[20:41:03 CEST] <JEEB> clang5 worked for me for android and linux
[20:43:03 CEST] <JEEB> I think my last android build was quite recent master with clang5 in NDK r16
[20:45:51 CEST] <JEEB> I think that was specific to 10.11 macos
[20:46:01 CEST] <JEEB> there's no details on it, though
[20:46:18 CEST] <JEEB> because on macos you have a) the xcode version and b) the OS version
[20:47:20 CEST] <thardin> the syntax looks really unusual
[20:56:53 CEST] <michaelni> clang 3.4-1ubuntu3 and 4 seem working on linux
[20:57:30 CEST] <JEEB> it's a stdlib problem, rather than compiler
[20:57:43 CEST] <JEEB> IIRC we had a report that it works on 10.12+
[20:57:43 CEST] <michaelni> ive just posted a patch that adds () can someone who has this issue test it 
[20:57:47 CEST] <JEEB> with "some" xcode
[20:58:03 CEST] <JEEB> (we never got results on which versions are broken and which aren't)
[21:06:09 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:919e37377a76: avformat/bintext: Reduce detection for random .bin files as it more likely is not a multimedia related file
[21:06:10 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:fe84f70819d6: avformat/mov: replace a value error by clipping into valid range in mov_read_stsc()
[00:00:00 CEST] --- Wed May 23 2018