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

[burek]

[00:39] <BBB> how do you compile libvpx 32bit?
[00:47] <jamrial> "./configure --target=x86-linux-gcc" i think
[00:48] <jamrial> you may have to use --extra-cflags for -m32 if you're on linux x64
[01:22] <BBB> (creating some x86-32 numbers)
[03:06] <BBB> hm& I think gnome.org kicked me off their webspace
[03:06] <BBB> can I get ffmpeg.org webspace for random stuff?
[03:06] <BBB> (like ffmpeg.org/~rbultje)
[03:08] <kierank> all the cool kids just post on github now
[03:09] <BBB> hm
[03:09] <BBB> how does that work?
[03:10] <kierank> I think you just commit a file in markdown
[03:10] <kierank> and then share it
[03:11] <BBB> commit a file in markdown?
[03:11] Action: Daemon404 just uses dropbox
[03:11] <Daemon404> for files
[03:11] <BBB> dropbox has adds
[03:11] <kierank> BBB: markdown is github's markup language
[03:11] <kierank> and you just make a repo like github.com/bbb/blog
[03:11] <kierank> and make a file like github.com/bbb/blog/2014-12-27/ or whatever
[03:12] <kierank> and share that
[03:14] <kierank> or you can be really hipster and get a livejournal
[03:14] <aetasx> thought girls gave that up in favor of spamming it on their facebook pages
[03:16] <BBB> https://raw.githubusercontent.com/rbultje/public/master/vp9-32bit.png
[03:16] <BBB> yay
[03:16] <BBB> thanks kierank
[03:17] <kierank> wow that's a big speed boost
[03:30] <jamrial> what version of libvpx is this? odd that sse2 and ssse3 are the same with it
[03:50] <michaelni> BBB, i can create an account on ffmpeg.org if you need one and send me a public ssh key. Not sure its optimal for random stuff though
[04:49] <BBB> jamrial: todays git head of libvpx
[04:50] <BBB> jamrial: I think our cpuflags dont work on them, so their sse2 may have ssse3 enabled also
[04:50] <BBB> jamrial: Id have to force-disable it and Im just too lazy for that :]
[04:51] <BBB> (as in: edit the optimizations template file and remove all ssse3 functions manually)
[04:51] <BBB> michaelni: Ill try github for now, but thanks
[04:54] <BBB> michaelni: if you want to review the branch I sent to ubitux earlier, thatd be nice
[04:54] <BBB> Im hoping to merge that
[04:55] <BBB> anyway, bed now
[04:55] <jamrial> BBB: your vp9 blog post on gnome is still up, so your webspace was not deleted
[05:07] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:fa0e5ffb89b1: avfilter/vf_cropdetect: add yuv440p and yuv410p support
[08:01] <Zeranoe> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler"
[12:17] <wm4> ==11780== Use of uninitialised value of size 4
[12:17] <wm4> ==11780==    at 0x4FE79FC: ??? (h264_qpel_10bit.asm:853)
[12:17] <wm4> is this interesting?
[12:19] <nevcairiel> depends, sometimes this is  intentional for some reason
[12:19] <wm4> it's in asm, so it probably doesn't matter
[12:27] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:4cfbeef31d4e: h264: factor hwaccel pixel formats list
[12:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:57089084ba7e: Merge commit '4cfbeef31d4e6096c0596359d212f5d99a7ba4b5'
[12:34] <arwa> When I am testing the formats for pp7, this is the result - "detected 2 logical cores"
[12:34] <arwa> What does this mean?
[12:40] <aetasx> wm4: you have a particular dev IDE you use?
[12:41] <wm4> no
[12:41] <aetasx> just using vim or something?
[12:41] <wm4> I'm using kate... why me?
[12:42] <aetasx> cause no one else is here :p
[12:52] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:57b6704ecd0f: avcodec: add AVCodecContext.sw_pix_fmt
[12:52] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:d16079abf473: Merge commit '57b6704ecd0f56d6a3092e448687cfd837bb0ac1'
[13:04] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:6c99c92a42ad: libavcodec: add AV_HWACCEL_ALLOW_HIGH_DEPTH flag
[13:04] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:ddb9a24a7f11: Merge commit '6c99c92a42add7f6a462114d5a4a53c93c551058'
[13:12] <ubitux> wm4: mmh afaik we tend to fix these as well (the overreads are fine but shouldn't end up in uninitialized data)
[13:15] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:c220a60f92dd: vdpau: add helper for surface chroma type and size
[13:15] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:d7aaeea5402c: Merge commit 'c220a60f92dde9c7c118fc4deddff5c1f617cda9'
[13:16] <michaelni> arwa, it just means your computers CPU has 2 logical cores
[13:18] <arwa> Ohh...okay!
[13:19] <arwa> If I am not getting any error, does this mean that all the pixel formats are supported?
[13:19] <arwa> Well , the command I used was - libavfilter/filtfmts-test pp7
[13:23] <BBB> jamrial: yeah, but I cant log in to it :(
[13:25] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:ebd5320afd42: vdpau: add support for 4:2:2 and 4:4:4 chroma sampling
[13:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:751731540f5b: Merge commit 'ebd5320afd42d4315851f3e0ca7f5d4a6300eb68'
[13:35] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:1f9237f2ac46: avconv_vdpau: allocate video surface of VDPAU-specified size
[13:35] <BBB> (I can log in to my blog, but not into my webspace)
[13:35] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:a6ab9ed50d8a: Merge commit '1f9237f2ac46dfbed1bfa1f4f0f1314c2a1d62ec'
[14:24] <BBB> jamrial: new results with corrected VPX_SIMD_CAPS_MASK values uploaded (same location)
[14:24] <BBB> (for reference: VPX_SIMD_CAPS_MASK=7 is sse2, VPX_SIMD_CAPS_MASK=31 is ssse3)
[14:26] <BBB> maybe we can couple that to out -cpuflags cmdline option smehow?
[14:26] <BBB> (I realize this would be hacky, I dont see an API to set the mask, maybe open a featur request against libvpx)
[14:35] <saste> ubitux, fine to push tblend?
[14:54] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:737d35e33408: vdpau: add support for the H.264 High 4:4:4 Predictive profile
[14:54] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:6f764d291121: Merge commit '737d35e33408263c04d7730f5487eed0d04938ba'
[15:13] <ubitux> saste: i think s/consecutives/consecutive/
[15:13] <ubitux> "for @code{blend}" ’ "for the @code{blend} filter"
[15:13] <ubitux> same below
[15:15] <ubitux> saste: otherwise LGTM
[15:16] <cone-78> ffmpeg.git 03Anton Khirnov 07master:60d4c6ff7646: h264: restore a block mistakenly removed in e10fd08a
[15:16] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:9e893473297e: Merge commit '60d4c6ff76467d4d8f55c1cc61ab6c618e8ea2f3'
[15:59] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:336bb3f706ea: avutil/dict: Use av_freep() to avoid leaving stale pointers in memory
[15:59] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:6d639ecf4472: avutil/audio_fifo: use av_freep() to avoid leaving stale pointers in memory
[15:59] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:05e74ac2f3f3: avutil/hmac: use av_freep() to avoid leaving stale pointers in memory
[16:18] <cone-78> ffmpeg.git 03Stefano Sabatini 07master:d4fd3f24e86f: lavfi: add tblend filter
[16:30] <BBB> ubitux: any progress on my 15 patches? :-p
[16:54] <ubitux> BBB: can you submit them to the mailing list?
[16:54] <ubitux> i'll review in the next hours probably
[16:54] <ubitux> gtg now
[17:00] <BBB> ok
[17:03] <BBB> ubitux: ok, you asked for it
[17:22] <aetasx> wth is tblend
[17:23] <wm4> aetasx: RTFML
[17:23] <aetasx> I get enough emails already ;)
[17:25] <ubitux> aetasx: main usage is to make a diff between 2 successive frames
[17:25] <aetasx> ah, interesting
[18:21] <ubitux> Tim_G: why would that be the wrong patch?
[19:09] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:ed96830afc05: avfilter/vf_blend: Fix AVClass
[19:15] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:cc91488588ac: avfilter/vf_cropdetect: Factorize duplicated code using a macro
[19:40] <ubitux> akira4: i will look deeper into libdvd* tomorrow (CET tz here)
[19:40] <ubitux> akira4: meanwhile, did you try to make the original protocol patch work?
[21:07] <Zeranoe_> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler"
[21:12] <BBB> ubitux: new patchset pushed with all comments addressed
[21:15] <Zeranoe_> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler"
[21:15] <Zeranoe_> Woops
[21:17] <BBB> ubitux: if you have no further comments, poke michaelni so he can merge from github, I guess
[22:06] <ubitux> BBB: yeah, no further comment
[22:06] <ubitux> you can "pull request" :)
[22:06] <ubitux> merge*
[22:09] <michaelni> merging rbultje/vp9-32bit would add 46 commits, the patchset contained 15 IIRC, i assue this is not intended
[22:11] <jamrial> the rest were already merged in a squashed form before, i think
[22:17] <michaelni> yes, i could cherry pick the last 15, they apply cleanly or BBB could rebase them and i could merge the result. But either way merging from this branch will alway have this problem as long as these commits mismatch the squashed one from master
[22:21] <ubitux> just wait for a rebase
[22:22] <michaelni> ok
[22:24] <cone-963> ffmpeg.git 03Clément BSsch 07master:56e432b27b8f: avutil/atomic: reuse ret to avoid dereferencing twice the same value.
[22:31] <ubitux> so... ilpack can be dropped or not yet?
[22:35] <BBB> michaelni: its now 16
[22:36] <BBB> michaelni: ubitux asked for an extra one to add my name to copyright list
[22:37] Action: Daemon404 bets chrome still wont switch to ffvp9
[22:37] <BBB> file a bug so they can track it :D
[22:37] <BBB> (cr.bug.com?)
[22:37] <Daemon404> i have many open bugs with chrome
[22:37] <BBB> or whatever it was
[22:37] <Daemon404> its akin to throwing my woes into a pit
[22:38] <nevcairiel> dont they use it now
[22:38] <nevcairiel> i thought they actually did
[22:38] <Daemon404> only small things like "DASH is broken and nonconformant" and "does not handle bt709 properly full stop"
[22:38] <BBB> lets see
[22:38] <nevcairiel> people on d9 complained that it was so extremely slow on 32-bit at least
[22:39] <nevcairiel> unless theirs is as well :P
[22:39] <Daemon404> nevcairiel, i thought the gave some reason like error resiliance
[22:39] <Daemon404> or something
[22:39] <ubitux> chromium will probably not switch to ffvpx because they need libvpx anyway i suppose
[22:40] <ubitux> typically because vp10 or whatever project they fancy
[22:40] <Daemon404> encoding too
[22:40] <Daemon404> webrtc crap
[22:40] <ubitux> in chromium?
[22:40] <ubitux> ah..
[22:40] <ubitux> is that really possible to make real time encoding with libvpx?
[22:40] <ubitux> i strangely have high doubts :')
[22:40] <Daemon404> vp8 yeah
[22:40] <ubitux> yeah vp8 ok.
[22:42] <michaelni> BBB did you push the rebased 16 to your github ?
[22:42] <BBB> I think I did
[22:43] <kierank> ubitux: i believe yes
[22:43] <BBB> let me see
[22:43] <kierank> ubitux: but I am assuming swscale is doing the right thing
[22:43] <ubitux> kierank: so what's the magic equivalent command line?
[22:43] <kierank> just vf_scale from 420 to 422
[22:43] <ubitux> (so we can document it in the drop commit message)
[22:43] <kierank> with interlaced
[22:43] <BBB> michaelni: yeah its there
[22:43] <BBB> https://github.com/rbultje/ffmpeg/commits/vp9-32bit
[22:44] <kierank> 9:40 PM <"ubitux> is that really possible to make real time encoding with libvpx? --> some people say it is
[22:44] <BBB> vp9/x86: save one register in loopfilter surface coverage. until top
[22:45] <ubitux> i wonder if i reach 1 fpm by encoding with libvpx/vp9 
[22:45] <Daemon404> ubitux, im doing my latest round of 4k testing right now
[22:45] <Daemon404> im debating even botherign with vp9
[22:46] <ubitux> is the first frame encoded yet?
[22:46] <Daemon404> ;p
[22:47] <BBB> is x265 that much better? Most comments I read complain it has the same issue as libvpx, its slow or not better than x264
[22:47] <michaelni> git fetch rbultje && git log master..rbultje/vp9-32bit --oneline | wc
[22:47] <michaelni> still gives 45
[22:48] <BBB> michaelni: well you merged it previously :)
[22:48] <nevcairiel> BBB: its not *that* slow ;)
[22:48] <BBB> nevcairiel: oh no, it takes only 17 days to encode a frame, instead of 24
[22:48] <BBB> such progress"
[22:48] <BBB> yay"
[22:48] <BBB> look how cool"
[22:49] <nevcairiel> nah its actually acceptable
[22:49] <BBB> maybe its more recent perormance is acceptable
[22:49] <nevcairiel> quality exceeds x264 on low bitrates at least, on high rates its about equal still i think
[22:49] <BBB> in the past it was poor
[22:49] <Daemon404> BBB, x265 right now reminds me of using x264 on my athlon xp back then
[22:49] <michaelni> BBB i can merge it but there will be 30 duplicate commits
[22:49] <Daemon404> that is, it's reasonably fast
[22:50] <Daemon404> for what it is
[22:50] <BBB> michaelni: let me rebase on top of new master, one sec
[22:51] <Daemon404> nevcairiel, i.e. Not Worth It
[22:51] <Daemon404> my main issue with vp9 is not actually teh speed fwiw
[22:51] <Daemon404> it's the terrible ratecontrol.
[22:51] <nevcairiel> Daemon404: at 4k its probably useful, as the compression gains are actually there
[22:52] <Daemon404> nevcairiel, we'll see, i am going to look at that on monday 
[22:52] <nevcairiel> but we all know that x264 also didnt beat xvid in the beginning, but of course you have to start somewhere
[22:52] <nevcairiel> h265/hevc should be with us for a while
[22:53] <Daemon404> x264 didnt beat xvid at high rates in mainline x264 until aq and psyrd got pushed
[22:53] <Daemon404> unless you disabled trellis and lowered the deadzone settings
[22:53] <Daemon404> which is kinda cheating
[22:54] <Daemon404> that said
[22:54] <Daemon404> x264's ratecontrol always hit teh target well (sometimes too well)
[22:54] <Daemon404> xvid's was criminally bad
[22:55] <JEEBsv> yeah
[22:55] <jamrial> hevc will be with us for a while indeed. blu-ray 4k and streaming will guarantee it
[22:55] <Daemon404> i am still waiting for teh fabled day when there is a way to actually play it back for most people
[22:56] <Daemon404> i dont count "you can get hevc if you stream to a smart tv"
[22:56] <BBB> michaelni: rebasing& will take a few minutes to confirm it all still works
[22:57] <michaelni> sure, no  hurry
[22:57] <Daemon404> are vp9 bitstreams trivially concatable?
[22:57] <michaelni> BBB and thanks
[22:57] <nevcairiel> Daemon404: once blu-ray picks up hevc playback stuff will have to adapt
[22:58] <Daemon404> nevcairiel, yea
[22:58] <Daemon404> but tbh, one of the only reasons h264 caught on on teh web IMO was flash
[22:58] <Daemon404> and flash is not getting hevc.
[22:58] <nevcairiel> and with the openhevc simd, software playback is also quite acceptable performance wise
[22:58] <nevcairiel> without, its just painfully slow
[22:58] <cone-963> ffmpeg.git 03Reimar Döffinger 07master:035180901de9: r210enc.c: Simplify and never store more than 10 bits.
[22:58] <Daemon404> nevcairiel, MS's filters used in IE may be ok
[22:58] <jamrial> i thought it caught on because anime switched to it from xvid
[22:59] <nevcairiel> Daemon404: thats only win10 however
[22:59] <Daemon404> jamrial, well i meant on the web.
[22:59] <BBB> why dont people write proper asm for hevc?
[22:59] <Daemon404> youtube and pals
[22:59] <Daemon404> BBB, chicken and egg problem
[22:59] <BBB> like, not the intrinsics crap
[22:59] <BBB> it seems people dont care about hevc
[22:59] <BBB> that is
[22:59] <BBB> they want the pretty software
[22:59] <BBB> but they dont want to pay for it, or write it themselves
[22:59] <Daemon404> nobody cares about anything post-h264 yet in reality
[22:59] <BBB> they just want to leach off the work of others
[22:59] <Daemon404> except youtube
[22:59] <nevcairiel> the intrinsics are decently fast at the very least
[22:59] <Daemon404> and marketing folks
[22:59] <jamrial> BBB: plepere was porting all those intrinsics to yasm
[22:59] <jamrial> but stopped midway
[23:00] <BBB> right that was 6 months ago
[23:00] <BBB> right
[23:00] <BBB> so now what?
[23:00] <jamrial> his contract with openhevc ended. nobody seemingly took his place
[23:01] <Daemon404> nobody wants to pay because there is no direct benefit right now
[23:01] <Daemon404> chicken and egg, liek i said
[23:01] <BBB> if investors worked this way
[23:01] <BBB> we would all be really, really, really, poor and unemployed
[23:01] <Daemon404> thats how investors work in parts of europe
[23:01] <ubitux> and have more time to work on ffmpeg \o/
[23:02] <Daemon404> deliciously stagnant
[23:02] <Daemon404> :)
[23:02] <BBB> hehe
[23:03] <nevcairiel> i would work on porting the asm, but i'm too bad at the asm, it takes too long to be fun :p
[23:03] <BBB> at least 32bit performance of ffvp9 is awesome
[23:03] <BBB> hevc & yeah ...
[23:03] <BBB> I hope people use ffmpeg in their hevc vs vp9 comparisons
[23:03] <BBB> it will be awesome (for vp9)
[23:03] <nevcairiel> the advantage of the intrinsics is that it magically works in 32-bit :d
[23:03] <BBB> the disadvantage of intrinsics is that it sucks
[23:04] <Daemon404> i sitll dont see vp9 beign adopted due to its abysmal encoder
[23:04] <nevcairiel> eh decoding speed isnt a common thing for codec comparison
[23:04] <Daemon404> i asked alex about the encoder at vdd btw
[23:04] <BBB> Daemon404: true
[23:04] <Daemon404> he said its because theyre 'tailoring it to their biggest customer'
[23:04] <BBB> the encoder is kinda shit (ask ubitux :D)
[23:04] <Daemon404> aka youtube
[23:04] <jamrial> nevcairiel: after an unholy and most likely unnecesary amount of movs to and from memory :p
[23:04] <nevcairiel> jamrial: nah its actually not that terrible
[23:04] <Daemon404> since they do distributed GOP encoding + implement their own ratecointrol hacks
[23:04] <Daemon404> they dont care
[23:04] <nevcairiel> at least with recent compilers
[23:04] <Daemon404> thus, libvpx oesnt care
[23:04] <Daemon404> and nobody else will use it.
[23:05] <BBB> so we need to write our own encoder :)
[23:05] <jamrial> Daemon404: it wont be adopted because Google doesn't even try to get people to adopt it, for some reason
[23:05] <BBB> anyway
[23:05] <BBB> vp9 ...
[23:05] <BBB> theyre already on vp10
[23:05] <BBB> so who care
[23:05] <Daemon404> jamrial, not true
[23:05] <Daemon404> they phone us (Vime) periodically
[23:05] <Daemon404> and feed us a bunch of lies
[23:05] <Daemon404> :D
[23:05] <Daemon404> Vimeo*
[23:05] <jamrial> haha
[23:06] <jamrial> who cares about vp10 when there's daala? :p
[23:06] <Daemon404> i am skeptical of daala
[23:07] <Daemon404> xiph has this way of deciding on a way to do stuff, and hammering it until it works
[23:07] <Daemon404> see: all previous xiph codecs except opus
[23:07] <Daemon404> also ogg.
[23:07] <nevcairiel> vorbis isnt too terrible, if you dont count its ogg container
[23:08] <Daemon404> it was quite bad until a third part worked on it
[23:08] <Daemon404> (aotuv)
[23:08] <Daemon404> party*
[23:08] <Daemon404> the encoder i mean.
[23:08] <BBB> I do think daemon404 has a point
[23:08] <BBB> you should choose techniques because theyre better
[23:08] <BBB> they just choose techniques because they sound cool and then they advertise it like a iraqi minister of public affairs
[23:09] <BBB> and then they withdraw it because it sucks
[23:09] <BBB> and circle back to step 1 for a replacement technique
[23:09] <Daemon404> well
[23:09] <Daemon404> also
[23:09] <Daemon404> xiphcode.c
[23:09] <Daemon404> incomprehensible
[23:10] <BBB> michaelni: https://github.com/rbultje/ffmpeg/commits/vp9-32bit-lpf
[23:10] <BBB> yeah, xiphcode is just shit
[23:10] <Daemon404> actually this all reminded me
[23:11] <Daemon404> i should submit a patch to vp9
[23:11] <Daemon404> alex told me where/how i shoudl add bt709 support.
[23:11] <Daemon404> btu :effort:
[23:11] <BBB> I believe it already has bits in the bitstream for it
[23:11] <kierank> i don't understand the people who say they are using vp9 in realtime
[23:11] <BBB> (in profile 1 and up)
[23:11] <Daemon404> BBB, it does not
[23:11] <Daemon404> it only has yuv and rgb
[23:11] <BBB> no it has bt709
[23:11] <BBB> I reviewed the patch
[23:11] <Daemon404> oic
[23:11] <BBB> Im not saying its exposed in the cli
[23:11] <BBB> but the bits in the bitstream are there (normatively)
[23:12] <Daemon404> also chrome ignores colorspace flags anyway
[23:12] <Daemon404> and treats everythign as 601
[23:12] <BBB> that too
[23:12] <BBB> lol
[23:12] <BBB> :)
[23:12] <Daemon404> BUT
[23:12] <Daemon404> only on sw decode
[23:12] <kierank> and chromecast doesn't work with 25hz tvs
[23:12] <Daemon404> hw decode uses drivers -> Does it right
[23:12] <Daemon404> so i have confused-as-hell users
[23:12] <Daemon404> \o/
[23:12] <BBB> yay
[23:12] <kierank> Daemon404: is chrome using swscale?
[23:12] <BBB> actually profile 0 probably has these bits also
[23:12] <BBB> anywya
[23:13] <Daemon404> kierank, no
[23:13] <Daemon404> libyuv
[23:13] <BBB> baby steps
[23:13] <BBB> I can hook up the ffvp9 colorspace bits if the libvpx ones are hooked up
[23:13] <BBB> so far its meaningless :D
[23:13] <Daemon404> lol yea
[23:13] <jamrial> what do they use ffmpeg libs for? ffvp8? audio codecs?
[23:13] <Daemon404> sw h264
[23:14] <jamrial> ah
[23:14] <Daemon404> probably vorbis or something
[23:14] <Daemon404> chrome is also the blocking browser on me for some DASH stuff
[23:14] <Daemon404> i swear chrome is teh new IE6
[23:14] <Daemon404> have to hack around its crap
[23:14] <jamrial> firefox uses the cisco openh264 because patents
[23:14] <Daemon404> it will use system hw iirc
[23:15] <Daemon404> if possible
[23:15] <Daemon404> dxva and pals
[23:15] <jamrial> on windows it can also use ms h264 decoder i think
[23:15] <Daemon404> yes
[23:16] <Daemon404> on os x it has VDA in beta iirc
[23:16] <Daemon404> but youd be silly to use firefox on os x
[23:17] <nevcairiel> someone was trying to get MS to support Opus in html5 audio, that would be a nice addition
[23:18] <Daemon404> its somewhat likely
[23:18] <Daemon404> they did create half of opus technically
[23:18] <Daemon404> also opus-in-mp4 is Almost Ready i think
[23:18] <Daemon404> waiting to mp4a reg to go through i think.
[23:19] <nevcairiel> i would love to have a option on android to support opus in some sort of streaming format, but apparently android 5.0 still doesnt do opus in ts, only plain .opus for audio playback
[23:20] <Daemon404> .opus is just ogg
[23:20] <Easyfab> For vp9 I see some days ago this -> https://github.com/ittiamvpx/libvpx   ? I don't try because I don't have a decent opencl gpu  and it's based on old 1.3 version. Has someone tried it for the speed ?
[23:25] <nevcairiel> opencl encoding has generally been a big disappointment, no matter which codec
[23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:c013ca58c534: vp9/x86: save one register in loopfilter surface coverage.
[23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:8132629bd587: vp9/x86: make cglobal statement more conservative in register allocation.
[23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:e59bd0898686: vp9/x86: slightly simplify 44/48/84/88 h stores.
[23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:d1c55654e11c: vp8/x86: remove unused register from ABSSUB_CMP macro.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:418c202c6363: vp9/x86: simplify ABSSUM_CMP by inverting the comparison meaning.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:e42409479f09: vp8/x86: move variable assigned inside macro branch.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:8ea2194ebb57: vp9/x86: store unpacked intermediates for filter6/14 on stack.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:7f80c3344cc0: vp8/x86: save one register in SIGN_ADD/SUB.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:75f8e520897f: vp9/x86: make filter_44_v work on 32-bit.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:6433a9133f41: vp9/x86: make filter_88_v work on 32-bit.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:0cc9c23ea171: vp9/x86: make filter_48/84_v work on 32-bit.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:047088b8c6cf: vp9/x86: make filter_16_v work on 32-bit.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:8a1cff1c355d: vp9/x86: make filter_44_h work on 32-bit.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:b26bc3520f9a: vp9/x86: make filter_48/84/88_h work on 32-bit.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:afd8c464b7ea: vp9/x86: make filter_16_h work on 32-bit.
[23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:3aefca68cae6: vp9/x86: add myself to copyright holders for loopfilter assembly.
[23:27] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:17dde95ec52e: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[23:30] <BBB> yay
[23:30] <nevcairiel> so are you done now, or still more to do? :d
[23:30] <BBB> thats it
[23:31] <BBB> I mean tehcnically we could now optimize filter_4_16 or filter_8_16
[23:31] <BBB> but theyre not very important
[23:32] <nevcairiel> that should make those 32-bit or pre-ssse3 users happier, some complained a bit about the slowness in their setups
[23:32] <BBB> yes
[23:32] <nevcairiel> i should push out an update to all those that use my stuff
[23:33] <nevcairiel> lets see if fate remains happy, i wanted to work on some stuff next week anyway
[23:40] <Zeranoe_> Looking at the code for movenc.c (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;hb=HEAD#l1922) it looks like descr does not accept user override? I'm guessing these meta parts cannot be changed... Perhaps a patch is in order
[23:45] <nevcairiel> you can shove it into AVStream->metadata as "handler"
[23:45] <nevcairiel> and the code will use it
[23:46] <Zeranoe_> nevcairiel: Can it be done though CLI?
[23:46] <nevcairiel> i dont use the cli
[23:48] <nevcairiel> it does have -metadata but i dont know if you can make it apply to a stream
[23:48] <BBB> Ive updated the blog post to cross the line that says 32bit doesnt work
[23:48] <BBB> feels kind of official now
[23:48] <BBB> anyway
[23:48] <BBB> lets do something thats not 32bit hammering
[23:48] <BBB> (32bit seriously sucks)
[23:49] <nevcairiel> i think you can do -metadata:s:1 to set metadata for stream #1
[23:50] <nevcairiel> not tested if it actually works, some SO posts claimed so :P
[23:51] <jamrial> "8 gprs is ought to be enough for anyone"
[23:52] <BBB> stack spill/unspill deluxe
[23:52] <nevcairiel> how many regs do alternate architectures have, like arm?
[23:53] <jamrial> some variants have 32 i think
[23:53] <nevcairiel> typically 15 GPRs apparently
[23:54] <Zeranoe_> nevcairiel: That doesn't seem to change it
[23:54] <jamrial> arm8 has 32 gprs and 32 simd
[23:57] <nevcairiel> Zeranoe_: works here
[23:58] <nevcairiel> Zeranoe_: ffmpeg -i foo.mkv -c:v copy -c:a copy -metadata:s:a handler="FooHandler" test.mp4
[23:58] <nevcairiel> gives the audio stream a handler "FooHandler"
[23:59] <Zeranoe_> nevcairiel: Oh, let me try that, I did handler_name="English"
[00:00] --- Sun Dec 28 2014