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

[burek]

[00:31:54 CET] <atomnuker> ...whilst there's no av_dict_get_int, av_dict_get_string() is really awesome
[01:35:14 CET] <cone-163> ffmpeg 03Rodger Combs 07master:1eb7c1d49d67: lavc/libx265: support all color parameters that x265 does
[02:22:41 CET] <cone-163> ffmpeg 03Michael Niedermayer 07release/3.2:acf131616717: avcodec/arm/sbrdsp_neon: Use a free register instead of putting 2 things in one
[02:22:41 CET] <cone-163> ffmpeg 03Michael Niedermayer 07release/3.2:fc7e3955aeae: avcodec/utils: Avoid hardcoding duplicated types in sizeof()
[02:22:42 CET] <cone-163> ffmpeg 03Michael Niedermayer 07release/3.2:124a3ddc4be1: Changelog: update
[03:20:13 CET] <wm4> jamrial, nevcairiel, wbs: can I push my network patch now?
[03:20:31 CET] <wm4> or should we actually require newer openssl/gnutls versions and just deprecate the options
[03:23:08 CET] <jamrial> i bet that will break compilation with a bunch of distros
[03:23:10 CET] <rcombs> requiring openssl 1.1 would be a bad idea
[03:23:11 CET] <jamrial> openssl 1.0.x is still widely used (if you mean making 1.1.x the minimum version supported)
[03:23:35 CET] <rcombs> openssl doesn't even support it yet
[03:23:38 CET] <rcombs> erm, openssh
[03:24:12 CET] <rcombs> that'll probably block most distros, at least from shipping 1.1 without also shipping 1.0
[03:24:18 CET] <jamrial> really? arch ships openssh 7.6 and openssl 1.1
[03:24:50 CET] <rcombs> might ship openssh statically linked against openssl, or they might be applying an openssh patch
[03:25:14 CET] <rcombs> there's been a patch sitting around in PR/the ML for like a year without getting merged
[03:25:32 CET] <rcombs> not sure if there's still any good reason for that
[03:26:08 CET] <jamrial> yup, https://git.archlinux.org/svntogit/packages.git/tree/trunk/openssl-1.1.0.patch?h=packages/openssh
[03:26:10 CET] <rcombs> tbh I don't really care about 1.1, but 1.1.1 is going to add a whole bunch of really useful shit
[03:27:24 CET] <rcombs> flag to use chacha for clients that prefer it, session key logging callback, callbacks to override shit mid-handshake, TLS 1.3...
[04:16:38 CET] <cone-163> ffmpeg 03Carl Eugen Hoyos 07release/3.2:028a032a315a: configure: bump year
[04:35:30 CET] <atomnuker> anyone who knows how hwframes filtering works: is it possible to do in-place filtering?
[04:36:07 CET] <atomnuker> I need to create another hw frames context otherwise the next filter (hwdownload) will be complaining the previous one doesn't have any
[04:36:52 CET] <atomnuker> and if I do that I need to go all the way and create a new frame from the new hw context (just reffing the in frame to the out makes the next filter say its not from the same ctx)
[04:47:27 CET] <wm4> hw frames are generally read-only
[04:47:37 CET] <wm4> not sure if copy-on-write can even work
[05:16:46 CET] <jamrial> huh
[05:16:58 CET] <jamrial> google defined a CodecPrivate element for vp9 in webm
[05:17:13 CET] <wm4> I thought vp9 doesn't have that
[05:18:16 CET] <jamrial> the contents seem to be similar to the vpcc mov atom
[05:18:45 CET] <wm4> what does that contain?
[05:19:20 CET] <jamrial> so basic bitstream info to allow a parser/demuxer to bail out early if it's something the decoder will not support (like high bitdepth streams) instead of having the decoder fail
[05:19:35 CET] <jamrial> profile, level, bitdepth, etc
[05:20:07 CET] <jamrial> https://www.webmproject.org/docs/container/
[05:21:05 CET] <wm4> shitty
[05:23:47 CET] <jamrial> maybe this is because starting up a hardware decoder may be costly for a stream that will ultimately not be decodable, so bailing out early would be a better idea
[05:27:04 CET] <jamrial> well, youtube vp9 videos don't seem to implement this
[09:50:30 CET] <jkqxz> atomnuker:  You can make outlink->hw_frames_ctx a reference to inlink->hw_frames_ctx.
[11:21:01 CET] <bogdanc> how can i tell inside cfhd.c:filter if i currently work with the bottom pixels or the most right ones? (inside the case "i == len-1")
[11:27:30 CET] <bogdanc> nvm
[13:06:51 CET] <cone-825> ffmpeg 03Rostislav Pehlivanov 07master:fcb681ac3edd: aacenc: use the fast coder as the default
[13:06:51 CET] <cone-825> ffmpeg 03Rostislav Pehlivanov 07master:6c4b9eb935b6: fate: remove the fate-aac-ltp-encode test
[13:07:34 CET] <atomnuker> BtbN: was it you who told me about the aac encoder's possible instability on long livestreams/synthetic chirps?
[13:07:50 CET] <BtbN> yeah.
[13:08:02 CET] <atomnuker> this ought to fix them even though I wasn't able to reproduce
[13:08:45 CET] <BtbN> Yeah, I never managed to reproduce it myself either. Only keep seeing it on Twitch, and every time obs-studio is involved, which uses the ffmpeg aac encoder.
[13:08:58 CET] <BtbN> And I doubt Twitch re-muxing the stream can cause that
[13:12:11 CET] <RiCON> i thought obs used microsoft's by default or fdk
[13:12:16 CET] <RiCON> guess they changed it
[13:12:26 CET] <BtbN> They never used fdk due to the license
[13:12:36 CET] <BtbN> And they used ffmpeg aac since forever, even when it was still experimental
[13:12:46 CET] <BtbN> And Microsoft has an AAC encoder?
[13:12:58 CET] <BtbN> https://clips.twitch.tv/NicePopularPorcupineCurseLit this is an example of the audio glitch
[13:13:29 CET] <RiCON> BtbN: since at least 8.x
[13:15:47 CET] <BtbN> According to the Handbrake-Guys, it's bad
[13:15:50 CET] <BtbN> So I doubt obs uses it
[13:17:03 CET] <RiCON> i can't remember where they set the defaults according to bitrate
[13:21:29 CET] <BtbN> https://github.com/jp9000/obs-studio/blob/master/UI/audio-encoders.cpp
[13:21:39 CET] <BtbN> they seem to be doing some elaborate mapping of bitrate to encoder
[13:23:08 CET] <BtbN> I don't understand what the hell that code is doing
[13:29:19 CET] <BtbN> It logs those informations, but only to DEBUG log, and there is no indication on how to raise the log level
[13:29:26 CET] <BtbN> it's not in the settings
[13:41:07 CET] <atomnuker> coming soon: a shaderless vf_scale_vulkan capable of scaling and yuv2rgb conversion
[13:52:31 CET] <durandal_1707> no rgb2yuv?
[13:55:58 CET] <atomnuker> not possible without shaders
[14:58:59 CET] <BtbN> atomnuker, is this true for ffmpeg 3.4 as well? So, just switching to fast there will help the same way?
[15:00:40 CET] <atomnuker> that coder hasn't been changed in more than 6 years, so yeah, it'll do the same in 3.4
[15:01:24 CET] <durandal_1707> isnt that worse quality?
[15:01:43 CET] <BtbN> Aparently only at low bitrates
[15:44:27 CET] <SortaCore> vf_scale_vulkan, what type of input would that be?
[15:44:37 CET] <SortaCore> need a certain hwaccel?
[15:50:45 CET] <cone-825> ffmpeg 03Rostislav Pehlivanov 07n3.2.10:HEAD: fate: remove the fate-aac-ltp-encode test
[15:51:44 CET] <atomnuker> SortaCore: you can import vaapi images into vulkan, so that would work
[15:52:24 CET] <atomnuker> I think you could also import kms images into vulkan, though I'll need to test that
[15:52:50 CET] <atomnuker> you can also import d3d11 images though the API's different
[15:54:57 CET] <wm4> atomnuker: how do you import vaapi images?
[15:55:19 CET] <atomnuker> VK_KHR_external_memory_fd
[16:18:41 CET] <atomnuker> can anyone refuzz the aac encoder? I'd do it myself but no fast enough spare machines
[16:22:28 CET] <nevcairiel> how do you effectively fuzz an encoder?
[16:22:38 CET] <nevcairiel> bitflips in input data are hardly going to affect it
[16:25:01 CET] <atomnuker> they are in aac because of the pain in the ass way scalefactors are coded
[16:25:32 CET] <atomnuker> and if the difference is too large an assert gets triggered
[16:27:27 CET] <atomnuker> and if you get a scalefactor wrong, you get junk output
[16:27:39 CET] <atomnuker> this also makes aac not very robust towards packet loss
[16:28:24 CET] <atomnuker> with opus you can put junk in 90% of the packet and as long as the energy's intact you'll still hear something comprehendable
[16:56:10 CET] <BtbN> atomnuker, the aac encoder shouldn't care if it's run in real time or faster than real-time, should it?
[16:56:33 CET] <atomnuker> nope
[16:58:10 CET] <BtbN> I wonder how good that Microsoft AAC encoder is. Seems like it's the one at fault for the glitches. OBS uses it for bitrates from 96 to 192, ffmpeg aac for anything outside that range.
[16:58:35 CET] <BtbN> I'd be surprised if it's better than ffmpeg aac though
[17:13:35 CET] <atomnuker> so practically no one ran the encoder? disappointing but oh well
[17:26:00 CET] <BtbN> I guess it will become the default soon though
[17:38:31 CET] <atomnuker> it will?
[17:41:55 CET] <kierank> atomnuker: ask michaelni to add it to the google fuzz set
[17:46:11 CET] <BtbN> atomnuker, it seems like this MS encoder is utter garbage, so the ffmpeg one is the obvious choice
[17:46:26 CET] <BtbN> I wonder why they didn't use it in the first place, given that they ship it with obs anyway
[18:13:12 CET] <SortaCore> atomnuker: how about dxva2?
[18:14:18 CET] <durandal_1707> what about 360° video support in cpu in lavfi for gsoc?
[18:43:16 CET] <atomnuker> SortaCore: I don't think so, not sure if you could go d3d11->dxva->vulkan
[18:43:27 CET] <atomnuker> erm dxva2->d3d11->vulkan
[18:44:01 CET] <nevcairiel> with a on-gpu copy you could, but its not implemented in the hwcontext
[18:44:08 CET] <atomnuker> durandal_1707: why, you said it youself there isn't much 360 video
[18:47:10 CET] <atomnuker> peloverde: hey you had some interest in ilbc, right?
[18:47:31 CET] <atomnuker> its the only mainstream codec we don't have support for
[18:52:49 CET] <durandal_1707> atomnuker: audio, there is lot of video but 4ch audio is rare
[18:54:51 CET] <cone-825> ffmpeg 03Daniil Cherednik 07master:c7d726f7f466: opusenc_psy: Typo, use all coeffs in range for band tonality calculation
[19:07:45 CET] <cone-825> ffmpeg 03Rostislav Pehlivanov 07master:56e11ebf55a5: dcaenc: cleanup on init failure and add a threadsafe init codec cap
[19:38:52 CET] <cone-825> ffmpeg 03Daniil Cherednik 07master:ec6e389c753b: avcodec/dcaenc: Use ffmpeg mdct instead of own implementation
[19:38:53 CET] <cone-825> ffmpeg 03Rostislav Pehlivanov 07master:c51301db14fe: dcaenc: move all tables inside context and fix incorrect coding style
[19:39:17 CET] <atomnuker> who wrote this piece of shit encoder and why was it merged as-is?
[19:39:20 CET] <atomnuker> its horrible
[19:40:29 CET] <atomnuker> the original author didn't know what they were doing and thought, "ah, fixed point audio encoders for the de-facto future standard, just sounds right"
[19:41:52 CET] <jamrial> you should send patches like the above to the ml first...
[19:42:34 CET] <atomnuker> just a bunch of cleanups, nothing more
[19:43:14 CET] <atomnuker> no one would've reviewed them anyway, then I'd lose the patches, would be too lazy to dig them from the ml until a month later
[19:43:50 CET] <jamrial> you set the encoder as init thread safe while it still had static tables initialized during init() without a pthreads_once control
[19:44:21 CET] <jamrial> that's solved now, but still the order should have been the inverse
[19:44:40 CET] <atomnuker> I know
[19:45:51 CET] <jamrial> is there any advantage moving them to the context?
[19:46:31 CET] <nevcairiel> if the tables are small enough that should imho be the preferable option
[20:05:31 CET] <peloverde> atomnuker: I'm not really interested in ilbc. I mean sure it would be nice to have but I don't have the time or interest to make it happen.
[20:13:01 CET] <atomnuker> peloverde: oh well, do you have any public/non-public specs? I looked into it a year ago and was able to find absolutely nothing?
[20:17:23 CET] <durandal_1707> its course code is spec
[20:20:01 CET] <kierank> atomnuker: rfc is not enough?
[20:22:08 CET] <atomnuker> oh, I didn't know its rfc was so detailed, I think that would work
[00:00:00 CET] --- Sun Jan 14 2018