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

[burek]

[00:17:43 CEST] <JEEB> asdf
[00:18:13 CEST] <JEEB> apparently we have a performance thing with tls_schannel around the same time the EOF != 0 thing happened
[00:18:23 CEST] <JEEB> but I can't see anything glaringly obvious
[00:18:26 CEST] <Compn> http://www.otakuusamagazine.com/66-pounds-hentai-confiscated-comiket-goer-swiss-customs/
[00:18:29 CEST] <JEEB> and it's not like TLS doesn't work
[00:18:51 CEST] <JEEB> and we're not getting bug reports on this because the most utilized ffmpeg.c builds (zeranoe's) utilize gnutls
[00:18:56 CEST] <JEEB> which seemingly seem to work better
[00:19:06 CEST] <JEEB> *which seemingly seems to work better
[00:19:47 CEST] <JEEB> people mostly seem to notice the issues with HLS playback with schannel, gnutls seems to work quite a bit better
[00:20:24 CEST] <JEEB> I tried to look at tls_read but as I noted I couldn't figure out anything glaringly obvious
[00:20:52 CEST] <nevcairiel> try with -http_persistent 0
[00:21:57 CEST] <JEEB> with a quick look that's faster
[00:22:27 CEST] <nevcairiel> for some reason that mode seems to mess up with schannel
[00:22:29 CEST] <nevcairiel> no clue why
[00:27:32 CEST] <JEEB> the issue @ mpv had someone make retry_transfer_wrapper return not only with < 0 but with <= 0 as well, which supposedly for some improved performance. personally I don't see it
[00:27:36 CEST] <JEEB> https://github.com/mpv-player/mpv/issues/5286#issuecomment-354140558
[00:28:23 CEST] <nevcairiel> that was probably before schannel was fixed for EOF returns
[00:28:36 CEST] <JEEB> quite possible
[00:28:58 CEST] <JEEB> since you're not supposed to return zero from that function with such protocols anyways
[00:29:23 CEST] <JEEB> (you get a warning)
[00:47:29 CEST] <cone-578> ffmpeg 03Jacob Trimble 07master:7e0df5910ec0: avcodec/opus_parser: Handle complete frames flag.
[03:49:55 CEST] <atomnuker> bofh_: ping
[03:53:29 CEST] <bofh_> atomnuker: pong
[03:54:33 CEST] <atomnuker> do you think its possible to change transform direction by changing the pre/post reindexing?
[03:55:01 CEST] <atomnuker> our ptwo fft does it that way, but don't know if its possible to do in mdct15 as well
[03:55:40 CEST] <atomnuker> currently we conjugate the imaginary values of the exptabs
[03:57:33 CEST] <atomnuker> *the values of the exptabs
[04:01:09 CEST] <bofh_> atomnuker: hrm. not sure. the fact that you can do it that way for split-radix 2/4 Cooley-Tukey seems more luck than anything (it's not possible to do it that way for regular radix-2 DIT Cooley-Tukey IIRC), but I'll think about it / ch3c3ck 3ckeck gh3 the literature over lucnch
[04:01:16 CEST] <bofh_> lunch*
[04:02:28 CEST] <bofh_> conjugating exptab values is the canonical way to do it & works for any order FFT btw.
[04:04:49 CEST] <atomnuker> ktnx, I'd really rather not store huge tables in our fft context which only differ by their sign
[04:05:40 CEST] <atomnuker> it doesn't help that the complex values we'd be storing will change size depending on whether float/double or int fft is used
[04:05:49 CEST] <bofh_> they're runtime-generated tho so they'd live in RAM/stack
[04:06:21 CEST] <bofh_> also doubles for audio fft is massive overkill imho.
[04:06:30 CEST] <atomnuker> yes, currently for the non power of two fft, for the ptwo fft they're generated on init once unless config_small is disabled
[04:07:10 CEST] <atomnuker> it won't just be used for audio though, durandal_1707 was requesting it for a filter
[04:08:28 CEST] <bofh_> using doubles in af_* is still overkill for all but very few cases, but that's a discussion for another time.
[04:08:44 CEST] <bofh_> and ahh.
[04:09:55 CEST] <bofh_> well I'll try seeing if doing it via reindexing alone is possible & poke you this evening.
[04:10:58 CEST] <bofh_> well, early afternoon for you if I'm remembering your timezone correctly.
[04:17:35 CEST] <atomnuker> ping me whenever, it hardly matters when I'm not aligned to what people use here
[09:41:19 CEST] <durandal_1707> Compn: are you ignoring me?
[09:43:35 CEST] <cone-030> ffmpeg 03Zhong Li 07master:900487043b6e: lavc/qsvenc: add quality status to side_data
[10:57:42 CEST] Action: JEEB makes a trac issue for the H.264 decoding barf
[10:58:26 CEST] <durandal_1707> Carl will close it for sure if he can not reproduce it
[10:58:39 CEST] <JEEB> don't worrty
[10:58:52 CEST] <JEEB> the sample reproduces on all versions of FFmpeg I've had on hand :P
[11:07:21 CEST] <JEEB> ^ durandal_1707 , pretty sure even you can repro this :D
[11:21:03 CEST] <kierank> JEEB: I want to create a "super-fate" for things like this
[11:36:27 CEST] <jdarnley> > Not a regression afaict, the following works fine
[11:36:33 CEST] <jdarnley> > -skip_initial_bytes 2000000
[11:37:13 CEST] <cone-030> ffmpeg 03Martin Vignali 07master:3af1c4ea7d18: swscale : treat float input data as uint 16bpc
[11:37:14 CEST] <cone-030> ffmpeg 03Martin Vignali 07master:bdd67546482b: swscale/swscale : small cosmetic
[11:37:15 CEST] <cone-030> ffmpeg 03Martin Vignali 07master:9e64ee3936b1: avcodec/psd : add support for gray float
[11:37:36 CEST] <kierank> jdarnley: wow you're not joking either
[11:39:11 CEST] <jdarnley> I guess that gives someone an idea of what it should look like after they fix the bug.
[11:40:15 CEST] <durandal_1707> TIL emblaze .EA files uses gsm codec
[11:49:35 CEST] <JEEB> jdarnley: yup. I did note in the initial description that it would work if you started decoding after the glitch/whatever
[12:10:19 CEST] <durandal_1707> which decoder is this: https://pastebin.com/QnsewCt6
[12:14:31 CEST] <BradleyS>       System.out.println("Timebomb :" + TimeBomb());
[12:14:31 CEST] <BradleyS>       System.out.println("Emblaze Video : This copy has EXPIRED");
[12:14:58 CEST] Last message repeated 1 time(s).
[12:14:58 CEST] <BradleyS> if (TimeBomb())
[12:14:59 CEST] <BradleyS> heh
[12:16:19 CEST] <BradleyS> probably this: https://www.zdnet.com/article/emblaze-video-fizzles-out/
[12:17:45 CEST] <jdarnley> > ecommends Netscape Navigator 4.0
[12:17:51 CEST] <jdarnley> Then I looked at the date
[12:20:07 CEST] <BradleyS> i like how the article subhead claims it's plugin-less video technology when it requires and ships it's own java applet
[12:20:42 CEST] <BradleyS> i guess it's technically a runtime and maybe not specifically using netscape's plugin api but yeah... far from native
[12:42:07 CEST] <durandal_1707> what decoder should i do next? i'm out of ideas
[12:43:30 CEST] <JEEB> did you already get bored of bink2?
[12:45:18 CEST] <durandal_1707> i got very frustrated, i couldn't get bitstream parsing of old variant working, and because of multithreading any debugging is futile
[12:50:39 CEST] <kierank> durandal_1707: can you not run in vm and set cpus to 1
[12:53:09 CEST] <durandal_1707> kierank: wouldn't kernel scheduler switch threads anyway?
[12:53:28 CEST] <kierank> durandal_1707: depends, they may have a thing to check cpus and spawn threads accordingly
[13:07:47 CEST] <cone-030> ffmpeg 03Jun Zhao 07master:c4608d225faf: lavf/hlsenc: fix mixed declarations and code warning.
[13:07:48 CEST] <cone-030> ffmpeg 03Jun Zhao 07master:e2921578c09e: lavc/libkvazaar: fix incompatible pointer type.
[13:15:45 CEST] <cone-030> ffmpeg 03Steven Liu 07master:9e61141905b5: avformat/hls: support decryption AES128 fmp4 m3u8 list
[14:11:21 CEST] <pasouza> Hi, I'd like to call anyone interested in the use of swscale in the SR filter to follow the ml discussion (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233233.html)
[14:11:36 CEST] <pasouza> and argue for or against it before we make any final decision
[14:15:58 CEST] <azaki> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^\s+@([[:alnum:]][[:alnum:]\-]*)({ <-- HERE })?\s*/ at /usr/share/texinfo/Texinfo/Parser.pm line 5481.
[14:16:06 CEST] <azaki> was building ffmpeg-git in arch, and got this warning
[14:16:33 CEST] <azaki> i'm guessing it's known by now? =o
[14:17:08 CEST] <azaki> seems to be during the configure stage
[14:22:58 CEST] <nevcairiel> isnt that error from your local TexInfo package
[14:23:07 CEST] <nevcairiel> or warning for that matter
[17:11:23 CEST] <cone-955> ffmpeg 03Baptiste Coudurier 07master:130de9142edd: avformat/mxfenc: automatically update descriptors klv size
[18:02:28 CEST] <durandal_1707> michaelni: if you find time, do you gonna review prosumer decoder?
[18:13:43 CEST] <durandal_1707> libavformat/tls_openssl.c:105:46: warning: comparison of function 'openssl_lock' equal to a null pointer is always false [-Wtautological-pointer-compare]
[18:13:46 CEST] <durandal_1707>         if (CRYPTO_get_locking_callback() == openssl_lock) {
[18:13:48 CEST] <durandal_1707>             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ^~~~~~~~~~~~
[18:13:51 CEST] <durandal_1707> libavformat/tls_openssl.c:105:46: note: prefix with the address-of operator to silence this warning
[18:13:54 CEST] <durandal_1707>         if (CRYPTO_get_locking_callback() == openssl_lock) {
[19:00:33 CEST] <cone-955> ffmpeg 03Jacob Trimble 07master:eb350ab738e7: avformat/mov: Allow saio/saiz in clear content.
[19:00:34 CEST] <cone-955> ffmpeg 03Fredrik Hubinette 07master:5ecd580953bb: avformat/utils: avoid undefined integer overflow behavior in update_stream_timings()
[19:01:46 CEST] <cone-955> ffmpeg 03Zhao Zhili 07master:70d2bab80b38: lavc/hevc_ps: fix crop info for monochrome
[19:14:42 CEST] <thardin> hrm, mxfdec timestamp issue
[20:41:55 CEST] <rcombs> durandal_1707: CRYPTO_get_locking_callback() was changed to a macro returning NULL in 1.1.0; you can make that compile-time-conditional on the version if you like
[22:16:55 CEST] <durandal_1707> Compn: are you awake?
[23:17:16 CEST] <jdarnley> Is it just me or does this monitor look better now I connected it on DVI rather than HDMI?
[23:25:15 CEST] <kierank> jdarnley: ?
[23:29:37 CEST] <wbs> jdarnley: some monitors display colors differently depending on HDMI and DVI connection, yes. HDMI connections usually run YCbCr while DVI connections run RGB, even though both could handle both. and monitors usually treat YCbCr differently even though it technically shouldn't matter
[23:37:36 CEST] <atomnuker> and even then some want limited range rgb even though they can handle full range just fine
[23:39:02 CEST] <atomnuker> TVs are hell and you shouldn't rely on them having anywhere near accurate colors nor that the image won't be filtered and noised/denoised
[23:39:59 CEST] <jkqxz> ... / overscanned / delayed by up to a second / etc.
[23:40:33 CEST] <jdarnley> This is a desktop PC display and now you mention TV range... that would fit.
[23:40:55 CEST] <jdarnley> It seems to be quite a bit brighter, and whiter, with the idential one next to it.
[23:41:01 CEST] <atomnuker> jkqxz: you've seen a TV which delays so long? damn, I thought 300ms I saw once was bad
[23:41:28 CEST] <jdarnley> It was never a perfect match but this is now brighter, sharper
[23:41:40 CEST] <jdarnley> with better black too, maybe
[23:42:06 CEST] <jdarnley> I've been missing out!
[23:42:48 CEST] <jdarnley> Maybe I should clarify that this is an HDMI-DVI cable.
[23:42:56 CEST] <jdarnley> I think I'll buy two more
[23:43:34 CEST] <jkqxz> I've seen over 500ms.  (It fucks epically with echo cancellation when you have microphones in the room as well.)
[23:43:58 CEST] <jkqxz> Generally TVs have some sort of "game mode" or similar function which you should always use, because it turns off the stupidest delay parts.
[23:45:22 CEST] <atomnuker> sadly they turn the backlight down for some reason on game mode, and some still do filtering even then, though nothing fancy
[23:46:03 CEST] <jkqxz> The cable shouldn't make any difference, because the wires are identical (excepting the lack of CEC in DVI).  That doesn't rule out either end deciding to treat the different connectors differently, though.
[23:46:11 CEST] <atomnuker> I wonder how they store potentially 100mb of data and some even do temporal interpolation, isn't memory quite expensive
[23:46:41 CEST] <jdarnley> One chip buffing just a little, then another, then another?
[23:46:43 CEST] <jkqxz> They need a few GB of memory to run their shitty android UIs anyway.
[23:46:58 CEST] <jkqxz> (Or webos, of course.)
[23:48:46 CEST] <atomnuker> right, that's probably why, they buffer and rely on android to display, maybe
[00:00:00 CEST] --- Thu Aug 23 2018