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

[burek]

[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/93ccba96df6340249b0db227d5bc3297010797a4
[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