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

[burek]

[00:00:55 CET] <jamrial> a quick look shows that vorbisdec also inits get_bits on the avpacket buffer, so i think it's safe to assume padding is present
[00:33:19 CET] <kierank> Sesse: also you should be using checked bitstream reader
[00:33:38 CET] <Sesse> kierank: I am, it is the default
[00:33:48 CET] <kierank> ok
[00:33:53 CET] <Sesse> kierank: but even the checked bitstream reader can read a few bytes past the end
[00:33:57 CET] <kierank> yeah
[00:34:17 CET] <Sesse> unfortunately, there's no good way of having it return an error, it just keeps replaying the same byte
[00:34:20 CET] <Sesse> but that's fine
[00:34:34 CET] <kierank> yes
[00:34:36 CET] <kierank> sadly
[01:00:29 CET] <atomnuker> yes, there's no problem with reading directly from avpkt->data, there will be padding
[01:01:05 CET] <atomnuker> eliminating memcpys and memsets is by far the single most important optimization which is not at all premature that someone should do
[01:01:12 CET] <Sesse> atomnuker: it would be nice if this were documented on avpkt
[01:01:22 CET] <Sesse> or the decode function
[01:01:35 CET] <Sesse> (the function pointer, not just the thing that calls the decode pointer)
[01:02:14 CET] <atomnuker> patch welcome
[01:02:31 CET] <atomnuker> avpkt->data is also allowed to be larger than what avpkt->size says
[01:02:38 CET] <Sesse> sure, that makes sense
[01:02:42 CET] <Sesse> it's C, after all
[01:02:43 CET] <atomnuker> no, I meant for encoding
[01:03:15 CET] <atomnuker> some encoders always allocate the full maximum packet size and just set avpkt->size to what they need
[01:03:55 CET] <atomnuker> that way they save on a memcpy at the cost of a slightly larger heap
[01:08:17 CET] <Sesse> it's an optimization everybody loves to do :-)
[01:08:18 CET] <Sesse> less cpu for more ram
[01:08:27 CET] <Sesse> the problem is that everybody makes the same optimization :-/
[01:08:42 CET] <Sesse> so you have tons of free cpu and always too little RAM
[01:08:55 CET] <Sesse> (okay, that's not universally true)
[01:09:44 CET] <iive> usually the opposite is true ;)
[01:09:51 CET] <iive> unless you run java
[01:11:02 CET] <iive> also, afair, realloc is guaranteed to use the same buffer if you shrink it.
[01:15:01 CET] <atomnuker> it can also save on a ton of complexity and bugs
[01:15:14 CET] <atomnuker> I wish I knew it when I wrote the vc2 encoder
[01:20:02 CET] <atomnuker> BBB: didn't you AVX2 the VP9 loopfilter?
[01:20:27 CET] <BBB> not yet, there didnt seem to be a huge demand
[01:20:32 CET] <BBB> and I had other things to do
[01:20:36 CET] <BBB> so I left it for later
[01:23:22 CET] <atomnuker> yeah, as soon as you finish optimizing 1 part another function will take its place in perf
[01:24:51 CET] <BBB> well, thats ok
[01:25:04 CET] <BBB> its more that loopfilter is kidna unimportant except for trivial content where nothing is really important
[01:25:12 CET] <BBB> for harder content, its mostly idct/mc
[01:25:19 CET] <BBB> and of course bitstream parsing
[01:25:49 CET] <BBB> so & yes you can get 1% with avx2/lpf& but really & Id rather write an encoder or start messing with av1 or so
[01:32:40 CET] <Sesse> or how about an sse2 idct :-P
[01:32:55 CET] <cone-527> ffmpeg 03Jun Zhao 07master:b53b3a4f6abc: lavc/vaapi_encode_h264: disable B frames in baseline profile
[01:36:50 CET] <BBB> Sesse: for vp9? already have that
[01:36:58 CET] <BBB> Sesse: and I wrote one for prores also
[01:37:07 CET] <BBB> Sesse: yours is identical, so just adapt the prores one and youre good
[01:41:40 CET] <Sesse> BBB: why is simple_idct not sse2?
[01:41:53 CET] <Sesse> surely the default idct ought to be
[01:42:14 CET] <Sesse> and why are there two different prores encoders
[01:42:21 CET] <Sesse> and decoders
[01:42:48 CET] <BBB> yes indeed, why
[01:42:50 CET] <kierank> LOL
[01:43:04 CET] <kierank> Sesse: fork bullshit
[01:43:04 CET] <BBB> Sesse: you ask the right questions
[01:43:17 CET] <BBB> Sesse: if you knew, youd probably run away scared or worse
[01:43:19 CET] <Sesse> BBB: something tells me there are no answers
[01:43:23 CET] <Sesse> ah
[01:43:27 CET] <BBB> Sesse: theres no reason
[01:43:29 CET] <BBB> theres a history
[01:43:29 CET] <Sesse> I'd tell you, but I'd have to kill you
[01:43:31 CET] <BBB> no
[01:43:45 CET] <BBB> Id tell you, but youd be convinced Im clinically insane"
[01:43:51 CET] <Sesse> close enough
[01:43:54 CET] <Sesse> anyway, prores idct is 10-bit output
[01:43:57 CET] <Sesse> I have 8-bit output
[01:44:06 CET] <BBB> the idct isnt fundamentally differen
[01:44:08 CET] <BBB> +t
[01:44:12 CET] <Sesse> newtek claims speedhq/ndi can deal with 10- and 12-bit output
[01:44:19 CET] <Sesse> and maintains 16-bit precision or better all along
[01:44:19 CET] <BBB> maybe it can
[01:44:23 CET] <Sesse> although I think the latter is a lie :-)
[01:44:32 CET] <BBB> easy enough to test if we have samples
[01:44:33 CET] <kierank> Sesse: the part about generation loss i think isn't possible
[01:44:37 CET] <Sesse> BBB: there are none
[01:44:45 CET] <BBB> well& thats problematic :)
[01:44:45 CET] <Sesse> kierank: they reportedly have a sample in their sdk to tes tit
[01:45:01 CET] <kierank> interesting
[01:45:22 CET] <kierank> it would require some defined metric for a downstream encoder to use
[01:45:27 CET] <kierank> so it chooses the correct quantiser
[01:45:36 CET] <Sesse> I guess they just lock it
[01:45:37 CET] <kierank> and perhaps also the same dct
[01:45:42 CET] <Sesse> and yes, dct and idct have to match
[01:45:51 CET] <Sesse> and somehow be precise enough, I guess
[01:45:54 CET] <Sesse> I don't know the details
[01:46:10 CET] <Sesse> it's certainly possible with h264 intraframe, since it's specified exactly
[01:46:19 CET] <Sesse> ie., no loss in the transform
[01:46:42 CET] <kierank> If SRC -> A -> B -> C, vc-2 claimed that A and B were same but there was a bug and it was B/C etc
[01:46:57 CET] <outcast> Hi can I ask help for a ffmpeg build with custom libraries , i can pastebin the config options. ?
[01:47:43 CET] <outcast> http://pastebin.com/Wa3SthpS
[01:48:21 CET] <Sesse> kierank: I don't know if they claim A -> B or just convergence at some point
[01:48:36 CET] <kierank> convergence at some point is feasible
[02:09:11 CET] <Chloe> Will ffmpeg ever get irc cloaks? 
[02:10:18 CET] <BtbN> freenode does not do irc cloaks anymore.
[02:10:34 CET] <BtbN> Only legacy ones still exist.
[02:10:59 CET] <jkqxz> Just get a better hostname.
[02:16:54 CET] <Chloe> I asked in #freenode apparently they do
[02:19:07 CET] <BtbN> they still hand out cloaks, but the ones I have, the unafiliated ones.
[02:19:30 CET] <BtbN> They don't register new community cloaks anymore. Unless that policy changed again recently.
[02:20:39 CET] <Chloe> I asked about project cloaks they said they do
[02:21:45 CET] <BtbN> interesting
[02:22:01 CET] <BtbN> Last time I checked up on that their website said they don't do that anymore.
[02:23:14 CET] <Chloe> It may be something to look into :) 
[02:32:03 CET] <BtbN> someone should fix their client.
[02:32:04 CET] <Compn> Chloe : you want an ffmpeg cloak? :D
[02:32:28 CET] <Chloe> Maybe :p
[02:32:56 CET] <Compn> ok maybe i should ban him temporarily
[02:33:54 CET] <Chloe> Forward them to ##fix-your-connection or something 
[02:34:02 CET] <Compn> no idea how to do that
[02:34:52 CET] <BtbN> mode f or something
[02:35:22 CET] <Chloe> Append $##fix-your-connection to the ban
[02:35:54 CET] <Chloe> /mode -b dlb76*@*
[02:36:14 CET] <Chloe> /mode +b dlb76*@*$##fix-your-connection 
[02:37:42 CET] <BtbN> that's not the right hostmask
[02:39:00 CET] <Chloe> Got there eventually 
[02:39:19 CET] <Chloe> >.<
[02:40:35 CET] <Chloe> Compn: but yeah, hit me up if they become a thing
[04:54:09 CET] <cone-776> ffmpeg 03Wang Bin 07master:0e8b68a2c403: avutil/tile: check clock_gettime at runtime for apple platforms
[05:14:59 CET] <wm4> the fuck
[05:15:13 CET] <wm4> isn't according to C spec the address of a function alwass non-0
[05:15:18 CET] <wm4> *always
[06:58:18 CET] <Compn> Sesse : did you try with fullsize 1080 frames?  even if slower and using more ram that would be more interesting fuzz sample imo
[09:33:54 CET] <Sesse> Compn: no, didn't try. fuzzing prefers small targets.
[09:36:10 CET] <durandal_170> your code is perfect, there is nothing to fuzz
[10:12:11 CET] <ubitux> any reason the merges stopped at:
[10:12:13 CET] <ubitux> 0ac2d86c47 dxva2: Factorize DXVA context validity test into a single macro
[10:12:15 CET] <ubitux> f8a42d4f26 dxva2: Make ff_dxva2_get_surface() static and drop its name prefix
[10:12:17 CET] <ubitux> ?
[10:12:38 CET] <ubitux> btw, ETA: 800+ commits to merge
[10:12:49 CET] <ubitux> i'm willing to work on it for a few days
[10:13:05 CET] <ubitux> DXVA is not something i can test though
[10:13:43 CET] <atomnuker> meh, what's there to merge
[10:14:15 CET] <ubitux> atomnuker: http://sprunge.us/DXXd
[10:21:12 CET] <atomnuker> meh
[10:22:12 CET] <atomnuker> I am also NAKing their bitstream reader API, I prefer get_bits
[10:27:01 CET] <kierank> Apart from their stupid rename, they have big speed improvements for reading
[10:31:13 CET] <Sesse> a bit surprising, perhaps; how can you improve on a simple table lookup
[10:34:18 CET] <wm4> I can test dxva
[10:39:16 CET] <atomnuker> Sesse: not for vlcs, just raw bit reading
[10:39:37 CET] <Sesse> atomnuker: even more so then, I suppose
[10:40:21 CET] <atomnuker> increased cache size from 32 to 64, that's all
[10:40:31 CET] <Sesse> well, okay, that's worthwhile
[10:41:00 CET] <atomnuker> well, perhaps, it'll probably perform worse
[10:41:11 CET] <atomnuker> (on non 64 bit x86 arches)
[10:41:20 CET] <Sesse> suppsoedly it needs to be #ifdef-ed?
[10:41:28 CET] <Sesse> there's already multiple readers in there, afaics
[10:41:49 CET] <atomnuker> nope, there's only one rawbits reader in our codebase
[10:42:16 CET] <atomnuker> with 2 switches
[10:42:45 CET] <atomnuker> (for endianess and unchecking)
[10:42:48 CET] <Sesse> what's LONG_BITSTREAM_READER?
[10:43:36 CET] <atomnuker> extends the cache from 25 to 32
[10:43:54 CET] <Sesse> so basically always needs the cache to be filled?
[10:45:01 CET] <atomnuker> yeah, you read some bits, you empty the cache, you fill it up
[10:45:43 CET] <atomnuker> either way rawbits reading speed is more irrelevant today
[10:46:27 CET] <atomnuker> entropy coding's starting to get used globally throughout codecs
[10:51:46 CET] <wm4> so what mailing list clients do you use?
[10:52:07 CET] <wm4> I'd need one that can handle the huge volumes of mails ffmpeg-devel produces
[10:52:10 CET] <kierank> On codecs with simple bitstreams, prores, speedhq, vc2 where it's basically O(VLC) the reader is important
[10:52:13 CET] <kierank> Gmail
[10:54:13 CET] <atomnuker> actually the reader had slowdowns on bitrate-heavy codecs IIRC
[10:54:22 CET] <atomnuker> (the libav one)
[10:55:07 CET] <Chloe> wm4: thunderbird. With 30k emails, as long as you dont do cmd+a, it may or may not crash at any time.
[10:58:01 CET] <wm4> wut
[10:58:22 CET] <Chloe> because if you cmd+a then it will crash immediately
[10:59:22 CET] <Chloe> wm4: have you tried a cli client?
[11:11:29 CET] <mateo`> I'm using mutt, works fine with 30k mails
[11:16:17 CET] <wm4> Chloe: haven't
[11:17:55 CET] <Chloe> Yeah, I've heard mutt is pretty good with a lot of email. I haven't switched because I enjoy clicking things too much
[11:19:08 CET] <bencoh> there is a patch for mouse support in mutt if you want :>
[11:19:28 CET] <bencoh> no idea whether it still works though (and it's an heresy)
[11:22:17 CET] <wm4> will mutt force me to memorize lots of weird key bindings?
[11:23:22 CET] <Chloe> bencoh: I enjoy clicking pretty things*
[11:23:55 CET] <bencoh> aww, but it's pretty! :(
[11:24:12 CET] <trapp> I was a user of Sylpheed for a long time. Now I'm using Thunderbird+Lightning due to the stopped Mozilla Sunbird project.
[11:24:31 CET] <bencoh> wm4: you will eventually memorize natural bindings :p
[11:30:50 CET] <wm4> jkqxz: heh, who wants vp8 hwdec?
[11:31:19 CET] <wm4> trapp: I'm using claws-mail, but its developers explicitly say the imap protocol and claws-mail do not work with such a huge mail volume
[11:31:40 CET] <wm4> claws-mail is a fork of Sylpheed
[11:32:01 CET] <Chloe> pop3? :D
[11:33:39 CET] <wm4> yes, they suggest that you should use pop3
[11:33:48 CET] <wm4> or something like this
[11:40:25 CET] <trapp> I have a local IMAP server and Sylpheed is comparable to Thunderbird regarding mail navigation performance. Fetching new mail might be slower. But at least Sylpheed is running more stable. I have to restart Thunderbird after 24h due to excessive memory usage.
[11:41:07 CET] <wm4> claws-mail often refetches all headers in a folder for no reason
[11:41:13 CET] <wm4> it also "blocks" during network operations
[11:42:42 CET] <mateo`> on my setup i delegate the imap synchronization to mbsync so i get a standard mailbox which is then used by mutt
[11:44:32 CET] <trapp> Indeed Sylpheed seems to do quite some things synchronously instead of async. Maybe that's the reason it's more stable :-)
[11:45:36 CET] <wm4> trapp: I mean, claws-mail is also very synchronous
[11:45:56 CET] <wm4> while the GUI technically doesn't freeze, you can't do much until it's finished with its operation
[11:47:43 CET] <trapp> wm4: I understand.
[11:51:59 CET] <wm4> I often kill -9 it though
[11:52:06 CET] <wm4> because it doesn't recover from whatever it's doing
[11:52:14 CET] <wm4> all in all a very not-great user experience
[11:53:40 CET] <jkqxz> wm4:  The yami people seemed to want it, and it was mildly amusing to write.
[11:54:52 CET] <wm4> how was it "amusing"?
[11:57:32 CET] <jkqxz> wm4:  Are you generally happy with that merge, beyond just "oh it's a merge"?  You are one of the most important users of it.
[12:00:55 CET] <wm4> well it's hard to tell how it's different from Libav's version
[12:01:03 CET] <jkqxz> Mostly amusing because I haven't looked at VP8 before, and finding out the bizarre decisions made in another codec is always fun.
[12:01:13 CET] <wm4> though I fully trust that the merge is sane anyway
[12:03:19 CET] <jkqxz> (Like, using your arithmetic entropy coder for /everything/, including the header information, turns out not to be quite such a good idea as you might have hoped.)
[12:04:08 CET] <wm4> lol
[13:20:50 CET] <Sesse> http://munin.sesse.net/samfundet.no/pannekake.samfundet.no/sensors_temp.html -- fuzzing.
[13:21:05 CET] <Sesse> +20 degrees :-P
[14:45:14 CET] <Chloe> Who is the ffmpeg group representative? 
[14:45:25 CET] <Chloe> For freenode that is
[14:46:07 CET] <durandal_170> our beloved leader that resign
[14:46:15 CET] <kierank> donald trump
[14:46:50 CET] <Chloe> michaelni? 
[14:47:06 CET] <durandal_170> Chloe: why you ask?
[14:47:47 CET] <Chloe> I looked into the cloak thing some more and the group representative will be given power to cloak or something. But it needs to be the 'group representative' 
[14:48:32 CET] <durandal_170> does cloak gives you superpowers..?
[14:49:00 CET] <Chloe> It looks cool, yo. 
[14:49:49 CET] <wm4> I thought Kim Jong was ffmpeg's leader
[14:49:57 CET] <durandal_170> can be me if michaelni doesnt want to represent us
[14:51:20 CET] <durandal_170> saste: can you be group representative?
[14:52:24 CET] <saste> durandal_170, I'd prefer not, not much into ffmpeg things in the last two years (at least)
[14:52:27 CET] <durandal_170> lets make FFmpeg president/leader cycle every 4 weeks
[14:52:39 CET] <funman> "representing" means /msg ##freenode please give /foo/cloak/ffmpeg clock to $username
[14:53:01 CET] <Chloe> Id prefer if it cycled every 5 weeks
[14:53:32 CET] <wm4> kierank should be leader
[14:53:41 CET] <durandal_170> yea
[14:53:55 CET] <funman> the true upstream
[14:53:56 CET] <kierank> durandal_170: haha athenian democracty
[14:54:01 CET] <Chloe> Seems unanimous 
[14:54:10 CET] <Chloe> kierank is now the leader 
[14:54:30 CET] <durandal_170> kierank: do you have git access to repo?
[14:54:33 CET] <kierank> yes
[14:57:45 CET] <Sesse> wow, ffmpeg has a native snappy decoder
[14:57:47 CET] <Sesse> someone must have been bored
[14:59:02 CET] <kierank> Original author(s)	Jeff Dean, Sanjay Ghemawat, Steinar H. Gunderson
[14:59:03 CET] <kierank> ah
[14:59:07 CET] <kierank> so famous Sesse 
[14:59:56 CET] <Sesse> is this from the wikipedia article? 
[15:00:00 CET] <Chloe> Does IP over broadcast actually happen anywhere? 
[15:00:11 CET] <kierank> Sesse: yes
[15:00:17 CET] <Sesse> kierank: the article is really poor
[15:00:21 CET] <kierank> Chloe: yes, people send ip over dvb
[15:00:50 CET] <Sesse> kierank: at least it's better than Zeev Tarantov, Steinar H. Gunderson, which was super-wrong on so many levels
[15:01:48 CET] <Chloe> durandal_170: yeah, I mean, it's as easy as funman says. There's nothing to it, you just need to say that you're the 'project representative'  for freenode. 
[15:02:31 CET] <durandal_1707> i think this is not permanent oping somehow
[15:02:55 CET] <Chloe> You need to put it in the access list 
[15:03:24 CET] <Chloe> Which you need +f for afaik
[15:11:14 CET] <durandal_1707> i guess only +f person on this channel can be our representative
[15:12:12 CET] <Chloe> I don't think so
[15:12:28 CET] <Chloe> Im fairly sure it can be anyone
[15:13:56 CET] <Chloe> Staff will get back to me on the procedure to become a representative 
[15:19:00 CET] <durandal_1707> currently we have two leaders+F here Compn and michaelni, ask them
[15:19:32 CET] <michaelni> I can ask for cloaks, i just dont know what to do
[15:20:49 CET] <jamrial> j-b might know how to use/assign them
[15:22:15 CET] <jamrial> durandal_1707: ?
[15:22:41 CET] <trapp> I'd like to see a fix backported to previous release branches: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c1bdc4126955cae7f385208e455685986
[15:22:41 CET] <trapp> Is this something I can do, or is it the task of the file maintainer, or the release maintainer?
[15:22:59 CET] <durandal_1707> jamrial: i dunno what happened
[15:23:50 CET] <funman> jamrial: i am the videolan irc representative
[15:24:16 CET] <funman> 14:52 < funman> "representing" means /msg ##freenode please give /foo/cloak/ffmpeg clock to $username
[15:24:21 CET] <funman> here's how to request cloaks
[15:24:26 CET] <trapp> From what I see release 2.7 to 3.2 would be affected.
[15:32:28 CET] <durandal_1707> jamrial: huh? I wonder how +O flag managed to set +ir
[15:32:46 CET] <jkqxz> trapp:  You can do it yourself.  Ideally backport with "git cherry-pick -x" from master to the branch you want, then send the patch to the ML.  (A newly-made patch against the branch also works, though it's preferred for it to refer directly to the commit on master.)
[15:33:48 CET] <michaelni> trapp, jkqxz i think ive locally backported that already to some releases
[15:34:57 CET] <durandal_1707> stupid irssi string parsing
[15:35:53 CET] <trapp> jkqxz: OK.
[15:35:53 CET] <trapp> michaelni: Yes, I asked for it in some mail but was unsure as I was not seeing it on git.videolan.org 
[15:36:19 CET] <michaelni> funman, iam not sure if ffmpeg has a representatve or if i am that but i sure can try to ask for some cloak, what exact cloak(s) we want ? ffmpeg/maintainer ? something else ? 
[15:36:25 CET] <Sesse> durandal_1707: irssi doesn't parse the string, the irc server does
[15:38:24 CET] <funman> michaelni: @ffmpeg/developer @ffmpeg/supporter
[15:40:46 CET] <michaelni> ok, so i need a volunteer to test  the cloaking on and a exact command to copy and paste.
[15:45:10 CET] <Compn> i can test developer do you have the command to copy and paste or you need someone to find it ?
[15:45:39 CET] <Compn> durandal_1707 : since when was i promoted to leader? :P
[15:46:24 CET] <durandal_1707> Compn: modified 5y 9w 6d ago, on Nov 02 23:25:13 2011
[15:47:12 CET] <Compn> oh , ok then
[15:47:28 CET] Action: Compn not paying attention to irc founding status
[15:50:03 CET] <michaelni> i dont have a exact command no, just the approximate one funman posted but i prefer an exact one so i dont miss-guess anything
[15:51:48 CET] <Compn> you've talked to the freenode staff already ?
[15:52:36 CET] <michaelni> no, i dont think FFmpeg has a registered representative  so i dont think i can add cloaks
[15:53:10 CET] <Compn> says 0 staff when i type /stats p
[15:53:14 CET] <Compn> so yeah
[15:54:06 CET] <Compn> so is this done with nickserv group ?
[15:54:42 CET] <funman> Compn: yeah you need to ask on ##freenode
[15:54:56 CET] <funman> i guess you need to register group first
[15:55:21 CET] <Compn> k
[16:17:03 CET] Action: Compn falls for it
[16:17:09 CET] <Compn> #freenode not ##freenode
[16:17:13 CET] <Compn> michaelni ^
[16:30:07 CET] <cone-594> ffmpeg 03Henrik Gramner 07master:cd09e3b34903: x86inc: Avoid using eax/rax for storing the stack pointer
[16:59:41 CET] <Sesse>     movsxdifnidn  r2, r2d
[16:59:43 CET] <Sesse> wtf
[17:00:08 CET] <Sesse> that's an extreme name
[17:01:43 CET] <Sesse> perhaps move with sign extension if not identical
[17:22:28 CET] <durandal_170> Compn: stop trolling around and add pixlet and ylc0 decoder to mplayer codecs.conf
[17:24:22 CET] <Compn> busy getting cloak right now
[17:24:24 CET] <Compn> remind me tho
[17:28:52 CET] <wm4> lol codecs.conf
[17:31:51 CET] <durandal_170> Compn: forget cloak, take umbrella
[17:32:12 CET] <Compn> wm4 : did you rip it out and send it all to lavf now ?
[17:32:51 CET] <durandal_170> Compn: in mpv it is magic
[17:33:16 CET] <Compn> wonder if mpv also removed binary codec support... hmm
[17:33:28 CET] <durandal_170> yes
[17:33:37 CET] <Compn> yeah then theres not much need for codecs.conf
[17:33:56 CET] <Compn> if its just a straight lavc -- no other decoders, no need to map to different libs
[17:36:14 CET] <wm4> codecs.conf was a roundabout and complicated mechanism
[17:37:15 CET] <Compn> it was created in a time before ffmpeg. thats one reason why...
[17:40:29 CET] <wm4> there was no reason to have it for "normal" decoders which support a known set of codecs anyway
[17:40:38 CET] <michaelni> Chloe, btw, cloaks dont hide IP in case you or anyone expected different
[17:40:56 CET] <Chloe> I know, they look cool though 
[17:41:57 CET] <Compn> wm4 : you mean the fourcc registration should have been in the wine code in the first place ?
[17:42:19 CET] Action: Compn remembers all of the hacks
[17:42:25 CET] <Compn> nevermind , there is no defending any of this
[17:42:37 CET] <Compn> it works, thats the answer.
[17:42:51 CET] <Compn> it murders small animals, but it works.
[17:44:36 CET] <BBB> more than just kittens?
[17:44:44 CET] <BBB> most code just kills kittens, right?
[17:46:35 CET] <Compn> have you seen mplayer code? :D
[17:46:39 CET] <Sesse> I suppose the original motivation for binary codecs was playing divx on linux, I guess we're a bit past that :-)
[17:47:37 CET] <BBB> Compn: true, true
[17:56:21 CET] Action: Compn bbl
[18:42:17 CET] <cone-594> ffmpeg 03Paul B Mahol 07master:7aef56864c96: avfilter/af_sofalizer: speed and clean up fast convolution a little
[18:56:27 CET] <cone-594> ffmpeg 03Paul B Mahol 07master:24d31a80746c: avcodec/qdm2: make use of bytestream2
[19:08:48 CET] <durandal_170> how to make get_vlc2 faster?
[19:08:57 CET] <kierank> use libav bitstream reader
[19:09:16 CET] <durandal_170> it uses up to 65% of time
[19:10:11 CET] <Sesse> that, and tweak the table size, I suppos
[19:10:11 CET] <Sesse> e
[19:10:25 CET] <durandal_170> to what size?
[19:10:32 CET] <Sesse> you'll have to try it and see
[19:10:40 CET] <Sesse> it depends on the cpu, the codec, and the codes in use
[19:11:56 CET] <jamrial> kierank: is it really faster, or just simpler?
[19:12:10 CET] <kierank> the benchmarks apparently show it is
[19:12:13 CET] <kierank> durandal_170: what codec
[19:13:20 CET] <durandal_170> utvideo
[19:15:57 CET] <kierank> i assume you have frame/slice threads
[19:16:08 CET] <kierank> all those intra codecs are basically O(bitstream) or O(vlc)
[19:16:28 CET] <durandal_1707> have frame threads
[19:16:57 CET] <durandal_1707> same could be said to magicyuv, except that one have slice threads also
[19:36:38 CET] <durandal_1707> it's 53 vs 72 fps in single threaded mode
[19:37:40 CET] <kierank> can ffmpeg do frame and sliced at the same time
[19:53:47 CET] <iive> Sesse: it's faster on 64 bit
[19:53:50 CET] <Sesse> heh, ff_put_pixels_clamped_sse2 uses fp instructions to move int data around
[19:54:57 CET] <kierank> that's normal iirc
[19:55:02 CET] <kierank> there's no penalty
[19:55:06 CET] <Sesse> there is
[19:55:08 CET] <kierank> we do shufps
[19:55:22 CET] <Sesse> it's a one-cycle forwarding latency for sandy bridge and newer, iirc
[19:56:05 CET] <Sesse> this is why you have separate instructions for e.g. int and float xor
[19:57:39 CET] <jamrial> Sesse: are you talking about the movhps?
[19:57:50 CET] <Sesse> jamrial: yes
[19:57:57 CET] <jamrial> there's no int equivalent for that afaik
[19:58:02 CET] <Sesse> true
[19:58:38 CET] <Sesse> at least not with generic strides
[20:00:20 CET] <jamrial> mmh, maybe pextrq, but that's sse4
[20:02:56 CET] <Sesse> jamrial: I suppose maybe having an sse idct would be more important than a better put_pixels_clamped :-)
[20:18:00 CET] <durandal_1707> kierank: looks like only left prediction is really slow compared to libutvideo
[20:36:04 CET] <durandal_1707> disabling safe bitstream reader makes performance similar
[20:46:25 CET] <atomnuker> jamrial: no, it's not something amazing, its just cleaner and performs well with low bitrate codecs relying on rawbits
[20:47:17 CET] <atomnuker> according to tests kagami IIRC did it was slower for anything but prores
[20:50:18 CET] <kierank> ENOBENCHMARKS
[20:50:38 CET] <kierank> 32-bit needs to die anyway
[20:50:39 CET] <kierank> sorry jamrial 
[20:50:41 CET] <kierank> j-b: 
[20:51:20 CET] <jamrial> ?
[20:51:38 CET] <kierank> I mean't j-b 
[21:28:49 CET] <llogan> michaelni, Compn: I'll be gone from January 13-23. -devel mod queue has recieved much more spam since beginning of year, so check daily if you can to keep up with it.
[22:06:31 CET] <Compn> llogan : enjoy your 10  days off , to wherever :)
[22:07:11 CET] <llogan> thanks. hawaii.
[22:07:49 CET] <Compn> oh nice
[22:07:53 CET] <Compn> big island? maui? 
[22:08:05 CET] <Compn> i been hawaii twice, great place :D
[22:54:18 CET] <llogan> big island
[23:00:16 CET] <cone-401> ffmpeg 03Lou Logan 07master:890320b1c084: doc/scaler: mention default scaling algorithm
[00:00:00 CET] --- Tue Jan 10 2017