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

[burek]

[01:12:25 CEST] <cone-544> ffmpeg 03James Almer 07release/4.2:c1dc4d2d501c: avcodec/h2645_parse: zero initialize the rbsp buffer
[03:33:26 CEST] <cone-544> ffmpeg 03OvchinnikovDmitrii 07master:f8ad2ddd7a51: libavcodec/amfenc: Vulkan initialization support for encoder.
[09:18:01 CEST] <JEEB> wbs: so for current end point of a track in movenc: is it track->end_pts or (track->start_dts + track->duration) ? I seem to have utilized the first one first, but now I've got at least one case where latter seems to be the correct value :)
[09:18:48 CEST] <JEEB> right now for testing I've got FFMAX between those two, but I wonder if I can just use the latter
[09:37:10 CEST] <wbs> JEEB: it's been a few years since I've touched that, but I think start_dts + duration is the one used for fragment stuff
[09:37:39 CEST] <wbs> as pts is just done with offsets on top of the dts, but dts is used for building the structure of the fragments etc
[09:41:15 CEST] <JEEB> yea
[09:42:23 CEST] <JEEB> not sure why on a subtitle track those two weren't the same here (will still have to re-check), but the start_dts + duration seemed to give the correct value
[09:42:52 CEST] <JEEB> this is mostly utilized when a padding packet has to be generated and thus the start of it is at the end of the previous fragment :)
[09:45:12 CEST] <JEEB> here's what the monstrocity currently looks without/with fragmentation from the debug logs I'm currently keeping: http://up-cat.net/p/6bf94b85 http://up-cat.net/p/d8fc4f9e
[09:45:31 CEST] <JEEB> will have to polish this up a bit and then should be ready for initial reviews
[09:47:51 CEST] <wbs> sorry, might look later. no time and not enough attention at the moment
[09:48:12 CEST] <JEEB> yea, it's OK :) that's just logs
[09:48:25 CEST] <JEEB> to see how stupid some of that whole queueing business is
[09:48:40 CEST] <JEEB> (but since the spec wants squashing there's not much more you can do)
[11:11:51 CEST] <mostynb> i wonder if patches that add SPDX license identifiers would be accepted, to make automated license checking simpler? an example source file comment would look like this (in whichever commenting style is already used in a given file): // SPDX-License-Identifier: LGPL-2.1-or-later
[11:16:30 CEST] <JEEB> mostynb: I think it'd mostly depend on where those would be useful
[11:16:48 CEST] <JEEB> we already have the license at the top of most files where fuzzy logic can grab it
[11:18:43 CEST] <mostynb> JEEB: the actual license is good for humans (well, sorta) but not so good for automated license checking tools
[11:19:21 CEST] <JEEB> sure
[11:19:44 CEST] <mostynb> for example if you wanted to get a list of all the GPL files in ffmpeg, a line like this would make this really easy to do
[11:20:43 CEST] <rcombs> that's already not especially difficult, since they all have a pretty distinct chunk of, well, GPL at the top
[11:21:39 CEST] <nevcairiel> in fact we have a test that ensures that license headers are consistent, so it would be possible to use a tool for th at, even if slightly more wordy then the  header string
[11:22:29 CEST] <JEEB> yea
[11:22:40 CEST] <mostynb> rcombs: being consistent is difficult, especially with automated tools. there are several variations of licenses, formatting can be different, comment style can be different, there can be additional exceptions added etc etc
[11:23:03 CEST] <mostynb> these SPDX headers are a standardised effort to make this easier
[11:24:37 CEST] <rcombs> BtbN: could you test to see if it works with a 32-bit build for you
[11:24:39 CEST] <mostynb> nevcairiel: such a tool would be ffmpeg-specific though, and therefore less likely to be used
[11:25:20 CEST] <BtbN> rcombs, I'll need to get a 32bit cross toolchain, and can't use WSL for that. So yes, but it might take a moment.
[11:25:46 CEST] <rcombs> I'm building with a 32-bit install of msys2
[11:25:58 CEST] <rcombs> (and do the 64-bit build with a 64-bit install)
[11:26:05 CEST] <BtbN> But yes, due to the limited address space with 32bit applications, the CUDA CUdevptr Unified Memory stuff is VERY limited
[11:26:27 CEST] <BtbN> I can totally see it running out of mappable address space rather quickly
[11:26:59 CEST] <rcombs> it looks like my 64-bit issues were due to something dopey on my end around logging (not entirely sure what but it only happens at -v trace so w/e), but I'm still seeing the crash in 32-bit
[11:28:34 CEST] <rcombs> I'm seeing this crash just with 720p after 2 frames, that seems at least a _bit_ quick
[11:29:20 CEST] <BtbN> There is only a few 100MB of mappable address space with 32bit
[11:30:23 CEST] <BtbN> Also, from Nvidias docs: "Deployment and execution of CUDA applications on x86_32 is still supported, but is limited to use with GeForce GPUs."
[11:30:33 CEST] <BtbN> https://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html#x86-32-bit-support
[11:31:03 CEST] <BtbN> So your "Operation not supported" might very well be the driver telling you to go use 64bit on your Quadro
[11:31:25 CEST] <BtbN> Or "Not Implemented" or what it was
[11:32:29 CEST] <rcombs> I was getting that on 64-bit
[11:32:36 CEST] <rcombs> the 32-bit build crashes
[11:32:52 CEST] <rcombs> but hmm, I _do_ only see the crash when I have a cuda filter in the chain
[11:36:12 CEST] <rcombs> I guess I'll look into shipping a 64-bit build; it's just a massive PITA on windows for a whole bunch of reasons
[11:36:32 CEST] <rcombs> like the user having to select which version they want, installer/updater stuff, upgrade path&
[11:37:11 CEST] <mostynb> nevcairiel: where can i find the license consistency test that you mentioned?
[14:08:16 CEST] <BtbN> philipl, I wonder if we should revive atomnukers old Vulken hwcontext stuff?
[14:08:33 CEST] <BtbN> It might be worthwhile to have it. It had _a lot_ of discussion. Over a year ago, but was never merged.
[15:18:11 CEST] <kierank> durandal_1707: "Fulfills precision requirements outlined in the official SMPTE specs"
[15:18:17 CEST] <kierank> mainconcept is trolling us over prores
[15:26:30 CEST] <durandal_1707> kierank: where?
[15:27:07 CEST] <kierank> email
[15:29:48 CEST] <durandal_1707> i received no such mail
[15:31:56 CEST] <kierank> I forwarded
[15:34:37 CEST] <durandal_1707> kierank: so buy/use it
[15:34:42 CEST] <kierank> LOL
[15:34:50 CEST] <kierank> I don't care for prores
[16:33:12 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:1232e67b16dd: avfilter/af_compand: change error condition into warning
[16:33:13 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:d8410e9cf9db: avformat/dhav: always initializer ret
[16:33:14 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:d063f13700aa: avcodec/tiff: add missing break in tiff_decode_tag()
[16:33:15 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:428b4aacb1a9: avformat/mov: improve timecode calculation
[16:33:16 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:ef73ccc2c419: avcodec/h264_refs: do not use invalid mmco values in case of error
[17:21:19 CEST] <philipl> BtbN: I think it's a capability worth having. But I don't have much spare time these days, and I'm sure it would be a slog.
[17:49:58 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:98f5cbcb7db4: avformat/dsfdec: set packet pts/duration/pos correctly
[17:49:59 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:9606e4b6e68d: avcodec/dsddec: add slice threading support
[17:50:00 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:330ba8d537b4: avcodec/dsd: use uint8_t instead of unsigned char
[18:02:18 CEST] <kierank> jdarnley_obs: just fyi someone has sent v210 patches
[18:04:17 CEST] <BradleyS> thanks for pushing the amf/vulkan patch philipl
[18:04:22 CEST] <philipl> np
[18:04:35 CEST] <philipl> Thanks for reminding me it was still an open issue
[18:09:39 CEST] <J_Darnley> thanks
[18:14:47 CEST] <J_Darnley> i see they removed something I think I added for assembly reasons but I don't really remember
[18:20:30 CEST] <cone-980> ffmpeg 03Limin Wang 07master:ffd65c8862e1: lavf/dump: dump the vbv_delay with N/A instead of 18446744073709551615
[20:14:20 CEST] <tmm1> jkqxz: is there any way to create a dummy drm hwaccel device on the cli?
[20:15:21 CEST] <jkqxz> -init_hw_device drm:/dev/dri/card0
[20:16:51 CEST] <jkqxz> philipl:  Is there any resolution to the problem with the multiple-plane formats in Vulkan not actually being supported properly by any drivers?
[20:18:10 CEST] <jkqxz> That seemed like the ugliest problem blocking stuff last time.  If it hasn't improved then using the OpenCL approach of handling each plane separately is an alternative.
[20:21:08 CEST] <Lynne_> jkqxz: all platforms support it now, including amd - https://vulkan.gpuinfo.org/displayreport.php?id=6699#formats
[20:21:28 CEST] <Lynne_> BtbN: I worked on the hwcontext until 2 weeks or so ago when I lost all motivation to do anything
[20:22:14 CEST] <Lynne_> since all my contributions and work were valued less than the opinions of a spammer and a rogue deaf developer
[20:22:48 CEST] <jkqxz> Lynne_:  Does "support" mean they actually work properly?
[20:25:18 CEST] <Lynne_> yes? why wouldn't they work properly?
[20:29:01 CEST] <jkqxz> I may be misremembering, but I think a year ago the Intel driver declared the support but then died randomly trying to use it.
[20:31:24 CEST] <Lynne_> jkqxz: yes, some specific illegal usage of shared memory in shaders made intel die, and it still does
[20:33:47 CEST] <Lynne_> hopefully no one evil will ever figure out its reading from storage-viewed images which don't have the storage flag set
[20:36:33 CEST] <Lynne_> I rewrote the context to split up multiplane images nonetheless, no penalty for doing so, less validator bugs, easier to import, etc.
[20:38:34 CEST] <Lynne_> can't use the builtin yuv conversions, but amd still doesn't support those, and driver dev's understanding of colorspaces is very relative
[21:05:37 CEST] <jkqxz> Probably for the best, then.  Awesome!  Is there anything else to do?
[21:07:52 CEST] <jkqxz> (Excepting "find a sensible way to make shaders for it".)
[21:14:32 CEST] <Lynne_> all the code for writing shaders sensibly was already well written
[21:15:24 CEST] <jkqxz> I mean the compiler.
[21:15:56 CEST] <Lynne_> glslang is available everywhere, and the c++ wrapper isn't big
[21:16:12 CEST] <durandal_1707> so use it?!
[21:17:08 CEST] <Lynne_> all that's left is to move my repo to a windows pc and then throw it all in the "Waste Bin" folder, since I don't have one on linux to perform this symbolic gesture
[21:17:44 CEST] <taliho> Hello, are there any define flags that indicate a system is POSIX compliant. Specifically, I'm trying to infer if errno is available on a particular system for my patch
[21:24:38 CEST] <BBB> #ifdef EINVAL
[21:24:40 CEST] <BBB> ?
[21:24:48 CEST] <BBB> but I think we typically assume these thngs just exist
[21:24:55 CEST] <BBB> also see AVERROR()
[21:31:03 CEST] <J_Darnley> Configure might check and produce HAVE_ERRNO or something
[21:31:04 CEST] <taliho> BBB: ah yes, seems reasonable just to check if that is set. thank you!
[21:31:49 CEST] <taliho> J_Darnley: thanks, I'll do a grep
[21:33:48 CEST] <J_Darnley> ffmpeg.c includes errno.h without anycheck
[21:33:50 CEST] <jkqxz> errno is required by C.  I don't think we can not have it.
[21:35:28 CEST] <J_Darnley> Then there is no need to check
[21:35:55 CEST] Action: J_Darnley has no idea where posix stops and c starts
[21:36:04 CEST] <jkqxz> C only defines a few error codes, so it's possible some particular codes might not be present.  We certainly assume a set of usual ones like EINVAL though.
[21:43:18 CEST] <BtbN> Fun, pre-auth remote code exec flaw in dovecot.
[21:47:40 CEST] <thardin> I warned you about parsing bro
[21:48:00 CEST] <thardin> I told you dog
[21:50:47 CEST] <durandal_1707> Lynne_: i do not get it, what is an issue?
[21:58:20 CEST] <cone-980> ffmpeg 03Thierry Foucu 07master:a80fdbcf1391: lavc/cbs_h2645: Use av_realloc instead of av_malloc
[00:00:00 CEST] --- Thu Aug 29 2019