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

[burek]

[01:15:29 CEST] <cone-328> ffmpeg 03Christophe Gisquet 07master:235381e674bf: dnxhddec: use unsafe bitstream reader
[02:33:28 CEST] <atomnuker> god damn it my commts have been bitrotting for so long I started writing an af_ssim
[02:35:23 CEST] <jamrial> we don't have that already?
[02:35:36 CEST] <jamrial> oh, vf_ssim
[05:22:33 CEST] <Zeranoe> Is it worthwhile to include kvazaar in the Windows builds?
[05:35:50 CEST] <jamrial> not if you include x265
[09:25:40 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:691a7df3c5b7: avfilter: add maskedmerge filter
[09:25:40 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:238ca2d72360: doc/filters: move mcdeint above mergeplanes
[10:01:00 CEST] <cousin_luigi> Greetings.
[10:24:53 CEST] <cone-210> ffmpeg 03Alex Smith 07master:a58c22d61260: configure: Support for HEASLR on mingw targets
[12:39:24 CEST] <cone-210> ffmpeg 03Christophe Gisquet 07master:6110a55b7d0d: dnxhddec: reindent/cosmetics
[12:50:30 CEST] <cone-210> ffmpeg 03Christophe Gisquet 07master:578f721f5dcf: dnxhddec: add my contributions
[13:12:00 CEST] <wm4> BBB: so where do we get a fast vp9 encoder?
[13:13:22 CEST] <av500> wm4: "google" for it
[13:13:25 CEST] Action: av500 hides
[13:14:44 CEST] <wm4> google only has a slow one
[13:20:21 CEST] <BBB> you copy some concepts from ffvp9, you put a few competent devs together that understand the spec + understand performance, you shake it and wait two years
[13:20:21 CEST] <BBB> ...
[13:20:22 CEST] <BBB> ?
[13:21:21 CEST] <nevcairiel> judging from BBB's presentation, its not that slow anymore, you can get like 30% quality over x264 at same speed or something?
[13:21:34 CEST] <BBB> thats still slow
[13:21:55 CEST] <BBB> the decoder is _faster_ than (ff)h264
[13:22:03 CEST] <J_Darnley> Would that be at x264's veryfast or veryslow?
[13:22:03 CEST] <nevcairiel> it could do with proper threading
[13:22:03 CEST] <BBB> why isnt the encoder faster (and 50% better in quality)?
[13:22:36 CEST] <BBB> they all use threading
[13:22:41 CEST] <BBB> I think people overthink threading
[13:22:49 CEST] <BBB> threading just shares equal workload over two cpus
[13:22:56 CEST] <BBB> it doesnt decrease workload in any significant way
[13:23:00 CEST] <Compn> is ffh264 still slower at single core decoding than coreavc ?
[13:23:04 CEST] <nevcairiel> x264 can use all my cores, if  vpxenc cant do that, its not threaded properly
[13:23:10 CEST] <BBB> true
[13:23:22 CEST] <BBB> so that needs fixing (it does, Im aware of several threading issues in libvpx)
[13:23:36 CEST] <BBB> but the more interesting thing (academically speaking) is why we are not 50% better at same speed than x264
[13:23:46 CEST] <BBB> the decoder stats suggest thats possibly, at same-quality at least
[13:23:58 CEST] <nevcairiel> because new encoding magic also needs CPU to analyze the image more?
[13:24:09 CEST] <BBB> apparently not that much
[13:24:32 CEST] <BBB> if vp9 _de_coding is faster than hevc, why isnt _en_coding also at all speed settings?
[13:24:35 CEST] <BBB> its a little, but not much
[13:24:38 CEST] <BBB> it should be a lot more
[13:24:59 CEST] <J_Darnley> Here's the obvious answer: there is not a bunch of people working hard to see their hardwork become the best encoder
[13:25:06 CEST] <nevcairiel> i think extrapolating encoding performance scaling based on the decoder is a bit far fetched
[13:25:38 CEST] <BBB> nevcairiel: maybe, but you should target it at least
[13:25:45 CEST] <nevcairiel> give an encoder a long list of different modes to consider, it has to test them all to some degree, while the decoder just gets told which mode to use and apply
[13:25:57 CEST] <BBB> nevcairiel: heres another way of saying the same thing: the line of vpx/x265 hould always be parallel to the x264 line, just shifted up/left
[13:26:04 CEST] <nevcairiel> so more modes, slower encoder, while d ecoder doesnt change
[13:26:16 CEST] <BBB> if it ever moves towards the x264 line in diagonally decreasing distance, it means were worse than x264 at that point
[13:26:21 CEST] <BBB> (relative to previous points)
[13:27:05 CEST] <BBB> more practically speaking, x264 does some pretty cool magic in its mode selection which vpx doesnt do
[13:27:10 CEST] <BBB> so theres a lot of opportunity for improvement
[13:27:34 CEST] <BBB> example: x264 has analyze; vpx simply turns of all non-h/v/dc/tm modes at 16x16/32x32 at speed>=1
[13:27:50 CEST] <nevcairiel> you could probably expect small gain at same performance, but expecting the full 50% promised gain at same encoding performance seems a bit out there, imho at least
[13:27:51 CEST] <BBB> thats sort of the general story of comparing these two encoders
[13:27:59 CEST] <nevcairiel> not to say that vpx already did all that it could
[13:28:04 CEST] <nevcairiel> but x264 is also a decade older, more or less
[13:28:08 CEST] <BBB> the taget should be 50%
[13:28:12 CEST] <BBB> you might never get there
[13:28:20 CEST] <BBB> but (esp. for x265) 10% is embarassing
[13:28:30 CEST] <BBB> and after that it actually itnersects
[13:28:36 CEST] <BBB> thats terrible
[13:29:16 CEST] <BBB> again, what Im primarily after is shapes of the second graph being equal
[13:29:33 CEST] <BBB> so the goal should be that the lines never get closer together as the speed target moves up, idealistically speaking
[13:29:55 CEST] <BBB> and the vpx line almost touches upon the x264 line, and the x265 line actually intersects with it
[13:30:02 CEST] <BBB> thats terrible, and means lots of work left to do
[13:30:31 CEST] <BBB> if we cant improve that, it means the new codecs arent that great after all, and it means we need to change our codec research groups to include speed research in addition to quality research
[13:30:49 CEST] <BBB> (or alternatively, face the risk of the new codec not being picked up by companies)
[13:31:53 CEST] <BBB> or beg intel to reinstate moores law?
[13:32:39 CEST] <nevcairiel> not every use case really cares, if i'm authoring a UHD Blu-ray I might simply not care, i have tons of bitrate and tons of time, while a broadcaster probably uses a real-time encoder, which is a different beast entirely and probably often hardware
[13:32:45 CEST] <nevcairiel> that leaves youtube and the likes
[13:33:11 CEST] <BBB> true
[13:33:30 CEST] <BBB> like I said in my blogpost, its written for the example scenario of youtubeish types
[13:33:42 CEST] <BBB> netflix is indeed very different
[13:34:42 CEST] <nevcairiel> hevc is still young, and as it matures hopefully both encoder and decoder get faster
[13:34:46 CEST] <BBB> the sad thing is that at high bitrates, the diff between old/new codecs goes down in most cases I looked at :(
[13:35:03 CEST] <BBB> so then the bluray savings go down also
[13:35:12 CEST] <nevcairiel> for 4k there is still quite some difference
[13:35:16 CEST] <nevcairiel> from bigger blocks alone
[13:35:29 CEST] <BBB> yeah, my example here is 1080p, so it helps a fair bit
[13:35:45 CEST] <BBB> but not as much already, I guess it depends on the complexity of the content, but it decomposes a lot at high bitrates
[13:35:52 CEST] <BBB> unless the area is highly static
[13:36:15 CEST] <nevcairiel> its the same reason why noone cares that the commercial h264 encoders used for Blu-rays are all crap
[13:36:16 CEST] Action: Daemon404 notes the comments on BBB's blog post show a lot of misinformation / failure to interpret the post still around
[13:36:20 CEST] <nevcairiel> let them waste bits, who cares
[13:36:48 CEST] <cone-210> ffmpeg 03Jean Delvare 07master:3e5b02bdb8e5: avfilter/delogo: Fix show option when band is small
[13:36:54 CEST] <BBB> Daemon404: well, thats why we discuss it, right? :)
[13:37:17 CEST] <BBB> nevcairiel: well, I guess thats the interesting thing - companies can save a lot of money (yes, $$$) on this
[13:37:23 CEST] <Daemon404> BBB, mostly its the normal stuff
[13:37:29 CEST] <Daemon404> like "BTU GPU ENCODING"
[13:37:31 CEST] <Daemon404> and whatnot
[13:37:33 CEST] <Daemon404> BUT*
[13:37:45 CEST] <fritsch> Are there any VP9 gpu encoders already? And if yes - which parts can they accelerate that much so that they outperform cpu?
[13:38:06 CEST] <BBB> Daemon404: comments where? my blog has 0 comments
[13:38:06 CEST] <nevcairiel> there arent even any non-vpx cpu encoders
[13:38:14 CEST] <Daemon404> BBB, hacker news and reddit
[13:38:47 CEST] <fritsch> BBB: i sent you an email :-) did not trust myself to comment
[13:38:59 CEST] <BBB> fritsch: yes, thanks for that
[13:39:01 CEST] <fritsch> nevcairiel: cpu / gpu?
[13:39:08 CEST] <BBB> reddit? I dindt see it
[13:39:09 CEST] <BBB> letmesee
[13:39:19 CEST] <Daemon404> its recent on reddit
[13:39:22 CEST] <Daemon404> on proggit
[13:39:31 CEST] <Daemon404> https://www.reddit.com/r/programming/comments/3mocaj/vp9_encodingdecoding_performance_vs_hevch264/
[13:40:34 CEST] <nevcairiel> someone should pick up hevc decoding performance, the intrinsics in openhevc are all rather crude i've been told, and carefully written yasm would probably be quite a bit faster still
[13:41:04 CEST] <Daemon404> some people seem to be conflating encoding and decoding speed as well, i think
[13:41:08 CEST] <Daemon404> or i read their stuff wrong
[13:42:48 CEST] <fritsch> nevcairiel: there I also have a question. Which code paths did they optimize and for which CPU? did they use generic extensions in their asm code? As I might think AMD vs Intel would reveal different results?
[13:43:05 CEST] <nevcairiel> AMD performance is in the crapper no matter what you do
[13:43:24 CEST] <fritsch> lol
[13:43:38 CEST] <fritsch> i will look at the code
[13:43:57 CEST] <nevcairiel> but its mostly just various SSE versions, from 2 to 4.1 or so, it should benefit all CPUs
[13:44:11 CEST] <Daemon404> unless you save sse2slow or w/e x264 calls it
[13:44:12 CEST] <Daemon404> ;)
[13:44:17 CEST] <Daemon404> have*
[13:44:22 CEST] <nevcairiel> only very old CPUs fall into that
[13:44:39 CEST] <Daemon404> there is a guy on on doom9 still running a p2 and xp
[13:44:39 CEST] <Daemon404> so.
[13:44:42 CEST] <Daemon404> :D
[13:44:53 CEST] <Daemon404> sorry
[13:44:53 CEST] <Daemon404> p3
[13:44:54 CEST] <nevcairiel> who cares about those guys
[13:44:59 CEST] <Daemon404> not me
[13:45:11 CEST] <Daemon404> its just that they also tend to be the noisiest
[13:45:24 CEST] <fritsch> yeah i know those kind of people ...
[13:45:29 CEST] <fritsch> amd legacy gpu users ...
[13:45:40 CEST] <fritsch> are the worst that can happen for you if you change the way your software decodes and renders
[13:45:44 CEST] <fritsch> :-)
[13:45:46 CEST] <nevcairiel> of course, they need to tlel the world about the kind of hero they are, and block innovation for everyone else because their decades old OS needs to work =p
[13:46:15 CEST] <J_Darnley> Excuse me but XP is the best OS Microsoft has ever made.
[13:46:38 CEST] <nevcairiel> And you are free to use it, just not with my software xD
[13:46:39 CEST] <Daemon404> i'm invoking poe's law here.
[13:46:55 CEST] <J_Darnley> (that wasn't satire)
[13:47:01 CEST] <fritsch> nevcairiel: that i will use in my kodi forum signature :-) too funy
[13:47:01 CEST] <Daemon404> my condolences
[13:47:32 CEST] <nevcairiel> Right now all my things even work on XP still, but i'll probably destroy it some day
[13:47:50 CEST] <nevcairiel> (or at least I havent been told otherwise)
[13:48:24 CEST] <Daemon404> i am, in fact, working on something that will break xp support in ffmpeg right now, maybe.
[13:48:33 CEST] <nevcairiel> pthread_once?
[13:48:35 CEST] <Daemon404> yep!
[13:48:51 CEST] <Daemon404> if someone cares so much about xp, they can write some emulated version
[13:48:51 CEST] <nevcairiel> emulation isnt impossible, or even htat hard
[13:48:52 CEST] <Daemon404> i will not.
[13:48:55 CEST] <nevcairiel> i'm sure SO has some code
[13:49:04 CEST] <Daemon404> nevcairiel, sure. but i dont care.
[13:49:09 CEST] <Daemon404> someone who cares can
[13:49:31 CEST] <J_Darnley> Meybe that will prompt me to finally learn multithreading
[13:49:43 CEST] <Daemon404> and an emulated version might end up not even fixing what im trying to fix anyway
[13:49:56 CEST] <Daemon404> (lock contention in avcodec_open2, when using lavc in multiple threads)
[13:50:22 CEST] <nevcairiel> pthread_once implementation isnt very complex, so emulating that with mutexes isnt that hard
[13:50:34 CEST] <nevcairiel> http://pastebin.com/XU2ak89c
[13:50:36 CEST] <Daemon404> and with mutexes, youre right back at lock contention
[13:50:37 CEST] <nevcairiel> thats the original function
[13:50:42 CEST] <nevcairiel> it a lso uses mutexes
[13:50:42 CEST] <Daemon404> depending on how it's done.
[13:51:58 CEST] <BBB> Daemon404: I think the hackernews comments are somewhat ok
[13:52:47 CEST] <nevcairiel> Daemon404: in before the os2 "maintainer" sends you angry mails =p
[13:55:21 CEST] <Daemon404> excuse me, but is called os/2, not os2.
[13:56:51 CEST] <nevcairiel> i r lazy
[13:58:09 CEST] <fritsch> nevcairiel: in which scenaria is such a pthread_once unavoidable? E.g. when it is not possible to setup everything before hand? So what's a typical usecase? in your implementation as fallback which data type is PTHRAD_NEEDS_INIT ? integer define?
[13:58:48 CEST] <wm4> nevcairiel: now try on xp
[13:59:01 CEST] <wm4> os/2 can probably be ignored
[13:59:05 CEST] <wm4> it's used by only 1 person
[13:59:23 CEST] <Daemon404> wrong! 2!
[13:59:54 CEST] <wm4> nevcairiel: actually, I don't understand your code either, how is the mutex initialized?
[14:00:10 CEST] <nevcairiel> wm4: thats the original pthread implementation
[14:00:13 CEST] <nevcairiel> it uses static init
[14:00:29 CEST] <wm4> what do you mean by "original pthread"?
[14:00:43 CEST] <nevcairiel> how is that hard to understand
[14:00:48 CEST] <nevcairiel> thats pthread_once source
[14:00:55 CEST] <wm4> from where?
[14:01:25 CEST] <wm4> pthread is a standard, there are many implementations
[14:01:59 CEST] <wm4> anyway, the only way to get static mutex init on windows is some hack that only works unofficially, isn't it
[14:02:22 CEST] <nevcairiel> just use atomic pointer switching to work around it
[14:02:36 CEST] <nevcairiel> the glibc function of pthread_once looks similar, just uses different function names
[14:02:46 CEST] <wm4> that gives a minor memory leak, which will be bikeshedded about for months
[14:03:01 CEST] <nevcairiel> its either that or no XP
[14:03:02 CEST] <nevcairiel> :P
[14:04:09 CEST] <nevcairiel> (in before os/2 doesnt even have atomics)
[14:04:10 CEST] <Daemon404> nevcairiel, could just make xp require an external pthreads
[14:04:11 CEST] Action: Daemon404 runs
[14:04:23 CEST] <wm4> Daemon404: +1
[14:04:33 CEST] <nevcairiel> meh, mixing pthreads and native threads is a big mess
[14:04:40 CEST] <Daemon404> ofc
[14:04:40 CEST] <nevcairiel> it leaks handles everywhere
[14:04:51 CEST] <wm4> you're not mixing them, you use either of them
[14:05:05 CEST] <wm4> what the user does is another question (and his fault!!!1)
[14:14:21 CEST] <nevcairiel> i should send my hack-y patch to enable the udp worker thread with w32threads, just to see how much bikeshed it produces
[14:14:39 CEST] <Daemon404> :D
[14:14:51 CEST] <Daemon404> we havent had a nevcairiel patch dump in a while
[14:15:04 CEST] <nevcairiel> most of them i just submit right away these days
[14:15:33 CEST] <Daemon404> ah
[14:16:08 CEST] <nevcairiel> http://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=06010e2475bd888e691b17937e1124a560f103cd;js=1
[14:16:13 CEST] <nevcairiel> seems slightly evil, but works fine =p
[14:17:39 CEST] <nevcairiel> (it doesnt need cancel because closing the socket will automatically unblock the thread)
[14:41:26 CEST] <BBB> nevcairiel: coming back to what you said earlier, ffhevc needs work, but all these companeis that are dying to see hevc being adopted will have to pay for it
[14:41:38 CEST] <BBB> nevcairiel: I am not doing it for free, its too much of a ripoff
[14:43:23 CEST] <J_Darnley> That's the spirit!
[14:46:32 CEST] <JEEB> :)
[14:46:35 CEST] <BBB> lol
[14:46:38 CEST] <BBB> sorry for being blunt
[14:46:43 CEST] <JEEB> well, it makes sense
[14:46:55 CEST] <JEEB> it's currently not yet the savior of current-gen video
[14:47:00 CEST] <BBB> I just feel that for h264 (also x264), for a long time, a bunch of companies made great money from our (or x264s) efforts
[14:47:02 CEST] <JEEB> thus it's not widely used in general as AVC
[14:47:06 CEST] <J_Darnley> I didn't mean to sound sarcastic
[14:47:11 CEST] <BBB> x264 licensing definitely helps, but ffh264 didnt get anything
[14:47:16 CEST] <JEEB> true
[14:47:33 CEST] <JEEB> although since x264/AVC had a lot of usage the community got more out of it
[14:47:33 CEST] <wm4> and there's still the patent situation (lol)
[14:47:57 CEST] <JEEB> HEVC doesn't exactly have a situation like that yet
[14:47:59 CEST] <BBB> the hevc patent situation is also funny, yes
[14:48:12 CEST] <JEEB> yeah, it's a "more pop corn, please" kind of situation
[14:48:28 CEST] <JEEB> it's as if there's people who don't want to see adoption of it happen ;)
[15:14:02 CEST] <BBB> JEEB: more popcorn it is indeed - Im loving it so far :D
[15:15:46 CEST] <Daemon404> needs more v-nova
[15:16:31 CEST] <Daemon404> BBB, oh i wante to point out, re: x265 stats - its 'placebo' preset is a lie
[15:16:47 CEST] <Daemon404> you can still enable more stuff to get better quality
[15:17:01 CEST] <Daemon404> but it is so ludicrously slow, im guessing they didnt want to look bad by having it in placebo?
[15:17:09 CEST] <Daemon404> (even though thats the intent of the name 'placebo'!)
[15:17:49 CEST] <BBB> veryslow is actually same quality as placebo for x265
[15:17:59 CEST] <Daemon404> yes
[15:18:04 CEST] <BBB> for x264 theres a 5% difference
[15:18:28 CEST] <Daemon404> theres some stuff to fiddle with for ME, bframes, and refs beyond placebo in x265
[15:18:32 CEST] <Daemon404> among others
[15:18:36 CEST] <BBB> thats true
[15:18:37 CEST] <Daemon404> it's a marketing thing
[15:18:40 CEST] <Daemon404> i guess.
[15:18:41 CEST] <BBB> Im sure you can get better quality
[15:18:49 CEST] <BBB> you can do a full motion search in libvpx as well
[15:18:52 CEST] <BBB> did anyone say slow?
[15:18:58 CEST] <Daemon404> :D
[15:19:13 CEST] <Daemon404> iirc in x264 the full motion search didnt even have any real gains iirc
[15:19:19 CEST] <Daemon404> er x265
[15:19:28 CEST] <BBB> star is not a bad ME approximation
[15:19:33 CEST] <BBB> neither is UMH, for that matter
[15:19:47 CEST] <BBB> libvpx uses a trivial staged hex search, which & uhm & is not that good? :)
[15:19:57 CEST] <BBB> (exponential stepwise hex)
[15:20:09 CEST] <Daemon404> for reasons?
[15:20:25 CEST] <BBB> I dont know, thats a good question
[15:20:30 CEST] <BBB> it never came up while I worked there
[15:20:41 CEST] <BBB> maybe just because it was like that yesterday and isnt obviously broken?
[15:20:48 CEST] <Daemon404> probably
[15:20:54 CEST] <Daemon404> though that doesnt explain RC
[15:20:55 CEST] Action: Daemon404 runs
[15:21:18 CEST] <BBB> :D
[15:21:36 CEST] <Daemon404> i fel like this generation of New Codecs (TM) is far less exciting than the last
[15:21:44 CEST] <Daemon404> maybe i have rose tinted nostalgia glasses.
[15:21:55 CEST] <BBB> people said the same when mpeg4 transitioned into h264
[15:21:58 CEST] <BBB> it just takes time
[15:22:08 CEST] <BBB> Im just pointing out the obvious elephants in the room
[15:22:17 CEST] <Daemon404> there were reasonably usable h264 encoders fairly early on, in the form of ateme
[15:22:20 CEST] <BBB> now some big company should pay some big engineering team to fix these problems, and well repeat for h266
[15:22:47 CEST] <BBB> hm& yeah, well, x265 is kinda disappointing so far
[15:22:59 CEST] <Daemon404> nobody works on x265 except paid people right now
[15:23:04 CEST] <Daemon404> which is why 'good enough' is where its at
[15:23:16 CEST] <Daemon404> x264 had people with goals
[15:23:19 CEST] <Daemon404> ("make my anime look good")
[15:25:28 CEST] <BBB> right
[15:25:29 CEST] <Daemon404> and lots of free time (univesty)
[15:25:33 CEST] <Daemon404> university even
[15:25:43 CEST] <BBB> time doesnt have to be free
[15:25:45 CEST] <BBB> time can be paid
[15:25:48 CEST] <BBB> *blink*
[15:26:03 CEST] <Daemon404> my point was nobody cares enough to pay
[15:26:06 CEST] <Daemon404> so x264 was born from passion
[15:26:07 CEST] <BBB> :)
[15:26:28 CEST] <BBB> some companies should pay
[15:26:46 CEST] <BBB> I mean, vimeo must spend reasonable amounts of money on encoding time and bandwidth, if you can decrease these costs, isnt that worth $$$?
[15:27:04 CEST] <Daemon404> i dont know how much we spend
[15:27:04 CEST] <BBB> and vimeo is only moderately big, there may be bigger players in that space?
[15:27:10 CEST] <Daemon404> i bet encoding time is more expensive than bw
[15:27:13 CEST] <BBB> you can estimate it
[15:27:25 CEST] <BBB> youtube tells you how many video uploads per hour
[15:27:33 CEST] <BBB> amazon tells you how expensive 1 core per hour is
[15:27:58 CEST] <BBB> you know how much spf you get when encoding 1080p on a reasonably recent sandybridge at youtube-y settings
[15:28:03 CEST] <BBB> voila
[15:28:46 CEST] <Daemon404> id have to look those up for us
[16:00:00 CEST] <BBB> theres a lot of public confidence in opencl/gpu, y'know
[16:00:16 CEST] <BBB> if I were an advertising firm hired to make gpus sound cool, I would cash out right now
[16:02:33 CEST] <JEEB> yeah
[16:02:58 CEST] <JEEB> almost once a month some poor soul hits #ffmpeg with questions on GPU-based (as in, not ASIC-based) encoding
[16:03:11 CEST] <JEEB> and then the usual lecture is needed
[16:03:23 CEST] <BBB> maybe vnova should re-spin and target gpus exclusively
[16:03:35 CEST] <BBB> seems like a magical fit
[16:04:20 CEST] <BtbN> GPUs aren't exactly usefull for video encoding though, even if someone would write a full OpenCL encoder, it wouldn't be crazy fast or good.
[16:04:44 CEST] <BBB> thats our point, sort of
[16:04:58 CEST] <BBB> maybe our sarcasm is too well-hidden :D
[16:05:45 CEST] <JEEB> :)
[16:07:18 CEST] <iive> doesn't x264 support some opencl acceleration?
[16:07:57 CEST] <Daemon404> it does, but it is useless
[16:08:21 CEST] <iive> what does it accelerate? Motion Estimation?
[16:08:32 CEST] <iive> dct ?
[16:08:34 CEST] <BBB> probably does a full ME
[16:09:00 CEST] <BBB> (as opposed to software hex/umh ME)
[16:09:25 CEST] <BBB> I think it does help compression tiny bits, on some clips
[16:09:26 CEST] <Daemon404> lookahead
[16:09:29 CEST] <BBB> but only a bit
[16:09:41 CEST] <Daemon404> http://git.videolan.org/?p=x264.git;a=commit;h=f49a1b2ef6d95d8f0f186df0fc3bfe38414e264f
[16:10:05 CEST] <Daemon404> (it's not faster than cpu fyi)
[16:10:24 CEST] <DHE> x264 acceleration is situationally useful. sometimes it helps (by something small like 10%) and sometimes it makes things a bit worse
[16:10:35 CEST] <BBB> ubitux: wanna review my 10/12bpp loopfilter asm for vp9?
[16:10:39 CEST] <Daemon404> 10% aint small, and ive never seen it be that much
[16:10:43 CEST] <DHE> now, some GPUs have actual H264 encoding hardware. nvidia has shadowplay on windows.
[16:10:58 CEST] <BBB> Gramner: wanna give final approval to checkasm itxfm_add vp9 tests?
[16:11:08 CEST] <DHE> but that's not opencl related
[16:11:32 CEST] <BBB> and now I need a victim for the dc/tm/h/v intra pred asm
[16:11:38 CEST] Action: BBB stares around
[16:11:52 CEST] <DHE> as in someone to write it?
[16:11:54 CEST] <BBB> iive: tag youre it
[16:11:59 CEST] <BBB> DHE: no, someone to review it
[16:12:11 CEST] <BBB> I wrote it and posted it before weekend, nbody responded
[16:12:30 CEST] <BBB> DHE: hows your x86 assembly?
[16:12:40 CEST] <DHE> borderline non-existant
[16:12:58 CEST] <BBB> &%^*% [vnova translator] -> expert
[16:13:00 CEST] <BBB> great
[16:13:03 CEST] <BBB> can you review my patch?
[16:13:26 CEST] <BBB> :-p
[16:16:33 CEST] <DHE> I am neither qualified, competent nor coherent enough to do so
[16:16:56 CEST] <BBB> haha ok Ill find another victim
[16:17:16 CEST] <BBB> maybe I need to pull a fiona and start giving x86 simd classes
[16:17:24 CEST] <BBB> that worked quite well for a while
[16:18:47 CEST] <durandal_1707> I want that!
[16:19:17 CEST] <BBB> oh I didnt notice, reddit has a duplicate detector
[16:19:20 CEST] <BBB> thats quite useful!
[16:20:03 CEST] <iive> you mean, repost detector?
[16:20:13 CEST] <Daemon404> no
[16:20:17 CEST] <BBB> other discussions (7)
[16:20:18 CEST] <Daemon404> it's meant to correlated between subreddits
[16:20:47 CEST] <DHE> it also does duplicate detection over long periods of time
[16:24:16 CEST] <BBB> durandal_1707: ok lets try to figure something out (once youve started it, youll notice its not hard at all)
[16:24:24 CEST] <BBB> durandal_1707: did you read through fionas original materials?
[16:26:08 CEST] <durandal_1707> I don't remember anything even if I had read
[16:26:53 CEST] <BBB> https://wiki.videolan.org/X264_asm_intro
[16:28:08 CEST] <nevcairiel> I considered writing some hevc asm at some point, but the important missing parts are IDCTs, and well, those are unreadable in C as it is, not a good place to start
[16:29:31 CEST] <martijnb> tbh I have to blankly stare at the math for a few minutes before IDCTs start making sense again
[16:30:10 CEST] <BBB> I feel all parts of hevc could use some attention
[16:30:14 CEST] <BBB> it wont make it 10x faster
[16:30:20 CEST] <BBB> but youll get 5% or 10% from various parts
[16:30:34 CEST] <BBB> idct would be a big gain, yes
[16:31:04 CEST] <nevcairiel> some of the things have already been looked at by james and others, those are probably ok
[16:31:14 CEST] <nevcairiel> MC is a bit of a mixed bag
[16:32:00 CEST] <Gramner> BBB: ok with me to push itxfm tests
[16:35:00 CEST] <BBB> ty
[16:44:41 CEST] <cone-210> ffmpeg 03Henrik Gramner 07master:19b28d047daa: checkasm: Fix the function name sorting algorithm
[16:49:36 CEST] <mateo`> hello o/, when using the hwaccel api, if you want to reconstruct the bitstream of a full frame, you have to concatenate the buffer given to start_frame with each buffer given by each call of decode_slice ?
[16:52:16 CEST] <cone-210> ffmpeg 03Ronald S. Bultje 07master:0b227c6d4725: checkasm: add vp9dsp.itxfm_add tests.
[17:06:44 CEST] <gnafu> BBB: Thanks for your most recent blog post.  Good read :-).
[17:07:51 CEST] <BBB> yw:)
[17:29:32 CEST] <nevcairiel> mateo`: start_frame gives you the full buffer, slices only slice buffers, so you can just use the start_frame buffer as  a whole
[17:36:30 CEST] <mateo`> nevcairiel: thanks !
[17:52:15 CEST] <mateo`> nevcairiel: i was asking because it looks like the videotoolbox hwaccel differentiate the case when the h264 stream is of format bytestream and avc
[18:55:04 CEST] <Gramner> BBB: oh, you changed iszero() in your second patch, I missed that. it's incorrect now :)
[18:55:06 CEST] <Gramner> patch sent
[19:47:44 CEST] <Zenk_BR> Hey, good afternoon (2;24pm In Brazil:] )
[19:52:37 CEST] <BBB> ?
[19:53:03 CEST] <BBB> Gramner: isnt that identical?
[19:53:35 CEST] <BBB> oh oops it isn't
[19:53:38 CEST] <BBB> ok patch ok :D
[19:53:39 CEST] <Gramner> the current code reads 4 bytes, skips 4 bytes, etc
[19:55:28 CEST] <cone-210> ffmpeg 03Henrik Gramner 07master:69e456d7fbc5: checkasm/vp9dsp: Fix iszero() to read the correct data
[20:57:04 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:1d0487f77f07: avcodec/pngdec: reset has_trns after every decode_frame_png()
[21:03:39 CEST] <Zenk_BR> Hey guys
[21:03:49 CEST] <Zenk_BR> i have a question =x
[21:04:43 CEST] <Zenk_BR> i'm trying convert .dav to any video formats...avi, mp4, mov...any one!!
[21:04:56 CEST] <nevcairiel> whats a dav video
[21:05:37 CEST] <Zenk_BR> http://www.openthefile.net/extension/dav
[21:06:37 CEST] <nevcairiel> its encrypted, so good luck
[21:06:40 CEST] <nevcairiel> also, you want #ffmpeg
[21:08:04 CEST] <Zenk_BR> so, ffmpeg don't convert?
[21:16:02 CEST] <durandal_1707> atomnuker: writing assim?
[21:33:27 CEST] <wm4> ubitux: wasn't part of your subtitle problem dealing with the ABI?
[21:33:35 CEST] <wm4> the ABI is free to change currently
[21:34:25 CEST] <nevcairiel> although we should probably lock it down at some point again
[00:00:00 CEST] --- Tue Sep 29 2015