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

[burek]

[00:29:56 CEST] <kierank> nevcairiel: equally a good c programmer shouldn't necessarily be coding crypto
[00:30:50 CEST] <nevcairiel> they should team up!
[00:43:19 CEST] <philipl> nevcairiel, BtbN: So. What does progress look like on the pix fmt stuff?
[00:43:27 CEST] <philipl> I don't even understand what making a decision looks like.
[00:44:29 CEST] <BtbN> Me neither, and I really don't like this stalemate kind of situation.
[00:50:31 CEST] <jamrial> a vote would solve it, but i don't think enough people care or know about the issue at hand, so the voting could go either way
[00:50:46 CEST] <jamrial> who is against and who is in favor of the new pixfmts currently?
[00:51:01 CEST] <BtbN> I think only carl is against them...
[00:52:51 CEST] <jamrial> well, a vote would probably end in adding the pix fmts winning i guess
[00:53:49 CEST] <jamrial> alternatively, since it's like three devs vs one, you could state that if he doesn't have a valid technical argument against it then he can't block it
[00:54:11 CEST] <cone-907> ffmpeg 03Marton Balint 07master:f099946fafb8: ffmpeg: log corrupted packets and frames
[00:54:15 CEST] <BtbN> Well, there are valid technical arguments against it. But to address them properly is quite a project on its own.
[00:57:09 CEST] <JEEB> yea, adding a whole struct for pixel formats and reworking the renegotiation for that can end up "interesting" :P
[00:57:30 CEST] <JEEB> you can keep the AV_PIX_FMT things for a while as well, but yea. it requires rework of all API clients as well
[01:01:43 CEST] <BtbN> It's just that this is holding up a lot of work... And the alternative to the pixel formats is an enormous mess
[01:02:18 CEST] <JEEB> yes
[01:21:11 CEST] <philipl> Right. Adding a bit depth attribute later doesn't become harder because we added a couple of new px fmts. That's not the hard part.
[01:22:09 CEST] <philipl> And no one is suggesting removing P010 so the argument isn't even consistent.
[01:23:25 CEST] <cone-907> ffmpeg 03Michael Niedermayer 07master:c27c7b49dc00: avcodec/av1_parse: Check obu_size
[02:50:22 CEST] <philipl> BtbN: If you're feeling generous, would you test an mpv change for me? https://github.com/mpv-player/mpv/pull/6170
[12:45:09 CEST] <January> nevcairiel: `WINAPI_FAMILY` is the windows define I should be using?
[12:45:33 CEST] <nevcairiel> #ifdef _WIN32 i guess
[12:46:33 CEST] <BtbN> philipl, I'll see if I can build it easily on Windows
[12:52:01 CEST] <BtbN> Is that still using a copy, or does it make use of actual mapping now?
[12:52:43 CEST] <BtbN> hm, and it's Linux only. I only have Windows machines and headless Linux ones with nvidia. So that makes testing kinda hard.
[12:55:37 CEST] <January> wbs: nice on the windres C wrapper, I completely forgot about it
[12:57:21 CEST] <wbs> January: I didn't remember that we had talked about converting it to C :P but when testing running things on windows this seemed like the least ugly way to fix it
[12:58:12 CEST] <January> wbs: we talked about integrating it directly into LLVM, but a C wrapper is probably just as good
[12:58:53 CEST] <wbs> January: ah, right. integrating it into LLVM would probably be nicer, but also requires more generalized policy about how to find includes and the preprocessor and whatnot
[16:11:25 CEST] <philipl> BtbN: i can't test windows but the adjustments are pretty small. I could put a patch together but you'd need to be prepared to fix it to actually work. :-)
[16:11:45 CEST] <BtbN> Building Vulkan on Windows seems surprisingly annoying
[16:16:32 CEST] <JEEB> yea
[16:16:39 CEST] <JEEB> I remember trying it and giving up after a while :P
[16:51:36 CEST] <jamrial> why not just download the LunarG sdk?
[18:00:23 CEST] <BtbN> jamrial, iirc because it expects MSVC
[18:00:45 CEST] <jamrial> BtbN: i used it to compile vkquake using mingw gcc
[18:01:36 CEST] <JEEB> oh, ok
[18:01:39 CEST] <JEEB> that's better than expected then
[18:04:59 CEST] <BtbN> Now to figure out how mpvs weird build system does things
[18:05:31 CEST] <JEEB> oh waf, the delightful little REDACTED
[18:05:42 CEST] <JEEB> it seems really meta to be honest
[18:06:07 CEST] <JEEB> but in general with mpv it's all about pkg-config and possibly CFLAGS etc
[18:06:08 CEST] <BtbN> I also don't have it installed, and cygwin does not seem to have it.
[18:06:10 CEST] <JEEB> it takes in the env vars
[18:06:18 CEST] <BtbN> pkg-config for the vulkan sdk?
[18:06:31 CEST] <JEEB> for that probably CPPFLAGS/LDFLAGS I guess then?
[18:06:38 CEST] <BtbN> doesn't seem to have a .pc file at least
[18:06:44 CEST] <JEEB> anyways, waf seems to hate bundling
[18:06:54 CEST] <JEEB> so run the bootstrap script with python3 or so
[18:07:01 CEST] <JEEB> that downloads a known waf binary and checks the checksum
[18:07:15 CEST] <JEEB> even the debian mpv package funnily enough has waf itself as a patch
[18:07:31 CEST] <JEEB> even though they noted before they'd be packaging one true version of waf
[18:23:58 CEST] <philipl> BtbN: I appreciate your hard work :-)
[18:30:46 CEST] <BtbN> now ffmpeg doesn't even build for me targetting mingw...
[18:31:08 CEST] <JEEB> reminds me I should update my mingw-w64 headers and CRT
[18:34:50 CEST] <BtbN> my mingw compiler seems to be picking up cygwin headers
[18:35:41 CEST] <philipl> Your regular ffmpeg build can't be used?
[18:43:10 CEST] <BtbN> philipl, no, can't build mpv for cygwin
[18:44:05 CEST] <BtbN> so, now, how do I tell it where my Vulkan SDK is?
[18:46:12 CEST] <BtbN> seems like I don't. The only thing it does is check for vulkan pkg-config...
[18:51:46 CEST] <BtbN> Well, aparently I have to write a pkg-config file
[18:52:40 CEST] <philipl> BtbN: Hmm. I guess the linux pc file comes from the distro packaging...
[18:54:06 CEST] <BtbN> managed to make it build
[18:54:14 CEST] <BtbN> so, how do I test this?
[18:57:44 CEST] <BtbN> hm, it crashes on startup
[19:02:27 CEST] <philipl> BtbN: well, it's not going to do anything relevant unless i/you implement the win32 sharing.
[19:02:42 CEST] <BtbN> well, it starting would be a good first start
[19:02:45 CEST] <philipl> But you could start with just proving that hwdec=nvdec does something on windows.
[19:02:48 CEST] <philipl> yeah.
[19:03:01 CEST] <BtbN> It just crashes with a generic startup error 0x7b
[19:04:31 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:c07bc1d6ee73: avfilter/af_silenceremove: add options to keep min duration of silence
[19:04:32 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:346b23237bdf: avfilter/af_silenceremove: add mode options
[19:04:33 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:a85362368143: avfilter/af_silenceremove: prefer outlink instead of inlink
[19:04:34 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:454ed32d5670: avfilter/af_silenceremove: add options description
[19:04:35 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:631994b62b12: avfilter/af_silenceremove: add enum for detection modes
[19:04:36 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:936376f3f7a8: avfilter/af_silenceremove: use enum for threshold detection modes
[19:04:37 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:e1e6a3121693: doc/filters: update silenceremove documentation
[19:10:06 CEST] <BtbN> no idea what's going on, but the binary is entirely useless
[19:23:16 CEST] <philipl> oh good.
[20:54:19 CEST] <cone-148> ffmpeg 03Aman Gupta 07master:64c50c0e978c: avcodec/cbs_h264: silence errors about end_of_seq nalus
[20:54:20 CEST] <cone-148> ffmpeg 03Aman Gupta 07master:b6c3a0274087: avcodec/cbs: fix crash in sei_pic_timestamp
[20:54:21 CEST] <cone-148> ffmpeg 03Aman Gupta 07master:41ed2c384993: avcodec/cbs: ensure user_data is padded for GBC parsing
[20:59:28 CEST] <JEEB> tmm1: sorry for doing something else than ACK'ing your patches. somehow ended up sidetracked all the while :P
[21:04:19 CEST] <tmm1> n/p, i assume no comments means no one objects