[00:17:06 CET] <wm4> Compn: can you please ban michaelni from the mailing list? he's trolling me again [00:24:32 CET] <jamrial> just drop it [00:25:23 CET] <iive> is he? [00:29:34 CET] <BBB> no hes not [00:30:00 CET] <BBB> but I can see wm4s point if you subtract the trolls [00:30:12 CET] <BBB> I think I agree with the background of it, but the message could be packed better [00:30:34 CET] <kierank> the idea is insane [00:30:42 CET] <kierank> streaming c structs over the network [00:30:55 CET] <wm4> streaming internal ffmpeg state over network [00:31:03 CET] <wm4> isn't that just ffserver anyway [00:31:08 CET] <wm4> which we all love so much [00:31:34 CET] <jamrial> yeah, and it and ffm are being removed, so not something to consider for a future side data api [00:31:45 CET] <BBB> still not removed? [00:31:58 CET] <BBB> 4 weeks ago it would be pushed next week [00:32:02 CET] <BBB> just push it [00:32:06 CET] <BBB> youll piss off some people [00:32:10 CET] <BBB> well move on, as we always do [00:32:29 CET] <BBB> libmpcodecs anyone? [00:32:39 CET] <BBB> or what was it, libmpfilters, I dont remember [00:33:51 CET] <wm4> libmpcodecs [00:34:02 CET] <wm4> though only the video filter part was (insanely) copied into ffmpeg [00:34:09 CET] <wm4> took half a decade to cleanup [00:34:44 CET] <michaelni> kierank, i do NOT want to stream any internal structs, i think my point is a bit misrepresented here. [00:34:53 CET] <wm4> I think libmpcodecs in mplayer also contained video and audio decoders [00:35:05 CET] <kierank> "If you have an application that streams video, and on a different computer [00:35:06 CET] <kierank> an application which plays that video you need to transfer the compressed [00:35:06 CET] <kierank> data (that is AVPackets and their side data) over the network." [00:36:12 CET] <thardin> there's no container that covers every use case maybe [00:36:30 CET] <BBB> there is, its called ffm [00:36:41 CET] <thardin> right [00:36:41 CET] <michaelni> what i mean really is the data to fully reconstruct the intended presentation. alot of this is in side data currently, i do not want any internal structs to be passed around [00:36:44 CET] <BBB> although that was never updated since 2005 so it didnt actually cover side-data [00:36:48 CET] <BBB> but it could :) [00:37:08 CET] <BBB> (not that we should keep ffm, it was horrible, as most such containers are when they try to do everything) [00:37:16 CET] <thardin> are any guarantees given about it or is it just "you have to use the same version of ffmpeg on both ends" [00:37:36 CET] <BBB> michaelni: if you want serialization/deserialization, I think people would say that makes sense, but thats not what it sounded like ;) [00:37:38 CET] <kierank> michaelni: and how do you account for endian? [00:37:50 CET] <kierank> in this bizzare world where you stream c structs over the network [00:38:04 CET] <michaelni> kierank, i do NOT want to stream c structs [00:38:17 CET] <thardin> kierank: easy, you do what quake does [00:38:25 CET] <thardin> it has a little endian flipping thing [00:38:36 CET] <wm4> I guess it boils down to michaelni's reply to me being some sort of non-sequitur (aka I misunderstood everything!) [00:38:44 CET] <iive> michaelni: if data is to be send over network, streaming, structs should be both packed and in network endian format (don't remember big or little ending is used by TCP/IP) [00:39:22 CET] <michaelni> BBB, serialization/deserialization, is one of several possibilities probably the one that makes most sense [00:39:28 CET] <iive> and that is something that would make internal use slower. [00:39:53 CET] <iive> michaelni: imho, you went few steps too far with brainstorming. [00:40:26 CET] <BBB> michaelni: thats very reasonable. I think what you sent to the ML suggested that you wanted something more & ser/deser is fine I think [00:40:56 CET] <michaelni> BBB, yes it seems people read something in my mail that i did not intend it to mean at all [00:41:28 CET] <kierank> michaelni: so what has serialisation and deserialisation go to do with that patch? [00:42:02 CET] <wm4> nice cehoyos post [00:42:44 CET] <michaelni> kierank, nothing, the thread drifted off topic as a new side data api was suggested and then drifted to network protocols [00:43:05 CET] <thebombzen> how is this not just another competing standard to mpegts [00:43:22 CET] <kierank> thardin: more insane, it's like mxf [00:43:47 CET] <kierank> michaelni: you raised the networking part [00:43:50 CET] <wm4> it's like... ffm [00:45:42 CET] <wm4> michaelni: so what was your point of your reply? you're free to write as many serializers/deserializers as you want in your streaming protocol implementation [00:45:45 CET] <BBB> lets leave this subject behind guys [00:45:49 CET] <BBB> michaelni says he didnt mean it [00:45:56 CET] <wm4> he always says that [00:45:57 CET] <BBB> we were trying to convince him to not mean that [00:46:01 CET] <BBB> so were in agreement [00:46:07 CET] <BBB> lets settle on that and move on [00:46:11 CET] <BBB> <3 [00:46:21 CET] <wm4> next time I'll just ignore any invalid points he raises, including in patch reviews [11:58:56 CET] <jdarnley> Oh. The intel official timing document lists actual throughput rather than reciprical throughput. [12:05:33 CET] <atomnuker> thealexbarney: hey, know which games use atrac9 and on which platforms? [12:30:14 CET] <durandal_1707> atomnuker: really? shame of you [12:30:58 CET] <atomnuker> just asking [12:31:08 CET] <jdarnley> What the heck? Am I blind or am I starting to see more and more errors in the intel instruction reference? [12:31:46 CET] <durandal_1707> atomnuker: ps vita, if you use brain cells you can get full rips of game [12:32:21 CET] <atomnuker> I wish there was a vita emulator too but hey, maybe with this decoder it'll be a step closer [12:36:05 CET] <durandal_1707> atomnuker: there is binary encoder [12:46:47 CET] <jdarnley> dammit! why can't I just make thse instructions be vex encoded. I don't need run-time op masks [13:00:44 CET] <durandal_1707> whos gonna write simple yuv444 asm for overlay filter? [13:05:48 CET] <jdarnley> I might volunteer but I have a large backlog of stuff to finish both for work and my own. [13:09:39 CET] <JEEB> atomnuker: I think the vita and PS4 use it [13:10:01 CET] <JEEB> you get samples in all games because the menu selection BGM etc is in that format, IIRC [14:15:51 CET] <jdarnley> Wow, what? vpmullq is faster than vpmulld? [14:17:51 CET] <durandal_1707> jdarnley: in which case/code? [14:18:28 CET] <jdarnley> No, just according to the intel timing document [14:18:53 CET] <durandal_1707> heh [14:19:15 CET] <jdarnley> 5 cycle latency vs 10 [14:19:30 CET] <jdarnley> and throughput of 1 vs 0.66 [14:25:39 CET] <shinchiro> sfan5: since you're the one who add libtls support in ffmpeg, I noticed the pkg-config detection doesn't work correctly [14:26:30 CET] <shinchiro> it used use_pkg_config but the function doesn't exist in configure [14:34:40 CET] <RiCON> it used to be use_pkg_config, now it's check_pkg_config, iirc [14:38:47 CET] <sfan5> RiCON: nope that wasn't touched since 2014 [14:39:15 CET] <sfan5> yup that seems like my fault, I never noticed due to the non-pkgconfig fallback I added [14:39:20 CET] <sfan5> will send a fix to the ML later today [14:40:11 CET] <shinchiro> nice [14:42:10 CET] <RiCON> sfan5: https://github.com/FFmpeg/FFmpeg/commit/93ccba96df6340249b0db227d5bc32970107... [14:42:36 CET] <sfan5> huh what [14:42:44 CET] <sfan5> maybe I'm just too stupid to use git blame [14:43:15 CET] <RiCON> CLI, sure, github's easier [14:52:14 CET] <Compn> when github ipo? :P [15:35:02 CET] <jdarnley> If someone is silly enough to use 32-bit code on an AVX-512 cpu, can they access all 32 SIMD registers with that EVEX encoding? [15:36:29 CET] <jdarnley> I don't plan to write anything like that, I was just curious. [15:41:03 CET] Action: funman throws a pre-MMX pentium at jdarnley [15:42:33 CET] Action: durandal_1707 silently puts some insult in patch code so Compn can not find it [15:50:54 CET] <jdarnley> Ah ha! The m64bcst I asked about yesterday is explained in Intel's Optimization Reference Manual, section 15.9 [15:58:21 CET] <BBB> are we using atomic integers in ER? [15:59:14 CET] <atomnuker> yes [15:59:30 CET] <BBB> ... [16:04:43 CET] <atomnuker> what? [16:12:12 CET] <wm4> what for [16:12:51 CET] <Chloe> ER? [16:14:10 CET] <wm4> error recovery or something [16:14:16 CET] <wm4> no, some other term [16:15:23 CET] <atomnuker> error recovery [16:16:48 CET] <wm4> error reslience [16:17:00 CET] <wm4> error resilience [16:17:20 CET] <wm4> (so, slightly more fancy term, lol) [16:40:35 CET] <thealexbarney> atomnuker: Many PS4 and PS Vita games use ATRAC9. [16:41:08 CET] <thealexbarney> Here's a non-exhaustive list of download links: https://pastebin.com/raw/Lk9aA5EK [16:41:47 CET] <thealexbarney> These all use the AT9 container, although there are others containing ATRAC9 as well [17:04:50 CET] <daddesio> thealexbarney: did you reverse-engineer AT9? The first result on google for "atrac9 decoder" is your repo. [17:07:13 CET] <daddesio> ah, I scrolled up [17:07:16 CET] <daddesio> "11:44 <thealexbarney> atomnuker, there are a few things I haven't gotten around to adding to that spec. I'm also available to clarify anything, although I probably won't be on IRC too much. Most of my knowledge of audio coding techniques comes from RE'ing the HCA and ATRAC9 codecs over the past ~half-year with no outside help, so I wouldn't be surprised if there were some oddities in the source because [17:07:18 CET] <daddesio> of that. [17:07:20 CET] <daddesio> " [17:07:32 CET] <daddesio> noice [17:09:47 CET] <atomnuker> thealexbarney: oh wow, thanks, didn't expect to see full links [17:39:48 CET] <Gramner> jdarnley: no, additional vector regs are x86-64 only [17:40:09 CET] <jdarnley> poor 32-bit bastards [17:40:12 CET] <Gramner> but you can use x32! /s [17:40:56 CET] <rcombs> 32-bitstards [17:42:39 CET] <iive> you can use x32 on x64 [17:43:00 CET] <iive> ;( [18:07:01 CET] <RiCON> sfan5: isn't it check_pkg_config? require_pkg_config will die() if it fails, iirc [18:08:00 CET] <sfan5> *sigh* yes, indeed [18:13:48 CET] <jamrial> sfan5: i'll ammend it and apply it [18:13:57 CET] <sfan5> too late i already sent a fixed patch [18:13:57 CET] <jamrial> no need to send a new patch [18:14:01 CET] <jamrial> alright [18:14:02 CET] <sfan5> ¯\_(Ä)_/¯ [18:15:15 CET] <jamrial> why the fallback anyway? if pkg-config is available for every supported version of the library, then there's no point in having the fallback [18:15:50 CET] <jamrial> it will only generate issues with static builds if libtls needs system libraries like pthreads [18:17:43 CET] <jamrial> yeah, look at this https://github.com/libressl-portable/portable/blob/master/libtls.pc.in [18:18:06 CET] <jamrial> static builds are pretty much guaranteed to not work with the fallback check [18:19:56 CET] <cone-349> ffmpeg 03sfan5 07master:b178278c7b4b: configure: fix pkg-config check for libtls [18:44:43 CET] <Compn> durandal_1707 : you may want to look how you reacted to 1 hour of mailing list moderation... [18:45:47 CET] <durandal_1707> Compn: huh? [19:02:59 CET] <Compn> durandal_1707 : i only hit the moderate button for 1 hour... [19:13:37 CET] <cone-349> ffmpeg 03sfan5 07master:b1781caf9e36: configure: remove libtls fallback check [19:35:56 CET] <durandal_1707> Compn: i wrote new patch, but cant send because of you. resign from your positions immediately! [19:57:03 CET] <Compn> durandal_1707 : moderation stopped one hour after that mail i sent [19:57:07 CET] <Compn> yesterday [19:58:40 CET] <durandal_1707> we must strip you from such powers so this does not happen again [20:00:40 CET] <Compn> durandal_1707 : i hope that you also find more ml admins :) [20:02:54 CET] <Compn> the exciting world of .... administering mailing lists [20:03:03 CET] <Compn> and sorting spam [20:37:46 CET] <durandal_1707> clueless people reinventing same stuff over and over again [20:57:16 CET] <cone-349> ffmpeg 03Martin Vignali 07master:f2e9156eb62b: avcodec/utvideodec : use gradient_pred dsp in interlace decoding [20:57:17 CET] <cone-349> ffmpeg 03Martin Vignali 07master:c76cf303ce11: avcodec/magicyuv : use gradient_pred dsp func for 8 bits gradient mode [20:57:51 CET] <durandal_1707> \Ë/ [21:02:55 CET] <cone-349> ffmpeg 03Martin Vignali 07master:d31770d9a603: avfilter/vf_interlace : move func init in ff_interlace_init and add depth arg for ff_interlace_init_x86 [21:02:56 CET] <cone-349> ffmpeg 03Martin Vignali 07master:adff97be5e2f: checkasm/vf_interlace : add test for lowpass_line 8 and 16 [21:02:57 CET] <cone-349> ffmpeg 03Martin Vignali 07master:1a5865b6dcc9: avfilter/vf_interlace : add AVX2 for lowpass_line 8 and 16 [21:02:58 CET] <cone-349> ffmpeg 03Martin Vignali 07master:8fb1d63d9192: avfilter/vf_tinterlace : add AVX2 func for lowpass_line 8 and 16 [21:12:07 CET] <cone-349> ffmpeg 03Martin Vignali 07master:a4a4179e83e6: avfilter/x86/vf_hflip : merge hflip byte and hflip short to one macro [21:12:08 CET] <cone-349> ffmpeg 03Martin Vignali 07master:f181648176c0: avfilter/x86/vf_hflip : add avx2 version for hflip_byte and hflip_short [21:12:09 CET] <cone-349> ffmpeg 03Martin Vignali 07master:3df6e61dad85: avfilter/x86/vf_hflip : indent [21:14:29 CET] <durandal_1707> awesome [21:18:56 CET] <cone-349> ffmpeg 03Felix Matouschek 07master:c12c2739cd1e: configure: Fix detection of vp9 decoder/encoder [21:32:45 CET] <cone-349> ffmpeg 03Jun Zhao 07master:2b38900cb377: tests/audiomatch: Add return value check for fread. [21:32:46 CET] <cone-349> ffmpeg 03Jun Zhao 07master:e72b8549920f: tests/audiomatch: Whitespace refinement [21:32:47 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:65da5c56e661: tests/audiomatch: Add missing return code at the end of main() [21:43:58 CET] <jamrial> the vf_interlace patches above broke fate [21:49:50 CET] <sadasdas> Hello [21:49:54 CET] <sadasdas> +seen burek [23:08:23 CET] <cone-349> ffmpeg 03James Almer 07master:8e0e4384b097: Revert "avfilter/vf_interlace : add AVX2 for lowpass_line 8 and 16" [23:08:24 CET] <cone-349> ffmpeg 03James Almer 07master:da032427786d: Revert "checkasm/vf_interlace : add test for lowpass_line 8 and 16" [23:14:08 CET] <Chloe> why do all those commits have spaces after the path [23:15:23 CET] <nevcairiel> Because the author put it there? :) [23:15:49 CET] <Chloe> nevcairiel: :( [23:16:27 CET] <nevcairiel> I don't think there is any better answer [00:00:00 CET] --- Wed Dec 20 2017