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

[burek]

[00:00:13 CEST] <JEEB> so the thing reading your files would be a different thing to the one sending stuff to the web etc
[00:00:34 CEST] <atomnuker> meh, how hard can that be? just have secure renderer/javascript vm
[00:00:53 CEST] <rcombs> I think chrome actually does have a "run in one process" command line switch for debugging purposes
[00:00:59 CEST] <JEEB> yea
[00:01:01 CEST] <JEEB> it does
[00:01:28 CEST] <JEEB> the whole chromium and multiple processes thing got real funny when doing policy management
[00:01:48 CEST] <atomnuker> doesn't help its designed to run in multiple processes, so there's still more overhead than the browser itself probably
[00:02:36 CEST] <klaxa> i love how firefox quantum spawns dozens of processes
[00:02:39 CEST] <iive> atomnuker, extremely hard, especially when you have programming language that is compiled to native code and have to run fast.
[00:02:49 CEST] <klaxa> and i have to kill them by hand if it gets out of hand and i run low on ram
[00:03:06 CEST] <iive> atomnuker, there were demos of meltdown exploit, running in JS in browser.
[00:03:32 CEST] <iive> it was logging the keyboard, iirc.
[00:03:33 CEST] <JEEB> and how they fixed that is by making the JS timer APIs less good at counting
[00:03:55 CEST] <JEEB> (less precise)
[00:03:59 CEST] <rcombs> "fix" is a strong word
[00:04:02 CEST] <iive> and making JS threading harder, in case you run one thread as counter.
[00:04:29 CEST] <JEEB> rcombs: yes I noticed as I wrote it
[00:04:40 CEST] <JEEB> probably wrong word to utilize without a hard bit of sarcasm
[00:06:47 CEST] <atomnuker> iive: meltdown wouldn't have been an issue if javascript ran very slow
[00:07:14 CEST] <rcombs> most of my problems would not be problems if javascript ran very slow
[00:07:17 CEST] <wm4> I'm looking forward to using multiprocess firefox... because then I can hopefully reload a page to fix its never ending memory leaks
[00:07:26 CEST] <rcombs> because people wouldn't be building so much shit in it
[00:07:36 CEST] <wm4> but really a browser should just start a new process that includes even the GUI for new windows
[00:07:49 CEST] <wm4> konuqeror used to do that (RIP)
[00:08:12 CEST] <rcombs> I mean in practice javascript is very slow but not because of the language or engine
[00:08:26 CEST] <rcombs> since the JITs are really impressively good
[00:08:32 CEST] <rcombs> just people build such utter garbage in it
[00:08:47 CEST] <TD-Linux> webm/mp4 segments fed to MSE can be independent of GoPs and keyframes
[00:08:57 CEST] <rcombs> also somehow CSS is stupidly slow these days
[00:09:07 CEST] <TD-Linux> though DASH may have stricter rules, I dunno
[00:09:14 CEST] <rcombs> TD-Linux: yeah in theory but browsers handle it poorly if they don't
[00:09:25 CEST] <TD-Linux> yeah chrome was broken in particular for webm iirc
[00:09:55 CEST] <wm4> I wonder if they fixed CSS data leakage yet (if a CSS segment has a different image for mouseover, you can pretty much observe what a user is doing)
[00:10:36 CEST] <atomnuker> I wish there were more than 2 viable web browser engines
[00:10:37 CEST] <rcombs> you can write a keylogger in pure CSS
[00:10:48 CEST] <cone-800> ffmpeg 03Jerome Borsboom 07master:c0f154bba506: avcodec/vc1_pred: set ref_field_type earlier
[00:11:10 CEST] <atomnuker> right now its just webkit (used by everyone and their dog) and gecko (used only by firefox)
[00:11:36 CEST] <rcombs> because <input> puts its contents in the value field, CSS queries can key off of the last character in the value field, and a CSS query can make a request by setting background-image
[00:11:40 CEST] <iive> and firefox are replacing it
[00:14:25 CEST] <rcombs> with a more-oxidized version
[00:14:35 CEST] <atomnuker> https://en.wikipedia.org/wiki/Lunascape
[00:14:51 CEST] <atomnuker> lol, this uses 3 web engines - gecko, webkit and trident, apparently at once
[00:16:28 CEST] <atomnuker> I'd hate to think how big the binary is
[00:20:33 CEST] <wm4> Lunaticscape
[00:20:58 CEST] <wm4> what is the purpose
[00:21:17 CEST] <wm4> I guess it could have made sense 16 years ago?
[00:21:41 CEST] <klaxa> "it's not by microsoft google mozilla or apple"
[00:22:26 CEST] <wm4> not sure if that wouldn't be false advertising
[00:22:35 CEST] <BtbN> It also does one update per 2 years
[00:22:38 CEST] <BtbN> very secure browser
[00:22:56 CEST] <wm4> for trident it doesn't matter because it'll load it via COM
[00:23:40 CEST] <wm4> atomnuker: actually chrome doesn't use webkit
[00:23:52 CEST] <JEEB> yea, GOOG forked webkit
[00:23:56 CEST] <JEEB> quite a few years ago
[00:24:01 CEST] <wm4> I'm not sure whether what they use now is a fork or rewrite or a mix or whatever
[00:24:21 CEST] <JEEB> they forked and are doing their thing now
[00:24:32 CEST] <atomnuker> oh, right, blink
[00:24:36 CEST] <JEEB> yup
[00:25:17 CEST] <wm4> btw. I don't really understand how that works licensewise
[00:25:21 CEST] <iive> well, I guess the time has finally come
[00:25:27 CEST] <wm4> KHTML is apparently LGPL and the base for webkit
[00:25:32 CEST] <iive> for ffmpeg to implement their own web rendering engine
[00:25:43 CEST] <BtbN> also for fftls
[00:25:52 CEST] <BtbN> Because there aren't enough tls libraries yet
[00:26:40 CEST] <wm4> fftls would not be useful because it pulls in a libavutil rat-tail (and maybe lavf)
[00:28:07 CEST] <atomnuker> "These parts were altered for the Blink fork, and although made slightly bulkier, it allowed greater flexibility for adding new features in the future."
[00:28:34 CEST] <atomnuker> I think this isn't a browser engine now, its an experiment on how long can build times be increased before people give up
[00:29:47 CEST] <wm4> apparently google devs build chromium on very fast build servers
[00:30:57 CEST] <atomnuker> was it google who kept everything in one big git repo internally?
[00:31:06 CEST] <JEEB> yes, a build farm is pretty much required for chromium
[00:31:27 CEST] <iive> remember that blog : https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/  ?
[00:32:00 CEST] <klaxa> i think it was microsoft, didn't they make a git addon/extension so you can browse it without having to download everything?
[00:32:21 CEST] <JEEB> google also has a monorepo
[00:32:26 CEST] <JEEB> windows is just big
[00:32:59 CEST] <klaxa> https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/
[00:33:15 CEST] <klaxa> >As a refresher, the Windows code base is approximately 3.5M files and, when checked in to a Git repo, results in a repo of about 300GB.
[00:33:22 CEST] <JEEB> yes, windows is big - as I noted
[00:35:10 CEST] <nevcairiel> building chromum only takes like 3 hours on my $1000 CPU, whats the big deal =p
[00:35:36 CEST] <wm4> someone should tell MS that you're not supposed to put _everything_ into a single git repo
[00:36:09 CEST] <JEEB> well it's still not google, although it's not git but a fork of perforce or something else more homebrewn at this point
[00:38:23 CEST] <wm4> these things are by definition clusterfucks
[01:53:26 CEST] <KGB> [13FFV1] 15michaelni closed pull request #87: Change remaining_bits_in_bitstream to remaining_bits_in_block (06master...06blocks) 02https://git.io/vNvVU
[01:56:42 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vpYA7
[01:56:42 CEST] <KGB> 13FFV1/06master 14760bcfb 15Dave Rice: bump to version 02/00...
[05:34:18 CEST] <cone-969> ffmpeg 03Gyan Doshi 07master:9f9f56e6791f: avformat/segafilm - revert keyframe detection
[05:48:02 CEST] <Compn> what the heck
[05:48:07 CEST] <Compn> someone fixed an old bug i reported
[05:48:41 CEST] <Compn> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c0f154bba506e1cb609b1193632d452b89918a80
[05:49:23 CEST] <Compn> that never happens
[05:53:11 CEST] <Compn> a 5 year old bug
[05:53:17 CEST] <Compn> in vc1!
[06:07:23 CEST] <Compn> i remember there was a mozilla splinter group that wanted to do a new web browser
[09:40:36 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:c6d8492cffc4: doc/examples/hw_decode: Remove setting deprecated refcounted_frames
[09:40:36 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:0c28a5cf0fc6: doc/examples/filtering_video: Remove setting deprecated refcounted_frames
[09:40:36 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:f97fa89925a5: doc/examples/filtering_audio: Remove setting deprecated refcounted_frames
[09:41:13 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:c6d8492cffc4: doc/examples/hw_decode: Remove setting deprecated refcounted_frames
[09:41:14 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:0c28a5cf0fc6: doc/examples/filtering_video: Remove setting deprecated refcounted_frames
[09:41:15 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:f97fa89925a5: doc/examples/filtering_audio: Remove setting deprecated refcounted_frames
[12:01:07 CEST] <cone-283> ffmpeg 03Paul B Mahol 07master:5d3efe9e1f0b: avformat/dsfdec: properly handle padded last packet
[12:17:08 CEST] <kierank> jdarnley: does ffmpeg have thread pools?
[12:17:36 CEST] <jdarnley> What?  I've no idea.
[12:18:15 CEST] <jdarnley> Didn't somone propose it again recently?
[12:20:20 CEST] <wm4> it doesn't
[12:20:31 CEST] <wm4> it only creates a fixed number of worker threads in some components
[12:21:01 CEST] <wm4> which are not shared or anything
[12:34:13 CEST] <durandal_1707> iive is back!
[12:34:39 CEST] <rcombs> oD
ô§
[12:34:39 CEST] <iive> durandal_1707, and why is this news?
[12:38:05 CEST] <kierank> wm4: ah ok so the threads are at least kept for a given decoder being open
[12:38:38 CEST] <wm4> yeah, they create the requested thread count on open, and destroy them on close
[12:38:56 CEST] <wm4> seems like there are many people who'd like this to be more flexible
[12:52:48 CEST] <kierank> probably ok for us, dunno about other people use-case
[13:21:30 CEST] <cone-283> ffmpeg 03Paul B Mahol 07master:00099ef0d0dd: avformat/dsfdec: fix calculation of size of data chunk
[15:28:21 CEST] <atomnuker> why is configure.sh so fucking broken?
[15:28:51 CEST] <atomnuker> none of the checks are deterministic
[15:29:05 CEST] <wm4> do you mean our configure or something else
[15:29:10 CEST] <atomnuker> yes, our configure
[15:29:17 CEST] <atomnuker> I can enable something and it'll stay disabled
[15:29:32 CEST] <atomnuker> I can make a random change elsewhere and it'll be enabled
[15:29:49 CEST] <wm4> time for meson?
[15:30:07 CEST] <atomnuker> sure, but I still need to figure out what goes wrong here
[15:30:13 CEST] <wm4> (don't know if that'd improve it)
[15:30:15 CEST] <atomnuker> check_cc shaderc shaderc/shaderc.h "int t = shaderc_optimization_level_fuckmess" enable shaderc_opt_perf
[15:30:31 CEST] <atomnuker> no such enum exists yet shaderc_opt_perf is enabled
[15:30:42 CEST] <atomnuker> "enable vulkan" <- vulkan is kept disabled
[15:30:46 CEST] <atomnuker> nothing in configure.log either
[15:30:51 CEST] <atomnuker> it just stops
[15:30:58 CEST] <wm4> maybe shaderc_opt_perf is somehow enabled indepedently
[15:31:03 CEST] <atomnuker> no mention of vulkan after a successful check
[15:31:19 CEST] <wm4> also isn't there a && missing
[15:51:45 CEST] <atomnuker> that was it for that check, but the main vulkan check is still non-deterministic
[15:51:57 CEST] <atomnuker> enabled vulkan && check_pkg_config vulkan "vulkan >= 1.1" "vulkan/vulkan.h" vkCreateInstance
[15:54:41 CEST] <atomnuker> seems like its "vulkan/vulkan.h" failing when I paste that into pkg-config
[16:54:18 CEST] <ubitux> do we have auto-inserted scale filter for converting from hwaccelerated format to cpu (and back) yet?
[16:58:24 CEST] <nevcairiel> not auto-inserted i dont think
[17:01:08 CEST] <wm4> no
[17:01:38 CEST] <ubitux> ok, that's unfortunate, but i guess it could be changed
[17:04:43 CEST] <ubitux> jamrial: why did you need 234a5e08313c6b8b0774796dfa1f285a3f877d14?
[17:04:56 CEST] <ubitux> it should be enabled only with the linux target, and we have an android target (which doesn't enable it)
[17:05:37 CEST] <ubitux> (sorry, i'm late to the party)
[17:09:12 CEST] <atomnuker> ubitux: we don't by design
[17:09:36 CEST] <atomnuker> they're very slow in most cases so hiding them would be bad
[17:11:29 CEST] <ubitux> but filtergraph are supposed to be pixel-format agnostic
[17:11:41 CEST] <ubitux> it works in a constraint based model
[17:11:47 CEST] <wm4> ubitux: in practice they're agnostic to nothing
[17:12:07 CEST] <ubitux> well, "slow" scaler and resampler are auto inserted transparently already
[17:12:14 CEST] <wm4> even auto conversion won't change that
[17:12:47 CEST] <wm4> e.g. you need different filters based on the pixel format (like hw scaling, deint, other things)
[17:13:19 CEST] <ubitux> my point was that hw scaler should actually be auto-inserted
[17:13:43 CEST] <ubitux> just like it's done for the large sw pix format auto scaling 
[17:14:35 CEST] <ubitux> currently, whatever the video decoder outputs, i can insert a filter and it will work, unless somehow it involves hw acceleration
[17:14:42 CEST] <jkqxz> Auto-inserting hardware scalers requires negotiation of all the hardware frame properties inside libavfilter.
[17:14:52 CEST] <ubitux> if i have a decoder fallback mechanism, i'll have to construct different filtergraph
[17:15:09 CEST] <ubitux> which is unfortunate because it works for any sw decoder currently
[17:15:46 CEST] <jkqxz> Auto-inserting hwupload/hwdownload could work in some cases, but you need to know about the devices you have available to do it (and it might fail anyway because the thing after doesn't actually support whatever you uploaded to, because that isn't negotiated).
[17:15:47 CEST] <ubitux> jkqxz: what do you mean? i only know the apple CVPixelBuffer thing, which would be trivial to auto-insert
[17:18:03 CEST] <wm4> ubitux: negotiating the sw_format
[17:18:22 CEST] <wm4> i.e. underlying hardware format
[17:18:35 CEST] <wm4> and probably more, dunno
[17:18:43 CEST] <wm4> like number of preallocated frames
[17:19:04 CEST] <ubitux> yeah, maybe the underlying hw format would need some kind of mapping
[17:19:25 CEST] <ubitux> (assuming we want to have the "format" filter working for hw as well)
[17:19:34 CEST] <ubitux> might not be the best course of action though
[17:23:51 CEST] <ubitux> speaking of other areas; any progress on the thread naming, vt async decoder / pts re-ordering, or hevc SIMD from libav?
[17:24:34 CEST] <ubitux> or ordered chapters in mkv :°
[17:25:14 CEST] <JEEB> ordered chapters (virtual timelines got an RFC from derek
[17:25:18 CEST] <wm4> daemon404 has sent a RFC that would mp4 export editlists metadata, and which could used for mkv ordered chapters
[17:25:24 CEST] <wm4> +be
[17:25:28 CEST] <JEEB> yea
[17:25:35 CEST] <wm4>  vt async decoder <- no, it's fucked
[17:25:39 CEST] <nevcairiel> its questionable how much use the HEVC SIMD would even be, before merging someone w ould first have to figure out if its even worthwhile
[17:26:00 CEST] <jamrial> ubitux: some old android sdk on fate
[17:26:03 CEST] <wm4> maybe you could somewhat mess async decoding into the vt hwaccel now
[17:26:11 CEST] <ubitux> jamrial: with --target=android?
[17:26:22 CEST] <atomnuker> ubitux: nothing new on thread naming, I just need to dig up the patch again, which I'll get to, in between lavu fft/rdft/dct/mdct, finishing the atrac9 decoder and whatever else I forget
[17:26:31 CEST] <jamrial> ubitux: http://fate.ffmpeg.org/report.cgi?time=20180419100203&slot=mipsel-android-gcc-4.4
[17:26:34 CEST] <jamrial> looks like no
[17:26:36 CEST] <jamrial> michaelni: ^
[17:26:42 CEST] <ubitux> maybe that was the issue then
[17:27:04 CEST] <ubitux> atomnuker: and vulkan yeah
[17:27:05 CEST] <jamrial> sorry if that fix was unneccesary then :(
[17:27:13 CEST] <ubitux> no worry :)
[17:27:17 CEST] <jamrial> also wb, i missed you :p
[17:27:38 CEST] <ubitux> wm4: by the length of that mp4 timeline thread i'm assuming it's going to be full of drama
[17:27:49 CEST] <wm4> sure
[17:28:10 CEST] <wm4> but I think everyone agreed that somehow exporting it is a good idea
[17:28:41 CEST] <ubitux> jamrial: i hope to get back on a regular contribution habit, but that might be tricky (need to make a few choices)
[17:29:19 CEST] <jamrial> cool :)
[17:35:38 CEST] <atomnuker> ubitux: yeah well first I need to figure out how to compile that again
[17:35:44 CEST] <atomnuker> fucking configure
[17:36:03 CEST] <atomnuker> everything should be proper now and what worked before with the exact code doesn't anymore
[17:36:26 CEST] <atomnuker> adding those missing && fixed something for a few minutes but now vulkan's broken altogether
[17:36:30 CEST] <atomnuker> and I changed _nothing_
[17:37:46 CEST] <ubitux> do you have a configure diff somewhere?
[17:39:15 CEST] <jamrial> shouldn't adding vulkan to configure be as easy as copying what opencl does?
[17:39:37 CEST] <atomnuker> in theory even easier
[17:39:39 CEST] <atomnuker> and it is easy
[17:40:40 CEST] <ubitux> vulkan has various packages; typically developer layers can be found in external packages
[17:40:46 CEST] <ubitux> do you try to auto detect these?
[17:41:40 CEST] <ubitux> maybe i can help a little with the configure; though, i wasn't able to figure out a way to make it detect properly the pthread naming
[17:41:47 CEST] <atomnuker> no, I don't use layers
[17:41:54 CEST] <ubitux> (but that was because this non standardized shit has different prototypes with the same symbol name)
[17:42:11 CEST] <atomnuker> there are no optional functions like opencl, all the API is the same on all platforms
[17:42:19 CEST] <atomnuker> check_cpp_condition vulkan vulkan/vulkan.h "defined VK_API_VERSION_1_1"
[17:42:26 CEST] <atomnuker> what is the first argument for?
[17:42:36 CEST] <ubitux> can i see the whole configure diff?
[17:43:23 CEST] <ubitux> the first argument allows you to do "enabled vulkan && ..." in the future
[17:43:39 CEST] <atomnuker> OH COME ON, check_cpp_condition <crap> <stuff> && enable <subcomponent which depends on crap> disables <crap> if <subcomponent which depends on crap> fails
[17:44:09 CEST] <ubitux> check_cpp_condition will enable or disable `vulkan`
[17:44:34 CEST] <jamrial> atomnuker: do you want help, or do you want to complain? if the former, post a dam diff already
[17:45:08 CEST] <atomnuker> I can fix it now I know what's wrong
[17:45:20 CEST] <jamrial> and a simple "enable <subcomponent>" will not disable either <subcomponent> nor <crap>
[17:54:28 CEST] <atomnuker> ubitux: btw if you're bored and don't know what to do you could take a look at my exp_meson branch
[17:55:36 CEST] <atomnuker> it can compile all of lavu without any asm code for now
[18:03:27 CEST] <ubitux> atomnuker: yeah no being bored is not my main characteristic currently
[18:16:33 CEST] <kierank> atomnuker: why do you need lavu without asm?
[18:17:04 CEST] <JEEB> no, he just didn't figure out the templating of the asm define file
[18:25:13 CEST] <jamrial> atomnuker: your latest email seems to have been cut after the first line
[18:31:59 CEST] <atomnuker> tab (by mistake) + enter
[18:36:32 CEST] <atomnuker> oh wow a 26 part patchset
[18:39:01 CEST] <jkqxz> atomnuker:  If I want a newer Vulkan implementation than my distribution has then I need the ICD loader and headers from <https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers>?  Do I need anything else?
[18:44:04 CEST] <atomnuker> no, that's it
[18:46:51 CEST] <jkqxz> Should vulkaninfo show the 10-bit formats?  I don't see any support for them in anv or radv.
[18:48:03 CEST] <atomnuker> no, vulkaninfo isn't updated for the ycbcr format extension
[18:48:50 CEST] <atomnuker> I've just sent out a v2 of the patchset which builds correctly
[18:49:46 CEST] <atomnuker> it should run on your amd as well in theory, but only for rgb formats
[18:52:09 CEST] <cone-458> ffmpeg 03Martin Vignali 07master:e6e462586281: avcodec/prores_ks : use official quant_matrix (for proxy and xq codec luma and chroma quant matrix is not the same)
[19:04:41 CEST] <BBB> ubitux: nice to see you back :)
[19:16:24 CEST] <cone-458> ffmpeg 03Martin Vignali 07master:07a566e7d6fc: swscale/swscale_unscaled : add X86_64 (SSE2 and AVX) for uyvyto422
[19:54:13 CEST] <durandal_1707> one could export frame side data of first frame to lavfi?
[19:56:07 CEST] <durandal_1707> if it channges midstream, we are screwed already
[20:23:47 CEST] <ubitux> atomnuker: not sure if it applies in your case but you can use "%*c" with a ' ' argument to create indent with printf format
[20:23:51 CEST] <ubitux> (re: vulkan shader code)
[20:24:08 CEST] <ubitux> (instead of the chained INDENT macro)
[20:24:42 CEST] <ubitux> ffprobe typically makes use of this 
[20:29:05 CEST] <atomnuker> durandal_1707: what for?
[20:29:10 CEST] <ubitux> BBB: nice to see you still here ;)
[20:30:44 CEST] <durandal_1707> BBB is not very active though
[20:31:06 CEST] <BBB> several devs told me to go away, so Im staying away, yes
[20:31:34 CEST] <jamrial> huh?
[20:31:42 CEST] <durandal_1707> atomnuker: to manipulate side data, read/write it
[20:32:01 CEST] <atomnuker> you can do that already, can't you?
[20:32:15 CEST] <atomnuker> BBB: wut?
[20:32:38 CEST] <atomnuker> ubitux: most of those are in const char * tables, so can't really use them there
[20:32:42 CEST] <durandal_1707> atomnuker: but it is needed before you receive avframe, in config props
[20:33:21 CEST] <atomnuker> what filter needs to know the side data of the first frame for configuration?
[20:33:41 CEST] <durandal_1707> stereo3d, ambisonic, ...
[20:43:38 CEST] <wm4> atomnuker: we're a toxic community
[20:43:53 CEST] <wm4> and that has consequences
[20:46:55 CEST] <jamrial> i don't recall anyone telling BBB anything like that, though
[20:47:46 CEST] <jamrial> "test failed comparing 179.077 with 179.077 (abs diff=0.000106812 with EPS=0.0001)"
[20:47:47 CEST] <jamrial> :/
[20:48:08 CEST] <durandal_1707> BBB: i told carl and nicolas to leave, and they ignore me
[20:52:03 CEST] <atomnuker> durandal_1707: I think for ambisonics the channel layout field ought to be sufficient
[20:52:50 CEST] <atomnuker> there are 16 or so possible ambisonic layouts supported in the opus draft IIRC, and we're not near that limit
[20:53:04 CEST] <atomnuker> (of having no spare channel layout bits left)
[20:56:48 CEST] <JEEB> I think durandal_1707's topic spawned up from https://patchwork.ffmpeg.org/patch/6477/
[20:57:18 CEST] <JEEB> since someone in #mpv is asking why "just adding stereo3d doesn't work" (getting info from AVFrames)
[20:57:51 CEST] <BtbN> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228738.html what?
[20:58:23 CEST] <JEEB> yea, I just noticed that in my mail client too
[20:58:29 CEST] <JEEB> and my response was very similar
[21:06:37 CEST] <durandal_1707> "Hi there, i have a couple of suggestion for FFMPEG-DEV" ---> nice mushrooms consumption
[21:24:16 CEST] <kierank> michaelni: with the new async api, could we make h264 field coding return avframes of the field (i.e the frame with double stride)?
[21:25:17 CEST] <JEEB> in theory yea
[21:25:48 CEST] <JEEB> except everything pretty much expects interlaced pictures being in a single frame
[21:25:52 CEST] <JEEB> like lavfi
[21:26:06 CEST] <JEEB> (just look what happened with j2k or hevc, which return field pictures)
[21:27:07 CEST] <michaelni> kierank, if you want data with the lowest latency then slice or mb row based granularity might be even better
[21:27:24 CEST] <kierank> michaelni: sure but iirc that didn't work for h264
[21:28:05 CEST] <michaelni> yes its not completely trivial IIRC
[21:28:59 CEST] <iive> i've heard that h264 can have a slice in the form of chess board. that would be hard to output with slice output
[21:29:18 CEST] <iive> but we usually don't have such strange slices.
[21:30:44 CEST] <kierank> and anyway for fields it's still the same issue
[21:30:50 CEST] <kierank> that you render into a double stride frame
[21:31:00 CEST] <kierank> so draw_horiz_band would need to be aware somehow
[21:32:00 CEST] <Nethe> hi
[21:32:47 CEST] <Nethe> Guys, have a one question. I posted in on Stack overflow. Can you please check it and try to help me what is wrong? https://goo.gl/APHAJn
[21:33:14 CEST] <durandal_1707> Nethe: free user support is on another channel
[21:33:19 CEST] <cone-458> ffmpeg 03James Almer 07master:153e92089207: avformat/vpcc: add ff_isom_get_vpcc_features()
[21:33:46 CEST] <Nethe> durandal_1707: I tried #ffmpeg channel, but guys there don't know to help me ;/
[21:33:53 CEST] <nevcairiel> The most common reason for such an error is an too old driver anyway
[21:34:14 CEST] <Nethe> it is interesting, because i have latest cuda and latest nv-headers installed
[21:34:52 CEST] <nevcairiel> maybe thats your problem, the latest headers are extremely new, and drivers in your distribution may not have caught up yet
[21:36:18 CEST] <cone-458> ffmpeg 03Gyan Doshi 07release/4.0:6b2fee19a7dd: avformat/segafilm - revert keyframe detection
[21:36:52 CEST] <Nethe> nevcairiel: yes thats correct. Will try older version of headers.
[21:36:56 CEST] <Nethe> thanks for tip
[21:39:16 CEST] <durandal_1707> BBB: admit it, nobody told you anything, you are just FFmpeg lazy
[21:39:34 CEST] <BBB> sure
[21:41:46 CEST] <durandal_1707> need VC-1 expert(s)!
[21:42:14 CEST] <JEEB> was the reference encode pool available for that format?
[21:42:23 CEST] <JEEB> I know they kind of specified it in SMPTE
[21:44:31 CEST] <JEEB> old spec is http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf
[21:44:54 CEST] <JEEB> seems like there's something called VC-1 Decoder and Bitstream Conformance
[21:44:56 CEST] <JEEB> in SMPTE
[21:45:10 CEST] <JEEB> and then VC1_reference_decoder_release6.zip is the reference decoder
[21:45:43 CEST] <JEEB> ah https://multimedia.cx/mirror/
[21:46:09 CEST] <JEEB> also seems to have the 2006 spec?
[21:48:00 CEST] <durandal_1707> JEEB: you are VC-1 expert?
[21:48:29 CEST] <JEEB> no
[21:48:34 CEST] <JEEB> but I could feed you with spec and reference decoder
[21:49:11 CEST] <iive> kostya was the vc1 expert.
[21:52:00 CEST] <durandal_1707> iive was mplayer developer
[21:52:27 CEST] <durandal_1707> JEEB: i have already that all
[21:52:30 CEST] <JEEB> great
[21:52:38 CEST] <Nethe> nevcairiel: you were correct. The older version of headers helped. Thanks a lot and sorry for disturbing here with this trivial question. 
[21:52:49 CEST] <JEEB> and yes I know it's less than perfect if you have no reference sample set
[21:52:54 CEST] <JEEB> although I don't know the quality of it
[21:53:21 CEST] <iive> durandal_1707, what is the point of that?
[21:54:31 CEST] <durandal_1707> michaelni: see this security bug: libavcodec/vc1_block.c:748:31: runtime error: index 368 out of bounds for type 'int16_t [16]' , happens with samples from fate
[21:54:53 CEST] <durandal_1707> iive: stating obvious info
[21:55:06 CEST] <iive> durandal_1707, so you are trolling me?
[22:03:54 CEST] <wm4> why are you upset by the truth
[22:05:12 CEST] <iive> wm4, are you talking to me?
[22:05:39 CEST] <JEEB> I'm not sure what durandal_1707 is trying but wm4 please - do not fall onto his level
[22:06:22 CEST] <JEEB> not sure how his behavior is called in English, although it is often being called "being 'clever'"
[22:07:14 CEST] <wm4> I have no idea what is going on here
[22:08:07 CEST] <JEEB> he didn't seemingly like me linking obvious things (the spec and the reference decoder), and thus he started being snarky again
[23:14:25 CEST] <klaxa> ah right, i've been thinking about this for some time now: right now it's not possible to get the address of a remotely connected tcp socket through public api
[23:14:56 CEST] <klaxa> i think that could be useful/necessary for logging in ffserver?
[23:15:39 CEST] <klaxa> or i am missing it
[23:45:35 CEST] <durandal_1707> i you guys apply rmhd wrapper i'm leaving for sure
[23:47:50 CEST] <jamrial> durandal_1707: what is wrong with it?
[23:50:09 CEST] <durandal_1707> i do not like non free wrappers in general
[23:50:24 CEST] <durandal_1707> what's next mediacodec and dshow support?
[23:50:46 CEST] <JEEB> dshow and mf are actually OS things, so wouldn't those be excempt from the GPL things?
[23:51:07 CEST] <JEEB> since generally calling nonfree OS libraries seems kosher from the GPL standpoint even
[23:51:34 CEST] <JEEB> (just like the QT APIs are not nonfree on mac, even though they're also available on windows - which requires installation of QT separately)
[23:51:37 CEST] <jamrial> durandal_1707: considering we already support those, i assume you're being sarcastic?
[23:51:40 CEST] <durandal_1707> lets he add that crap to gstreamer
[23:53:33 CEST] <j-b> durandal_1707: you meant MediaFoundation, not MediaCodec, right?
[23:53:56 CEST] <KGB> [13FFV1] 15michaelni tagged 06draft-ietf-cellar-02 at 06master: 02https://git.io/vpO6q
[23:54:09 CEST] <jamrial> durandal_1707: de/muxer code can and should go in, assuming no technical problesm are found
[23:54:12 CEST] <jamrial> they don't depend on any external library
[23:54:22 CEST] <durandal_1707> j-b: yes, i will than add alac, ape and flac wrapper too
[23:54:25 CEST] <jamrial> and we support demuxing all kinds of proprietary shit
[23:55:04 CEST] <j-b> durandal_1707: can I ask why? You prefer everything native?
[23:55:24 CEST] <durandal_1707> i don't like non-linux wrappers
[23:55:25 CEST] <kierank> I agree with durandal_1707 
[23:55:47 CEST] <j-b> durandal_1707: non-linux? why is flac non-linux?
[23:55:59 CEST] <JEEB> lol, RMHD actually has a lunix SDK
[23:56:04 CEST] <j-b> I mean, I understand your objection to dshow, MF or rmhd
[23:56:09 CEST] <j-b> but alac, flac?
[23:56:09 CEST] <JEEB> so "non-linux wrappers" doesn't match
[23:56:22 CEST] <JEEB> and yes, there's the nonfree aspect which I understand
[23:56:25 CEST] <j-b> yeah, the non-linux confuses me.
[23:56:33 CEST] <durandal_1707> and optimfrog, and tak, they both have windows sdk
[23:56:46 CEST] <JEEB> ok, are you just derping around?
[23:57:00 CEST] <JEEB> just like when I tried helping you with the basics of VC-1 which clearly weren't helpful enough
[23:57:27 CEST] <JEEB> you have something in your mind that you clearly want to let out - please try to focus and put it out coherently
[23:57:31 CEST] <durandal_1707> anything under the sun that have sdk, i will write wrapper for ffmpeg, i will smile for eternity how that will be maintained
[23:57:32 CEST] <atomnuker> yeah, I kinda feel like rmhd should instead be RE'd (or better yet open sourced) the hevc decoder modified to support it (I think its based on it)
[23:57:52 CEST] <j-b> Does Kostya still live?
[23:57:54 CEST] <JEEB> yea, according to kostya's initial checks
[23:57:58 CEST] <j-b> He could RE it.
[23:58:30 CEST] Action: durandal_1707 back on fixing VC-1
[23:59:11 CEST] <JEEB> https://codecs.multimedia.cx/2017/10/rmhd-a-more-detailed-look/
[00:00:00 CEST] --- Mon Apr 23 2018