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

[burek]

[00:01:18 CET] <jkqxz> Ok, thank you.
[00:02:24 CET] <cone-091> ffmpeg 03Mark Thompson 07master:74cf4a75f74e: ffmpeg: Ignore SIGPIPE
[00:15:32 CET] <wm4> on that note, I'm not actually interested in the drama, and if my reply to michaelni was too harsh/unfriendly, I apologize
[00:16:44 CET] <cone-091> ffmpeg 03Jun Zhao 07master:658ac0672f46: lavfi/procamp_vaapi: fix the green video issue if without arguments.
[00:16:45 CET] <cone-091> ffmpeg 03Jun Zhao 07master:4e6e1e5350b7: lavfi/misc_vaapi: use default value setting if without arguments.
[00:26:15 CET] <wm4> huh I didn't realize we have a hls protocol
[00:26:27 CET] <wm4> though it says you should use the hls demuxer instead
[00:26:51 CET] <nevcairiel> yeah its old
[00:27:00 CET] <wm4> it's only 300 lines, wonderfully simple
[00:27:11 CET] <wm4> the demuxer is 2300 lines
[00:27:45 CET] <jamrial> hls demuxer got a lot of development recently. half of those ~2300 lines are probably less than a year old
[00:28:54 CET] <nevcairiel> its simple because it barely supports any of it
[00:31:56 CET] <wm4> sure
[00:32:43 CET] <nevcairiel> thats probably because hls was still relatively simple back in the days
[00:32:53 CET] <nevcairiel> it got expanded with dumb features over the years
[00:33:04 CET] <nevcairiel> what was wrong with mpegts segments, noo, had to force fMP4 into that
[00:33:30 CET] <nevcairiel> fMP4 is only the most hackish streaming format ever invented
[00:33:34 CET] <wm4> Libav's hls.c (basically didn't get any of the recent changes) is only 860 lines
[00:33:45 CET] <wm4> hey still better than dash
[00:33:59 CET] <nevcairiel> dash is xml, thats just always worse
[00:34:00 CET] <wm4> which is a comical xml nightmare
[00:40:28 CET] <klaxa> wow, i didn't know hls got mp4 now
[00:40:49 CET] <klaxa> i've only hacked hls stuff when i didn't even know what it was, like 2014 or so
[00:40:51 CET] <wm4> jkqxz: wow you got the worst possible reply from nicolas
[01:02:22 CET] <nevcairiel> i'm pretty sure he referred to "lurks" instead of the nickname, but who knows at this point, not like thats an offending term in any way
[01:04:30 CET] <wm4> eh
[01:05:15 CET] <nevcairiel> there is even a wikipedia article to explain it =P
[01:05:17 CET] <wm4> anyway trying to figure out what exactly CE is offended by is increasingly a guessing game
[01:06:56 CET] <Chloe> did the irc meeting which occured a while ago help anything?
[01:06:59 CET] <Chloe> we could try do that again
[01:07:38 CET] <jamrial> no, and no
[01:07:50 CET] <nevcairiel> those things barely ever help anything
[01:08:29 CET] <wm4> CE also just mailed me this: Bist Du wirklich so bescheuert?
[01:08:29 CET] <wm4> Die Mailing list admins glauben, Du bist krank und man kann
[01:08:29 CET] <wm4> nichts dagegen tun. Ich glaube das eigentlich nicht, aber nach
[01:08:29 CET] <wm4> diesem Email frage ich mich, ob sie recht haben?
[01:08:54 CET] <wm4> that's pretty funny
[01:08:55 CET] <jamrial> i could use a translation :p
[01:09:06 CET] <nevcairiel> its basically a bunch of insults
[01:09:22 CET] <wm4> it also says the mailing list admins think I'm "sick"
[01:09:30 CET] <wm4> as in sick in the head
[01:11:04 CET] <jamrial> ml admins, as in llogan and Compn?
[01:11:31 CET] <wm4> probably
[01:11:42 CET] <jamrial> also, google translate handled that really well
[01:11:52 CET] <TimothyGu> lol more CE bs
[01:11:58 CET] <TimothyGu> when is this going to end
[01:12:57 CET] <wm4> it was sort of funny but I think it's going a bit too far now
[01:13:47 CET] <JEEB> yes, multiple people have been rather insulting at each other, but it's no reason to level-up it
[01:14:18 CET] <JEEB> (or well, not insulting but what's the right word...)
[01:14:26 CET] <klaxa> flaming?
[01:14:35 CET] <JEEB> just generally WORD
[01:19:10 CET] <TimothyGu> read the archives. same old same old
[01:20:04 CET] <JEEB> yes, it's unfortunately not new
[01:31:27 CET] <JEEB> wm4: btw are you sure it was http that had timeout?
[01:31:39 CET] <JEEB> http.c didn't have a timeout AVOption (couldn't find string)
[01:31:47 CET] <JEEB> is it on the tcp protocol level?
[01:32:10 CET] <JEEB> ah, yes
[01:32:13 CET] <JEEB> there it is :)
[01:33:44 CET] <wm4> yes, I think strictly speaking it's tcp, and it's passed down the protocol chain
[01:34:28 CET] <JEEB> yea, I just wanted to link the specifics for some reason into my reply :P
[01:34:38 CET] <JEEB> (I should really be sleeping)
[01:34:52 CET] <wm4> uh I should verify whether it really works
[01:37:41 CET] <JEEB> ok, udp is also microseconds with timeout
[01:38:47 CET] <wm4> ok looked how it actually works, and it's due to explicitly passing the options AVDictionary down the protocol chain
[01:39:12 CET] <wm4> and for subsequent connections (like when seeking) it even keeps a copy of the original options dict, so that the options stick
[01:41:25 CET] <JEEB> yup
[01:46:10 CET] Action: JEEB posts
[01:48:45 CET] <kierank> JEEB: as if a thread on a nonrealtime os can do microsecond precision timings
[01:49:40 CET] <JEEB> kierank: that wasn't the point, the point was that changing the name of an option brings it in line with another protocol's option
[01:49:44 CET] <kierank> i know
[01:50:33 CET] <JEEB> so we have RTSP/UDP/TCP at least with a similar socket-based "timeout" option that takes in microseconds
[01:50:52 CET] <JEEB> whether or not microseconds are correct for this... (´4@)
[01:51:17 CET] <JEEB> but this change was just regarding renaming of options, where the type just happened to even match between multiple protocols after it
[01:54:02 CET] <JEEB> of course, if the change of option types (which seemed to be the primary concern for most people who commented) is deemed critical enough, then that can be done as well,  although I'm not sure if it should be stuck together with the initial option renaming.
[01:57:27 CET] <wm4> yeah I don't think finer than microseconds is needed
[01:57:49 CET] <JEEB> if there's a fancier type than just INT
[01:57:55 CET] <JEEB> (which all timeouts currently are)
[01:57:56 CET] <wm4> if you need timeouts smaller than a microsecond you're probably doing some hardcore realtime stuff, and certainly not in libavformat
[01:58:19 CET] <JEEB> they can be switched together at some point as a general timeout clean-up
[01:59:58 CET] <wm4> also these timeouts are usually used for rather coarse user settings (or just to prevent scripts from getting stuck), so even a resolution as low as 100ms would be fine
[02:00:09 CET] <JEEB> yes
[02:00:15 CET] <wm4> not the mention that libavformat's polling reduces the resolution anyway
[02:00:36 CET] <JEEB> but personally I'm not going to touch that side of it, since that's a whole separate bikeshed
[02:01:54 CET] <wm4> ah yeah, the poll() call is always done with a fixed 100ms timeout
[02:02:12 CET] <wm4> so the timeout option effectively has a resolution of 100ms
[02:02:32 CET] <rcombs> I do think it being in microseconds when everything else is (possibly decimal) seconds is weird
[02:04:10 CET] <rcombs> AV_OPT_TYPE_DURATION
[02:04:25 CET] <JEEB> yes, that part I actually most agreed with
[02:04:36 CET] <JEEB> that the types (option ones) could be normalized
[02:05:07 CET] <wm4> feel free to Change Everything for that but I won't
[02:05:11 CET] <rcombs> not sure how to do that without immediately breaking compat, though
[02:05:19 CET] <rcombs> I mean, you could use a different name
[02:05:22 CET] <JEEB> oh yea, bw compat will go derp
[02:05:28 CET] <JEEB> unless you want a new option
[02:05:31 CET] <wm4> I only wanted to get rid of the stupid rtsp special case
[02:05:34 CET] <rcombs> but there isn't really a better name available than "timeout"
[02:05:34 CET] <JEEB> yes
[02:06:28 CET] <JEEB> the rename is a step to the right direction and the next step can be taken if we are still in the mood of breaking AVOption bw compat
[02:06:52 CET] <JEEB> (but it's a separate larger piece of work that requires git grepping for all time-related AVOptions to bring them all in line)
[02:07:11 CET] <JEEB> (or just even starting with timeouts)
[02:08:28 CET] <rcombs> just sucks for anyone currently using them in a script
[02:08:46 CET] <JEEB> yes
[02:08:59 CET] <rcombs> I guess for timeouts you could cheat and assume any absurdly large value was meant to be microseconds, and warn about it and divide
[02:09:30 CET] <JEEB> also I loved one of the options being in milliseconds, just to be different from both seconds and microseconds
[02:09:41 CET] <rcombs> lol
[02:09:44 CET] <JEEB> of which microseconds was utilized for the normal socket timeout
[02:09:51 CET] <rcombs> AV_OPT_TYPE_DURATION is AV_TIME_BASE, right?
[02:09:59 CET] <JEEB> I think so
[02:10:11 CET] <JEEB> or was it a rational thing?
[02:11:01 CET] <rcombs> nah it's microseconds
[02:11:07 CET] <JEEB> yea
[02:11:11 CET] <JEEB> just checked some of my older code
[02:11:15 CET] <wm4> the best idea I came up with was interpreting "timeout" as the actual timeout (and in ms) if "listen_timeout" is also set
[02:11:22 CET] <kierank> wm4: I reckon you can do +- 500us at best on a standard machine
[02:11:25 CET] <wm4> but, too much effort
[02:11:29 CET] <JEEB> which (ab)used av_parse_time()
[02:12:14 CET] <rcombs> so yeah, you could change them all to AV_OPT_TYPE_DURATION, then check if the value is e10000*AV_TIME_BASE, for instance
[02:12:23 CET] <rcombs> and warn and divide by 1000000
[02:13:18 CET] <JEEB> anyways, sleep taimu
[02:13:54 CET] <wm4> that seems like a bad idea
[02:14:35 CET] <wm4> wait what is AV_TIME_BASE at all
[02:14:51 CET] <wm4> hm microseconds
[02:15:07 CET] <rcombs> yeah, so there'd be no change to existing code that actually _uses_ the value
[02:15:25 CET] <wm4> so why the comparison you mentioned?
[02:15:46 CET] <wm4> oh, TYPE_DURATION would still assume seconds for normal input numbers
[02:15:49 CET] <rcombs> currently to specify e.g. 5 seconds, you pass 5000000
[02:15:51 CET] <rcombs> yeah
[02:16:02 CET] <rcombs> so this would let you pass 5
[02:16:22 CET] <rcombs> 5 would produce 5000000, and 5000000 would produce 5000000000000
[02:16:24 CET] <wm4> I still don't think this would be a good idea for a compat hack
[02:16:44 CET] <rcombs> I'm not _super_ sold on it but as compat hacks go it's relatively clean
[02:17:05 CET] <rcombs> since the range of reasonable timeouts is way smaller than the 6 orders of magnitude of difference here
[02:17:19 CET] <wm4> couldn't it just default to microseconds if there's no unit given
[02:17:19 CET] <rcombs> so you could very confidently tell when a value was intended for the old thing
[02:17:26 CET] <wm4> then it'd be perfectly compatible
[02:17:37 CET] <rcombs> does TYPE_DURATION even do units?
[02:17:53 CET] Action: rcombs checks
[02:17:54 CET] <wm4> (not that I'd see any reason to change this... if ffmpeg CLI usage is too inconvenient, the CLI can do the translation)
[02:18:14 CET] <rcombs> it does not
[02:18:34 CET] <wm4> anyway this is still nothing but bikeshed since the rtsp option not only has a different unit, but completely different and incompatible semantics
[02:19:02 CET] <rcombs> API usage would stay the same unless you were passing a string already
[02:20:34 CET] <wm4> protocols use AVDictionary to pass in options, which are always strings
[02:21:08 CET] <rcombs> I mean if you were using, say, av_opt_set_int
[02:22:29 CET] <wm4> AFAIK you can't even use that with protocols
[03:12:00 CET] <Compn> wat
[03:34:02 CET] <rcombs> has http://fatebeta.ffmpeg.org/report/aarch64-linux-qemu-ubuntu-gcc-4.8/20180125234228 been broken since 0a24d7ca831b85db18593e5f18d765adb40e5cd9
[03:35:32 CET] <rcombs> it's complaining about "fcmeq           v7.4S, v3.4S, #0.0"
[03:35:54 CET] <rcombs> I don't know nearly enough arm to tell what any of that means
[03:44:03 CET] <jamrial> rcombs: poke matthieu
[03:44:17 CET] <rcombs> does he IRC
[03:44:24 CET] <jamrial> i don't know
[03:47:38 CET] <jamrial> rcombs: maybe https://sourceware.org/ml/binutils/2014-02/msg00148.html
[03:48:15 CET] <rcombs> hmm, so maybe I need a new assembler on this CI
[03:48:18 CET] <rcombs> and so does fate
[03:49:00 CET] <jamrial> how old is binutils?
[03:49:23 CET] <jamrial> try to change that to #0.0 to #0, see if it helps
[03:52:37 CET] <rcombs> 2.24
[03:52:51 CET] <rcombs> it's an android toolchain
[03:52:56 CET] <cone-078> ffmpeg 03Karthick Jeyapal 07master:0df9d0f4cbcb: avformat/dashenc: Fix a resource leak when http persistent in enabled
[03:52:56 CET] <cone-078> ffmpeg 03Karthick Jeyapal 07master:18e2ac032e9d: avformat/dashenc: Signal http end of chunk(http_shutdown) explicitly
[03:52:57 CET] <rcombs> (>android)
[03:53:00 CET] <rcombs> I'll try it
[03:57:36 CET] <jamrial> guess that fix was never backported to 2.24 as mentioned in that patch, and it's only in >= 2.25 
[04:44:34 CET] <jamrial> rcombs: cool, can you send a patch?
[04:45:15 CET] <rcombs> jamrial: sent
[09:42:17 CET] <cone-380> ffmpeg 03Rodger Combs 07master:77237504757b: lavc/aarch64/sbrdsp_neon: fix build on old binutils
[14:01:21 CET] <thardin> can ffmpeg do palette + dither these days?
[14:15:05 CET] <sfan5> like this? http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
[14:20:04 CET] <thardin> yes found something similar
[17:22:34 CET] <atomnuker> durandal_1707: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018?action=diff&version=19
[17:33:06 CET] <cone-380> ffmpeg 03Rodger Combs 07release/3.4:ad85d9af13db: lavc/aarch64/sbrdsp_neon: fix build on old binutils
[18:11:54 CET] <tmatth> atomnuker: would it make sense to add PLC to one or both of ffmpeg's libopus decoder or native opus decoder?
[18:16:25 CET] <atomnuker> its not straightforward
[18:16:57 CET] <atomnuker> packet loss implies total packet loss and not just a corrupted packet, right?
[18:17:42 CET] <atomnuker> I think the simplest and non-hacky way to do this would be to use lavfi
[18:19:04 CET] <atomnuker> with a filter which is forced to run in real time and checks the pts on every input packet and if it drifts more than the max frame size would apply plc
[18:19:38 CET] <durandal_170> atomnuker: yes!, i am qualified as student for gsoc
[18:19:40 CET] <atomnuker> though I think this should belong in the user, unless durandal_1707 has any ideas how to
[18:24:52 CET] <durandal_170> write simd for lut3d filter
[18:25:28 CET] <tmatth> atomnuker: total packet loss yeah
[18:26:09 CET] <kierank> atomnuker: unless you use a special protocol packets are either there are not
[18:27:22 CET] <atomnuker> yeah, and no packets -> no frames
[18:29:19 CET] <kierank> well if you buffer and lose a single packet you can hide
[18:33:43 CET] <tmatth> IIRC opus_demo buffers by one packet to demonstrate PLC as well as FEC
[19:33:02 CET] <KGB> [13FFV1] 15michaelni closed pull request #89: Replace color space wording by more adapted transformation wording (06master...06transformations) 02https://git.io/vNvVm
[20:12:32 CET] <BtbN> Are those unversioned files like "libavfilter/opencl/overlay.c" auto-generated?
[00:00:00 CET] --- Sat Jan 27 2018