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

[burek]

[00:00] <cone-105> ffmpeg.git 03Timothy Gu 07master:108dec305505: x86: dsputilenc: convert hf_noise*_mmx to yasm
[00:00] <kierank> 9:11 PM <"Daemon404> england is shitty like this because of their stupid timezone
[00:00] <kierank> I'm sorry that we invented time
[00:01] <iive> kierank: i thought that the french did. and then britain stole it.
[00:47] <cone-105> ffmpeg.git 03Carl Eugen Hoyos 07master:12d6ae014212: Fix fate-aac-ln-encode with --target-path (second try).
[00:47] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:03acecae84ae: Merge remote-tracking branch 'cehoyos/master'
[01:12] <cone-105> ffmpeg.git 03James Almer 07master:3ab4f96a91e9: motion-test: force C functions for the reference C context
[01:12] <cone-105> ffmpeg.git 03James Almer 07master:625ffa145704: x86/motion_est: sad_{x, y}2_mmxext functions are bitexact
[02:07] <BBB> ubitux: pheew finally updated the blog post with your new results (http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/)
[02:14] Action: Daemon404 wonders if he can retest vp9 now, if smarter__ fixed the broken RC
[02:23] <smarter> Daemon404: I haven't had time to look at RC recently, I was planning to do that in the next few days
[02:23] <Daemon404> o
[02:23] <smarter> Daemon404: but there's been a ton of fixes related to RC in the past few months
[02:23] <Daemon404> but is the encoder fast enough to finish before the heat death of the universe
[02:24] <Daemon404> as someone else so eloquently put it
[02:24] <smarter> not unless something magic happened while I wasn't looking
[02:24] <Daemon404> o ok
[02:25] <smarter> my list of things to look at are : 1) RC 2) Psy 3) speed stuff, but I lack time :]
[02:25] <Daemon404> heh
[02:25] <Daemon404> google seems to have this idea that everyone should adopt vp9 (but not android)
[02:25] <Daemon404> but only the decoder
[02:25] <Daemon404> presumably to watch... youtube
[02:25] <Daemon404> because they give 0 fucks about the encoder
[02:25] <Daemon404> afaict
[02:25] <smarter> I think KitKat has libvpx with vp9
[02:25] <smarter> for decoding
[02:26] <Daemon404> i thought that was only vp8
[02:27] <smarter> they do care about the encoder, but I guess speed is not what they care most about for their usecase
[02:28] <Daemon404> they dont care about adoption of the encoder
[02:28] <Daemon404> not one bit
[02:28] <Daemon404> they absolutely and utterly failed to convince us to use it :P
[02:29] <smarter> well, there's been a lot of work on a real-time mode, but not much on making the best quality mode much faster
[02:29] <Daemon404> (even with mild lies!)
[02:29] <Daemon404> realtime mode isnt interesting if it is uglier than x264's realtime
[02:29] <Daemon404> why would i care
[02:29] <Daemon404> :V
[02:29] <smarter> good realtime is hard
[02:30] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:4fb4bf7289de: avcodec/lagarithrac.h/lag_get_rac: drop apparently unneeded operations
[02:30] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:d8ae0dfd999d: avcodec/lagarithrac: increase LUT from 256 to 1024 bytes
[02:30] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:fbaf73a33d50: avcodec/lagarithrac: lag_get_rac: use normal division
[02:30] <Daemon404> smarter, yes but my point is
[02:30] <Daemon404> they entirely ignore that it simply is not economical for anyone but google themselves to encoder vp9 at cale
[02:30] <Daemon404> in such a way where it beat x264
[02:31] <smarter> yeah I'm not disagreeing with that :)
[02:35] <jamrial> x265 released v1.1 a couple hours ago
[02:36] <iive> wow, they beat x264 to it.
[02:36] <Daemon404> "beat"
[02:36] <jamrial> that's a pretty fast schedule. it's been one month since 1.0
[02:36] <Daemon404> their versions mean nothing
[02:36] <Daemon404> the company just has deadliens for version #s
[02:36] <Daemon404> they dont signify anything
[02:37] <jamrial> you could say the same about ffmpeg. a numbered release every 3 months
[02:47] <kierank> llogan: nice tweeting
[02:48] <kierank> 1:23 AM <"Daemon404> but is the encoder fast enough to finish before the heat death of the universe
[02:48] <kierank> 1:24 AM <"Daemon404> as someone else so eloquently put it
[02:48] <kierank> I will take credit for that :)
[02:55] <Daemon404> ah dslkjlskdjfllk
[02:55] <Daemon404> what a easy to remember nam
[02:55] <Daemon404> e
[02:55] <Daemon404> an*
[02:58] <kierank> Daemon404: https://www.youtube.com/watch?v=lsFAokXCxTI
[03:07] <Daemon404> lul.
[04:01] <michaelni> Daemon404, ok if i apply "Disable xform_asm on little endian" with a more verbose commit message ? or do you have a better idea ?
[04:34] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:19c9d1e8e71d: avcodec/h264: in the absence of recovery points, be more tolerant on accepting plain I frames
[05:31] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:571ab8344a9a: avformat/avidec: allow rounding errors between scale/rate and timebase
[05:51] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:d5c9d055ea3d: avcodec/x86/dsputilenc_mmx: fix build without yasm
[08:10] <ubitux> BBB: thx :)
[08:11] <ubitux> BBB: "beating libvpx by a lot at high bitrates"  is this missing a word or that's correct english?
[10:39] <plepere> I have a new version of my ASM idct patch for hevc. Should I send it through the mailing list or does someone want to review it before ?
[12:44] <michaelni> plepere, i suggest ML
[12:44] <michaelni> thats as noone replied in 2h ...
[12:53] <cone-277> ffmpeg.git 03Janne Grunau 07master:d5a55981986a: build: check if AS supports the '.func' directive
[12:53] <cone-277> ffmpeg.git 03Michael Niedermayer 07master:a40c338a00a4: Merge commit 'd5a55981986ac5d1a31aef3a8d16eaff8534a412'
[12:54] <BBB> plepere: ml is always fine
[12:54] <BBB> ubitux: I think its correct, but Im not a native speaker so Im not sure ..
[12:54] <ubitux> BBB: same here, ok :))
[12:56] <BBB> Daemon404: yeah the main problem is speed, ubitux and I complained about that also
[12:57] <ubitux> at that point i wonder if we shouldn't even use the word "speed" at all
[12:57] <ubitux> that's giving the encoder too much credit
[13:02] <cone-277> ffmpeg.git 03Martin Storsjö 07master:95b7fa1729b9: oggenc: Support flushing the muxer
[13:02] <cone-277> ffmpeg.git 03Michael Niedermayer 07master:c7e54628e30a: Merge commit '95b7fa1729b93bbb3f4fb85a5c0cb53cf970c3c7'
[13:21] <cone-277> ffmpeg.git 03Christophe Gisquet 07master:11b470381354: huffyuvdec: implement trick
[13:41] <cone-277> ffmpeg.git 03Christophe Gisquet 07master:deadcf5e71bb: huffyuvdec: implement trick for BGR
[13:45] <BBB> ubitux: or write your own :)
[13:45] <BBB> multimedia-mike-style
[13:45] <plepere> ok, I've sent my patch
[13:45] <BBB> http://multimedia.cx/eggs/the-worst-vp8-encoder/
[13:49] <ubitux> heh, well yeah no :)
[13:49] <BBB> http://multimedia.cx/eggs/the-big-vp8-debug/
[13:49] <BBB> ok anyway enough mike-hugging
[13:49] <BBB> brb
[13:50] <ubitux> ah, missed that post
[13:50] <ubitux> looks nice
[16:12] <Daemon404> [FFmpeg-devel] add HEVC codec into flv format
[16:12] <Daemon404> oh god
[16:12] <Daemon404> WHYYYYY
[16:13] <j-b> the answer is: no.
[16:13] <Daemon404> i do not think hevc is defined in flv
[16:13] <Daemon404> like, at all
[16:14] <j-b> I checked.
[16:14] <j-b> it's not
[16:28] <j-b> lol
[16:28] <kierank> j-b: it's because those chinese gpl violators did it
[16:28] <plepere> kierank won by KO
[16:28] <Daemon404> hah
[16:30] <kierank> there's a thread with strongene in it that I cc'd a load of people in
[16:30] <kierank> it's hillarious
[16:31] <plepere> isn't there an x86 instruction or macro to do FFMIN() ? I feel that the only way to do it without jumps is by going SSE with pmin instuctions.
[16:32] <Daemon404> ...
[16:32] <Daemon404> >because the Strongene James is my friend
[16:32] <Daemon404> hahahahahaha
[16:32] <kierank> oh wow
[16:32] <j-b> wow
[16:33] Last message repeated 1 time(s).
[16:34] <kierank> there
[16:34] <iive> plepere: there is cmov too
[16:36] <kierank> I may have taken the piss too much
[16:36] <j-b> kierank: you are mean
[16:36] <Daemon404> no no no
[16:37] <Daemon404> i applaud kierank 
[16:37] <Daemon404> good show.
[16:37] <kierank> Was a bit mean
[16:39] <plepere> iive, is it a good practice or is it still a jump ?
[16:40] <iive> plepere: it is conditional mov, so no jumps at all. the only problem is that it is i686 instruction. not really a problem now days.
[16:41] Action: plepere slow claps kierank 
[16:41] <plepere> thanks iive. :)
[16:42] <kierank> The strongene encoder is an x264 ripoff and the decoder is a rip off of lavc in some way
[16:42] <Daemon404> and their app are all violators
[16:42] <Daemon404> android etc
[16:42] <Daemon404> they actually provide a patch, but theyre sitll violating
[16:43] <j-b> ok, so either he is stupid or he does not understand ...
[16:43] <Daemon404> "x265 is different with Strongenes HEVC, because x265 is open & free & open source"
[16:43] <Daemon404> i actually laughed
[16:43] <Daemon404> irl
[16:44] <JEEBsv> lol
[16:44] <JEEBsv> kierank: I applaud you, you made me laugh out loud in the tube :)
[16:45] <kierank> Daemon404: they have patches now?
[16:45] <Daemon404> yeah
[16:45] <Daemon404> i looked at one
[16:45] <Daemon404> but they still link illegally
[16:45] <Daemon404> to their own decoder statically, and to their own apps gpl-y
[16:45] <kierank> Last time I looked a year ago the entire thing was based off lavc
[16:45] <kierank> An x264
[16:45] <plepere> kierank, you should use j-b's "With my kindest regards," in your replies.
[16:46] <Daemon404> i prefer "Kindly go forth,"
[16:46] <kierank> plepere: j-b does better trolling than me to big companies
[16:47] <j-b> "kindly go fuck yourself"
[16:47] <Daemon404> j-b, what i wrote means exactly that
[16:47] <Daemon404> but only in england.
[16:47] <kierank> "Thank you for confirming you have downloaded and run the software"
[16:48] <Daemon404> i really cannot wait until dolby's patents expire
[16:48] <Daemon404> it will be much fun
[16:48] <iive> when does it expire?
[16:48] <Daemon404> for ac3?
[16:48] <Daemon404> like... 2015?
[16:48] <Daemon404> soon.
[16:49] <j-b> for ac3 decoding? probably already
[16:49] <kierank> Probably yes already
[16:50] <kierank> But they merged the docs for ac3 and eac3 so it is not clear
[16:50] <j-b> We'll have fun
[16:50] <kierank> DTS should be soon too
[16:50] <plepere> ac3 = trueHD ?
[16:50] <j-b> I just asked for a license to Dolby
[16:50] <iive> Doulby Digital
[16:50] <kierank> Dolby digital
[16:50] <iive> ops
[16:52] <iive> I think somebody from videolan once did analisys of what the patent covers. I don't remember much of it, but basically half of the patent was about speedups by using floats instead of doubles and some stuff about encoding.
[16:53] <iive> it's really old mail...
[16:53] <iive> but yeh, you don't have to actually break a patent in order to be sued for braking it.
[16:55] <Daemon404> dolby has yet to do fuck all
[16:55] <Daemon404> afaik
[16:55] <Daemon404> just scaremongering
[16:56] <ubitux> omg that thread.
[16:58] <JEEBsv> lol
[16:58] <JEEBsv> the english
[16:58] <JEEBsv> degrading
[16:59] <Daemon404> at least it isnt "huehuehue"
[17:01] <j-b> iive: could it be walken?
[17:01] <plepere> Daemon404, you put that laughing lizard image in my head now. ):
[17:01] <iive> j-b: really can't remember. i'll try to find the mail.
[17:01] <Daemon404> eh i was referring more to random brazilian spammers
[17:01] <Daemon404> predates that image
[17:02] <plepere> hehe lizard or something like that
[17:03] <Daemon404> i know the mee
[17:03] <Daemon404> meme
[17:03] <iive> if you are talking with chinese, have in mind you may also need to explain some basic concepts, on top on the language barrier.
[17:03] <Daemon404> http://i0.kym-cdn.com/photos/images/facebook/000/540/811/e45.png
[17:03] <Daemon404> this is the relevant meme for that thread
[17:04] <iive> if I remember correctly, ffmpeg had chinese developer with perfect english. he might help.
[17:04] <plepere> dang it, you made me laugh irl. haha
[17:06] <plepere> anyways, gtg. see you all.
[17:29] <j-b> Daemon404: W-T-F
[17:29] <j-b> Daemon404: Do you know where FFmpeg found the spec of h263 in flv?
[17:29] <Daemon404> yes
[17:30] <iive> j-b: can't find the mail. giving up.
[17:30] <Daemon404> justin.tv made it up
[17:30] <Daemon404> iirc
[17:30] <j-b> Daemon404: my, my, my
[17:30] <j-b> Daemon404: same for this MP4 ?
[17:30] <Daemon404> no idea about mp4
[17:30] <Daemon404> someone pointed me at https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=30bcd6a9
[17:30] <Daemon404> maybe android is to blame
[17:30] <Daemon404> i dont know.
[17:32] <j-b> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=30bcd6a945ae296ef7b36a91cc21789a05de85d9
[17:33] <Daemon404> oh android broadcaster is an app
[17:34] <ubitux> Daemon404: isn't clear_block assuming alignment?
[17:34] <j-b> Amazing stupidity
[17:34] <j-b> Amazing log
[17:34] <Daemon404> ubitux, no
[17:34] <j-b> So much solidity
[17:34] <Daemon404> the C version is literally memset
[17:34] <ubitux> yes but what about the asm version?
[17:34] <Daemon404> and i think reimplementing memset so it can assume alignment is fuckign retarded
[17:34] <Daemon404> ricing for no reason
[17:34] <Daemon404> it is a of EXTREMELY dubious value
[17:35] <ubitux> Daemon404: memset is one of the slowest function in vp9 :-°
[17:35] <fionag> I think when I last did a thing involving clear_blocks, the asm version was *quiiite* a bit faster.
[17:35] <fionag> though it likely depends on the platform.
[17:35] <ubitux> mova  [blocksq+lenq+mmsize*0], m0
[17:35] <ubitux> seems it assume alignment
[17:35] <Daemon404> ubitux, im sorry but i simply will not ever agree reimplementing a libc func is not retarded.
[17:36] <fionag> x264 has aligned_memset and aligned_memcpy too.
[17:36] <ubitux> Daemon404: the libc function doesn't assume the alignment so it's not the same thing
[17:36] <Daemon404> ... yes but youre entirely missing my point
[17:36] <Daemon404> yourer still reimplementing memset ofr the sake of ricing
[17:36] <Daemon404> which is stupid as fuck.
[17:37] <ubitux> the c version could use the AV_W*, iirc they assume alignment
[17:37] <Daemon404> i dont really know why i bother to point this out to the microoptimization captial of the world
[17:38] <Daemon404> :V
[17:38] <ubitux> now maybe it's questionable on the inline part
[17:38] <j-b> Daemon404: and of course, this justin.tv guy did not add the codec_ID with a number over 1000
[17:38] <Daemon404> nope!
[17:38] <ubitux> a memset could be inlined by a compiler, while clear_blocks in dsp might not be
[17:38] <j-b> Daemon404: because that would have made sense...
[17:38] <ubitux> so it might be interesting to compare..
[18:16] <cone-163> ffmpeg.git 03Michael Niedermayer 07master:8f4b176c55f0: avcodec/dvbsubdec: add some basic av_log debuging support
[18:51] <Daemon404> more chinese guys
[18:51] <Daemon404> \o/
[19:01] <cone-163> ffmpeg.git 03Tobias Rapp 07master:d76f0c0378df: avfilter/bufferqueue: Increase buffer queue size
[19:08] <kurosu_> memset does an awful lot of setup
[19:08] <kurosu_> to set 64 bytes to 0, just the call overhead (if the compiler doesn't inline the function) is probably slower than inlined sse code
[19:09] <kurosu_> I kind of remember dct36 in mp3 decoder calling memset for like 1KB or something - doing it inline shaved like 20% of the function time
[19:35] <llogan> kierank: thanks. got to break up the release-only-news.
[19:56] <llogan> saste: ffprobe related pull request on github (I didn't really look at it though) https://github.com/FFmpeg/FFmpeg/pull/74
[19:57] <llogan> the author is an angryman, so be prepared for insults.
[20:15] <llogan> "Pot Player"
[20:18] <cone-163> ffmpeg.git 03Luca Barbato 07master:39ec5e1cf844: avconv: Report the codec and the encoder separately
[20:18] <cone-163> ffmpeg.git 03Michael Niedermayer 07master:0efe3be71d94: Merge commit '39ec5e1cf8444f827c42effb76e5694e091bbff3'
[20:32] <cone-163> ffmpeg.git 03Carl Eugen Hoyos 07master:3c57f3ef5eff: Fix some fate filter tests with --target-path.
[20:32] <cone-163> ffmpeg.git 03Carl Eugen Hoyos 07master:7738f925a642: Fix rc_max_rate documentation.
[20:32] <cone-163> ffmpeg.git 03Michael Niedermayer 07master:6a0f9f27d576: Merge remote-tracking branch 'cehoyos/master'
[21:23] <wm4> lol that hevc in flv thread
[21:32] <Paranoialmaniac> even if flash player can't play hevc, stupid people call it hevc in __flv__
[21:37] <kurosu_> there's even a bug report (albeit older)
[21:39] <kurosu_> there was cavs for avc, what about chev for that new "standard" ?
[21:57] <llogan> looks like arch now offers a x264-10bit package in the Extra repo
[22:31] <cone-163> ffmpeg.git 03Michael Niedermayer 07master:47313bbb5f52: avcodec/dcadec: remove fishy FFMAX()
[22:31] <cone-163> ffmpeg.git 03Michael Niedermayer 07master:98ff07d1c647: avcodec/dcadec: Check dca_dmixtable index
[00:00] --- Thu Jun  5 2014