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

[burek]

[00:15:08 CET] <Chloe> wm4: one issue I found with WSL was that if I compile using it then it can freeze up the entire OS until make is completed, whereas msys2 doesnt do this. I wonder why this is
[00:18:01 CET] <wm4> maybe the windows scheduler is bad
[02:00:43 CET] <rcombs> wm4: what happened to your videotoolbox threading fix anyway
[03:10:35 CET] <wm4> threading with videotoolbox is still pretty broken but I don't give a shit
[03:39:40 CET] <jamrial> wm4: was that necessary?
[03:39:57 CET] <wm4> what?
[03:41:23 CET] <jamrial> your reply in the ml
[03:41:32 CET] <jamrial> it's pointlessly aggressive
[03:42:44 CET] <wm4> the reply to the post that michaelni can't maintain hevc because we don't want half of the code to be logging of obscure failure cases?
[03:43:03 CET] <jamrial> yes
[03:43:54 CET] <jamrial> he agreed to remove it. why not leave it at that?
[03:44:11 CET] <wm4> well he's been asked multiple time to cut those log messages down, but he keeps doing it, so whatever
[03:44:36 CET] <jamrial> also, i find it curious that this kind of error log is so disliked when cbs reports the exact same error for every single value, not just a few
[03:45:54 CET] <jamrial> i understand disliking the logs he tried to add reporting values from internal calculations, but reporting an out of range value as defined in the spec?
[03:46:54 CET] <wm4> I'd probably agree if there were actual files in the wild that had this problem, rather than just another made up file from fuzzing
[03:47:39 CET] <jamrial> you know that even the conformance sample suite actuall has values with out of range values, right?
[03:47:48 CET] <jamrial> eventually supperseded, yes, but still, they exist
[03:48:45 CET] <wm4> so why did nobody care about that so far
[03:49:59 CET] <jamrial> well, nobody found this one buggy sample in our suite because our hevc parser just didn't do range checks. until i tried to add a cbs test using it, and that one did complain about it
[03:50:24 CET] <jamrial> then jkqxz dug a bit then found it was eventually superseeded because of said wrong value
[03:50:58 CET] <wm4> there's still no problem with exiting without logging
[03:51:17 CET] <wm4> there are far trickier things in the ffmpeg API that come with no logging to help debugging them
[03:51:53 CET] <wm4> and we don't want to log every branch that's ever taken, right? (that would happen if this were consequently done)
[04:13:33 CET] <rcombs> that sounds like something we call a "debugger"
[17:03:46 CET] <wm4> such a garbage API... the http protocol has a timeout in microseconds protocol option, while the rtsp protocol has an option with the same name that means something else and is in seconds
[17:03:58 CET] <JEEB> yup
[17:04:02 CET] <JEEB> AVOptions for everyone!
[17:04:05 CET] <wm4> what the fuck is consistency?
[17:04:55 CET] <BtbN> There should be some document somewhere stating which units to expect in options
[17:05:17 CET] <BtbN> so you only ever use seconds or something, and add respective suffixes if that would end up horrible
[17:06:40 CET] <wm4> also there must be some overflow happening
[17:06:48 CET] <wm4> BtbN: well it does?
[17:06:52 CET] <wm4> it's still shit inconsistent
[17:07:46 CET] <atomnuker> wm4: its either inconsistent avopts or more fields in avformatcontext
[17:08:08 CET] <wm4> seems like you're part of the problem
[17:08:14 CET] <wm4> "just do bullshit who cares"
[17:08:46 CET] <nevcairiel> atomnuker: or you know, you could just make them consistent
[17:09:21 CET] <SortaCore> yea, the timeout in rtsp was a dud
[17:09:31 CET] <SortaCore> for one stream it just never finished attempting to connect
[17:09:53 CET] <atomnuker> nevcairiel: can't, they'd have to go through regular deprecation for anything non experimental as far as I know
[17:10:09 CET] <SortaCore> you can use the interrupt callback, but then it's set in the underlying tcpcontext, which means you either got to memory-hackery a reset for it, or create a more complicated callback
[17:10:29 CET] <atomnuker> wm4: I care, that's why I suggest people to use already existing names for avopts
[17:10:53 CET] <wm4> atomnuker: did you realize the problem?
[17:11:03 CET] <wm4> the avoptions use the same name, but different units
[17:11:05 CET] <SortaCore> he did, he mentioned units
[17:11:19 CET] <atomnuker> I thought it was different everything, nvm then
[17:11:21 CET] <SortaCore> *cough*
[17:11:42 CET] <SortaCore> "<@BtbN> There should be some document somewhere stating which units to expect in options"
[17:12:03 CET] <SortaCore> altho, you could cover that in the option descriptions
[17:12:19 CET] <SortaCore> now it's time to move ffmpeg to std::chrono
[17:12:32 CET] <nevcairiel> it would still be bad practice to have different units on options with the same name
[17:12:34 CET] <wm4> and something in this horrible shitmess applies timeouts differently
[17:12:45 CET] <wm4> so specifying a timeout of 6 seconds aborts immediately
[17:15:09 CET] <wm4> probably some overflow undeed
[17:15:13 CET] <wm4> *indeed
[17:24:02 CET] <wm4> oh fucking lol
[17:24:27 CET] <wm4> it fails with rtsp because merely setting the timeout makes it set RTSP_FLAG_LISTEN
[17:27:27 CET] <SortaCore> *gestures at his messages at 9 mins past*
[17:27:58 CET] <wm4> SortaCore: sigh
[17:28:11 CET] <wm4> SortaCore: it fucking is described in the options descripotions
[17:28:16 CET] <SortaCore> yea, it's useless :p
[17:28:26 CET] <wm4> SortaCore: what am I supposed to do as API user, parse the descriptions?
[17:30:08 CET] <wm4> the rtsp user agent option is also different from http, are you shitting me
[17:30:51 CET] <SortaCore> lol yea
[17:31:09 CET] <SortaCore> don't worry, I'm with you on this one, I've also experienced the useless timeout
[17:37:16 CET] <wm4> user responded to my WONTFIX: "I understand completely, I've looked through the ffmpeg source before and ... I suppose garbage covers it :P"
[17:37:22 CET] <wm4> I'm glad some users are so understanding
[18:17:39 CET] <rcombs> what's anyone supposed to do with AV_PKT_DATA_MASTERING_DISPLAY_METADATA, anyway
[18:19:36 CET] <atomnuker> use the max luminance for hdr, and if really advanced, use the white point and the rest to correct color
[18:20:44 CET] <wm4> normally it gets transfered to the AVFrame side data
[18:21:00 CET] <nevcairiel> this one doesnt really exist on packets anyway
[18:21:05 CET] <nevcairiel> but as stream side d ata
[18:21:24 CET] <nevcairiel> although i suppose it could
[18:21:43 CET] <wm4> well stream side data uses the AV_PKT_ enum anyway
[18:22:02 CET] <wm4> and there's some mechanism to attach stream side data to packets (not sure if it even works)
[18:23:19 CET] <rcombs> if you're using lavf, are you supposed to feed it to a platform decoder
[18:23:27 CET] <rcombs> or is it just always in SEI
[18:23:53 CET] <nevcairiel> the stream sidedata can come  from webm/matroska, ie. vp9 hdr, because it has no such SEI
[18:23:59 CET] <nevcairiel> youtube hdr uses it
[18:24:09 CET] <rcombs> ahh
[18:24:23 CET] <nevcairiel> has the same content as the SEI data though, so  same interpretation
[18:24:28 CET] <rcombs> does HEVC ever not have it in SEI?
[18:24:37 CET] <nevcairiel> who knows
[18:24:45 CET] <nevcairiel> someone could put it in the container if they wanted to
[20:44:22 CET] <cone-091> ffmpeg 03Josh Allmann 07master:ee88f31d34c8: libavformat/rtmpproto: Plug leak if sending bytes read report fails.
[21:24:08 CET] <durandal_1707> atomnuker: why atrac9 is not complete still..?
[21:27:39 CET] <atomnuker> because vulkan's almost complete
[21:28:51 CET] <BtbN> https://developer.nvidia.com/sites/default/files/akamai/gameworks/VulkanDevDaypdaniel.pdf Vulkan Slides from nvidia. From 2016. Claiming CUDA<->Vulkan interop.
[21:30:12 CET] <BtbN> https://github.com/KhronosGroup/Khronosdotorg/blob/master/api/vulkan/faq.md#vendor-nvidia
[21:32:19 CET] <atomnuker> the weird thing is that nvidia also have an extension for external memory importing but I don't think its used for anything
[21:34:03 CET] <BtbN> Isn't that even a KHR extension by now?
[21:34:14 CET] <BtbN> And it can be used for various D3D/DirectX Surfaces
[21:34:18 CET] <BtbN> but not CUDA, yet
[21:34:26 CET] <BtbN> I think it will eventually, but they take their damn time
[21:34:42 CET] <BtbN> And I kinda refuse to duplicate filters to CUDA just because nvidia has no interop
[21:34:49 CET] <philipl> BtbN: I saw those slides before. It's actually very carefully ambiguous
[21:34:56 CET] <atomnuker> https://developer.nvidia.com/sites/default/files/akamai/gameworks/VulkanDevDaypdaniel.pdf
[21:35:00 CET] Last message repeated 1 time(s).
[21:35:22 CET] <BtbN> That does not look ambigous to me at all
[21:35:46 CET] <philipl> BtbN: huh, true. I saw different slides.
[21:36:15 CET] <philipl> My conspiracy theory is that it's being held up by the same people who wanted to make sure OpenCL wasn't really usable on nvidia.
[21:37:22 CET] <philipl> BtbN: I found an OpenGL shader implementation of yadif today. Not much use for an ffmpeg filter. Could be useful in mpv except it's GPL and not LGPL.
[21:37:39 CET] <atomnuker> VK_KHR_external_memory and VK_NV_external memory, those are 2 separate extensions
[21:38:00 CET] <BtbN> I think it works like it did at OpenGL
[21:38:04 CET] <philipl> It started as an NV and was then promoted
[21:38:12 CET] <BtbN> And it transistion from vendor extension to KHR to base
[21:38:26 CET] <philipl> Yeah, so vulkan can import but there's no export on the cuda side
[21:38:34 CET] <BtbN> that doesn't matter
[21:38:55 CET] <BtbN> Mapping CUDA memory to a Vulkan texture is exactly what we need
[21:39:08 CET] <BtbN> so Vulkan filters can operate on CUDA frames without copying
[21:39:16 CET] <philipl> When I say 'export', I mean you can't pass a cuda memory pointer and have it work.
[21:39:27 CET] <philipl> So you need to something on the cuda side to make it work, and that part is what's missing
[21:39:30 CET] <BtbN> Once CUDA is implemented, it will work like that
[21:39:51 CET] <BtbN> You will most likely just hand a devptr to Vulkan, and it will make it into a generic memory object
[21:40:06 CET] <philipl> That sounds useful; they'll probably do something else.
[21:40:20 CET] <BtbN> It works like that for D3D stuff
[21:41:20 CET] <philipl> One can hope.
[21:41:50 CET] <philipl> So where does that leave us? Pester our nvidia contacts?
[21:43:40 CET] <BtbN> I don't think they can help much. The Interop will happen eventually
[21:43:44 CET] <BtbN> might just take a few more years
[21:46:50 CET] <atomnuker> at least nvidia are fast with their drivers to implement the latest extensions
[21:47:35 CET] <atomnuker> though its questionable how usable they are as no one's ever tested them
[21:48:23 CET] <atomnuker> until me no one wrote anything to use the ycbcr vkformats I think
[21:51:54 CET] <Chloe> wm4: why cant we just depend on a net library? isnt that how you fix it in mpv
[21:52:09 CET] <Chloe> i remember someone saying something about how libcurl fixed things
[21:52:26 CET] <wm4> yeah ffmpeg could probably just use libcurl, I don't know
[21:53:01 CET] <wm4> probably wouldn't get rid of all network code, since there are plenty of things that need raw tcp or udp
[21:53:26 CET] <Chloe> but a majority of the annoying net code?
[21:53:35 CET] <Chloe> or would it just not be useful overall
[21:55:39 CET] <wm4> if you didn't get it yet, ffmpeg is a NIH shitshow
[21:56:57 CET] <Chloe> It doesnt need to be
[21:57:06 CET] <thardin> no no let's reimplement an http client but poorly and also with lots of segfaults
[21:57:59 CET] <thardin> lavc is the good part
[22:06:46 CET] <Chloe> was the ffm muxer removed?
[22:09:48 CET] <jamrial> yes
[22:16:16 CET] <atomnuker> Chloe: I think tmm1_ had some complaints with using libcurl in lavf
[22:32:08 CET] <jamrial> jkqxz: were you planning on adding sei support to cbs_h265? i can help you with the boring work of defining some of the types if you want
[23:04:34 CET] <wm4> heh ce seems really annoyed at me, that's nice
[23:07:00 CET] <wm4> is asking me to go away every dozen threads a CoC violation yet?
[23:09:28 CET] <Chloe> wm4: we dont have a CoC really, just some guidelines which dont really mean much
[23:11:09 CET] <wm4> I'm pretty sure outright harassing me is even violating the lesser CoC we actually have
[23:14:21 CET] <Chloe> wm4: I mean 'Be friendly and respectful towards others and third parties.', but we dont have anything which says what should happen if someone doesnt follow it, so it's pretty useless.
[23:14:47 CET] <wm4> yes
[23:14:53 CET] <wm4> it's unenforced
[23:15:02 CET] <wm4> otherwise ce would be long gone
[23:15:23 CET] <BtbN> It's getting pretty ridiculous, yes
[23:15:25 CET] <wm4> (carl eugen hoyos, for the record)
[23:16:19 CET] <wm4> he also cites me for attacking another dev today, I wonder what that refers to
[23:16:37 CET] <wm4> because I was disapproving of michaelni starting another huge bikeshed for a simple fix?
[23:16:38 CET] <atomnuker> I can't see how you think michaelni tried to drive the discussion into a bikeshed though, he just offered an advice
[23:16:56 CET] <wm4> (and what was the second time)
[23:17:39 CET] <wm4> atomnuker: well he clearly asked for changing the rtsp option to take a string or something
[23:17:57 CET] <wm4> I don't see any "advice" (as in optional and not part of the patch review) there
[23:19:40 CET] <wm4> also michaelni harassed me a lot in the past (like making me go through all that pointless crap when getting rid of the side data merging, or the AVFRamer.opaque_ref), so it's not like this is an isolated thing
[23:19:43 CET] <wm4> so fucking excuse me
[23:20:26 CET] <BBB> wm4: Im sorry you have to go deal with his behaviour
[23:20:33 CET] <BBB> I think a lot of us just give up
[23:20:47 CET] <BBB> :(
[23:21:16 CET] <Chloe> I mean, how do you deal with something like this? What would a consequence be?
[23:21:40 CET] <Chloe> If we can figure that out, then we can figure out how to put it in place, and then start fixing everything.
[23:22:16 CET] <atomnuker> wm4: its an opinion, its not like he specifically requested you to change it, if you disagree just explain why you disagree and he'll either drop it or then go and bikeshed
[23:23:07 CET] <atomnuker> immediately disregarding someone's opinion is rude
[23:24:29 CET] <wm4> I'Ve also asked michaelni plenty of times he should make it clearer whether something is just advice or general thinking, or a patch review change request
[23:25:04 CET] <wm4> on that topic, I also think an integer timeout in microseconds is good enough, rather than some overnegineered string+units thing
[23:26:07 CET] <wbs> wm4: if I'm understanding it right (I didn't look close) something like that already exists, if you just set the right avoption type
[23:26:31 CET] <wm4> yes, but this change is to harmonize behavior with the http protocol, not to rewrite everything
[23:46:56 CET] <cone-091> ffmpeg 03Martin Storsjö 07master:85e10c0a9321: intreadwrite: Use __unaligned in MSVC for ARM64 as well
[23:46:57 CET] <cone-091> ffmpeg 03Mark Thompson 07master:8e9be8ffba03: Merge commit '85e10c0a9321bfe0d2afe0f3983ab6a8df6e3fba'
[23:47:52 CET] <jamrial> <+wm4> also michaelni harassed me a lot in the past (like making me go through all that pointless crap when getting rid of the side data merging
[23:48:02 CET] <jamrial> can you drop that already? it was not pointless
[23:48:22 CET] <jamrial> i was careless and did a merge wrong, and google came out of the woodworks because i broke chromium
[23:48:41 CET] <jamrial> the abi concerns had a reason
[23:49:34 CET] <cone-091> ffmpeg 03Josh Allmann 07master:a2a9e4eea0e4: rtmp: Plug leak if sending bytes read report fails.
[23:49:35 CET] <cone-091> ffmpeg 03Mark Thompson 07master:b855b570c811: Merge commit 'a2a9e4eea0e4fde2ed8d3405b4f33f655b600c2d'
[23:49:44 CET] <jamrial> the bump got rid of it all, so leave the past in the past, please
[23:50:49 CET] <wm4> making it part of the bullshit was pretty much bullshit, but even beyond that it took tons of flaming to make the change _at_all_
[23:51:21 CET] <wm4> so, sorry if I base my current behavior on experiences in the past (it's called learning)
[23:51:32 CET] <cone-091> ffmpeg 03Ruiling, Song 07master:559370f2c451: qsv: Skip the packet if decoding failure
[23:51:33 CET] <cone-091> ffmpeg 03Mark Thompson 07master:04e4ab44d7c5: Merge commit '559370f2c45110afd8308eec7194437736c323d4'
[23:52:59 CET] <jkqxz> Apply SIGPIPE ignoring?
[23:53:30 CET] <jkqxz> Hmm, I did say tomorrow almost a week ago.
[23:53:33 CET] <jkqxz> Sounds like yes.
[23:55:25 CET] <iive> jkqxz, the argument against it, is that signal handling might have unknown effects on unknown architecture. So the only way to know what and where is to apply it.
[23:57:06 CET] <jkqxz> We know exactly what effect ignoring it will have (the write will get an error and we can act sensibly, rather than the process being immediately hard-killed).
[23:57:29 CET] <jkqxz> I'm much less sure about edge cases if we catch the signal and do something.
[23:57:37 CET] <iive> jkqxz, that's what we want it to do. Apply it, and handle the bugs if they are ever found.
[00:00:00 CET] --- Fri Jan 26 2018