[FFmpeg-devel-irc] IRC log for 2010-05-26

[irc at mansr.com]

[00:01:23] <janneg> mru: your math is flawed. 1 * 1.25 * 0.75 = 0.9375
[00:01:49] <mru> no, gcc math is flawed
[00:02:41] <mru> I got it
[00:02:53] <mru> you can't do the calculation like that
[00:03:02] <mru> suckage is sort of inverted quality
[00:03:19] <mru> so sucking 25% more means being 25% less good
[00:03:32] <mru> thus 4.4 is 25% less good than 4.3
[00:03:38] <mru> and 4.5 is 25% more good than 4.4
[00:03:50] <mru> and it all works out
[00:04:52] <janneg> sure
[02:42:30] <Compn> is james zern in here?
[04:21:25] <CIA-93> ffmpeg: alexc * r23332 /trunk/ (4 files in 2 dirs): Add an AVSTREAM_PARSE_FULL_ONCE parsing mode to parse headers and combine packets once and only once.
[04:23:43] <CIA-93> ffmpeg: alexc * r23333 /trunk/libavformat/asfdec.c: Parse and repack the first frame of H.264 in ASF because SPS+PPS lives in its own packet.
[05:24:27] <Dark_Shikari> Yuvi: fyi, gmaxwell (iirc) showed me a graph the other day of decoding speed
[05:24:41] <Dark_Shikari> at qiis in theora that were so high that the loopfilter was off, libtheora got a big speed boost
[05:24:44] <Dark_Shikari> so there was a hump in the graph
[05:24:49] <Dark_Shikari> There was no hump for ffmpeg.
[05:24:52] <Dark_Shikari> I suspect something's up here,
[05:35:46] <astrange> it looks like vp3.c never skips the loop filter
[05:36:45] <astrange> it could use skip_loop_filter too but without nonref frames it'd be ugly
[05:38:05] <Dark_Shikari> but at low qii it does nothing
[05:38:17] <Dark_Shikari> h264 doesn't use skip_loop_filter for that
[05:39:13] <astrange> i mean it could support the skip_loop_filter option
[05:39:21] <Dark_Shikari> ah.
[05:39:24] <Dark_Shikari> that could be done too.
[05:39:28] <Dark_Shikari> well, we have it for h264 in "all" mode too
[05:39:30] <Dark_Shikari> and people use that.
[06:51:38] <KotH> salut
[06:52:12] <kshishkov> shalom
[06:52:14] <wbs> gomorgon
[06:52:46] <kshishkov> wbs: "gomorron" then
[07:04:42] <Dark_Shikari> mru: re your previous question about deblock strength in h264
[07:04:44] <Dark_Shikari> http://x264dev.multimedia.cx/?p=443
[07:04:47] <Dark_Shikari> Now it has a C version :)
[07:05:00] <Dark_Shikari> So you could write a straightforward one for x264, test it, and then easily port it to ffmpeg.
[07:05:15] <Dark_Shikari> for neon.
[08:10:40] <_av500_> gm
[08:23:01] <Dark_Shikari> http://img.photobucket.com/albums/v16/PicsOfMax/asseenby.jpg
[08:28:20] <lu_zero> good morning
[08:58:44] <_av500_> Dark_Shikari: http://topnews.in/google-s-vp8-codec-ready-showcasing-2262330
[08:59:02] <_av500_> all that ffmpeg h264 decoder bashing... :)
[09:07:13] <KotH> the downside of all that hyping: if someone voices some concerns that sound half way verifiable, then everyone will hype those concerns too
[09:07:44] <Dark_Shikari> also, I just sent an email to michael containing a nice idea to give a big decoder speed boost.
[09:07:53] <Dark_Shikari> confirmed to help in x264.
[09:09:09] <KotH> damn..
[09:09:39] <KotH> working on oss projects should be made a mandatory item on any ciriculum that teaches programming
[09:10:40] <kshishkov> there are many OSS projects of high quality like PHP
[09:10:58] <KotH> believe, the code i've here in front of me is much worse than php
[09:12:06] * kshishkov believes without any strains
[09:12:25] <KotH> i have an 80 page document that explains the architecture and everything... it's worse than reading the h.264 standard, contains at least one design error every ten pages and doesnt tell teh interesting stuff
[09:12:42] <kshishkov> sounds like proper standard
[09:13:06] <Dark_Shikari> sounds like vp8
[09:13:07] * Dark_Shikari runs
[09:13:39] <KotH> nah.. no code c&p's :)
[09:14:20] <kshishkov> Dark_Shikari: it sounds more like VP8 whitepaper disguised as standard to me
[09:16:42] <janneg> KotH: the problem is that computer science/informatik doesn't teach programming
[09:17:04] <KotH> janneg: nah.. that's no problem
[09:17:09] <KotH> janneg: i dont care about CS anyways
[09:17:27] <siretart> janneg: depends on the university
[09:17:40] <KotH> janneg: but everyone who gets a course in programming (like math, phys, bio, ee,...) should get their beating in an oss project too
[09:18:19] <kshishkov> KotH: or in programming at all
[09:18:55] <KotH> kshishkov: programming itself is not the problem most times
[09:19:10] <janneg> and I'm not even sure sure that programming skills can be teached (beyond a certain amount)
[09:19:11] <KotH> kshishkov: it's that people are not aware of the traps and pitfals they are writing
[09:19:23] <KotH> kshishkov: like using int32 for file handles
[09:19:30] * kshishkov remembers that his group at uni got ~50% of females and ~0% of people capable of programming
[09:19:35] <KotH> kshishkov: it works, yes... until you switch to a 64bit system
[09:20:08] <KotH> kshishkov: sad thing: the company internal coding guidelines demand, that each used integer type has to be fully qualified with its size
[09:20:57] <KotH> kshishkov: which makes sense when writing code for embedded systems, but when writting user space apps on a unix system, it's just asking for trouble
[09:21:01] <kshishkov> int32_on_32_bit_platform_but_64_on_64_bit_platform i, j, k;
[09:21:02] <janneg> KotH: open returns an int
[09:21:21] <KotH> janneg: yes, i know
[09:21:51] <KotH> janneg: but $guy doesnt care because $codingguideline tells him to use in32
[09:22:21] <kshishkov> yes, guidelines are for people without common sense
[09:23:32] <janneg> int is 32bit in most deployed 64bit implementations
[09:23:56] <KotH> best thing we had in our coding guidelines were: each function has to have a forward declaration at the top of the file
[09:24:27] <janneg> argh
[09:25:12] <janneg> KotH: you should summon diego to clean up your coding guidelines
[09:25:30] <KotH> i cleaned up most of the issues already
[09:25:53] <KotH> revolting against those guidelines was one of the first things i did when i started here :)
[09:26:54] <KotH> interstingly, goto was forbidden in the guidlines
[09:26:58] * KotH wonders why
[09:27:34] <kshishkov> because they heard that at school
[09:29:02] <astrange> they don't want you writing error handlers or direct-threading interpreters
[09:29:32] <Dark_Shikari> No, they want error handlers to use massive nested if ;)
[09:29:32] <pJok> god förmiddag, kshishkov :)
[09:30:20] <kshishkov> god morgon och god dag och god kväll, pJok
[09:31:47] <Dark_Shikari> http://img.photobucket.com/albums/v16/PicsOfMax/asseenby.jpg
[09:33:43] <spaam> didnt you paste that some hours ago?
[09:34:04] <spaam> one hour..
[09:34:17] <Dark_Shikari> oh wait.  I did.
[09:34:28] <Dark_Shikari> I fail at keeping track of which channels I post images in.
[09:34:29] <Dark_Shikari> but whatever.
[09:45:18] <janneg> Dark_Shikari: have you seen http://lwn.net/SubscriberLink/389029/4d93fde770743516/ "Swift and predictable reactions to WebM"?
[09:45:30] <janneg> "... compared the codecs side-by-side, encoding the same source media at the same audio and video data rates, which Garrett-Glaser did not do, ..."
[09:46:52] <Dark_Shikari> janneg: saw it long ago
[09:46:53] <Dark_Shikari> they're idiots
[09:46:56] <Dark_Shikari> what do you expect
[09:47:05] <Dark_Shikari> they can't even read the text
[10:19:33] <Compn> 'same audio rates' :D
[10:19:45] <mru> what has audio got to do with it?
[10:23:14] <mru> lol, the article mentions that old sun codec
[10:23:26] <mru> the one that requires 32-bit maths for everything
[10:23:45] <mru> because nobody uses 16-bit computers anymore, right?
[10:39:38] <CIA-93> ffmpeg: cehoyos * r23334 /trunk/libavcodec/ (avcodec.h utils.c):
[10:39:38] <CIA-93> ffmpeg: Add CODEC_CAP_EXPERIMENTAL and prefer encoders without it.
[10:39:38] <CIA-93> ffmpeg: Patch by Janne Grunau, janne-ffmpeg jannau net
[10:39:50] <mru> \o/
[11:01:09] <janneg> DonDiego: first step for avoiding experimental codecs committed
[11:01:26] <DonDiego> not quite
[11:01:41] <DonDiego> this will still use the vorbis encoder if libvorbis is not available
[11:01:57] <DonDiego> little is gained in this way
[11:02:55] <janneg> aka first step. the vorbis encoder isn't even marked as experimental yet
[11:03:38] <DonDiego> did i misread your patch?
[11:03:55] <DonDiego> explain: what happens if ffmpeg was not compiled against libvorbis?
[11:05:35] <janneg> I'm thinking of adding strict vs. experimental checks in avcodec_de|encode_*
[11:05:43] <janneg> DonDiego: currently nothing
[11:08:22] <DonDiego> the internal vorbis encoder is not used?
[11:11:13] <janneg> DonDiego: that's the goal (unless -strict experimental is used)
[11:11:33] <DonDiego> what is missing for that goal?
[11:11:59] <wbs> hmmmm, speaking of that... in the libvorbis wrapper, I noticed a memcpy that I'm not certain that it can't be overlapping... http://pastebin.org/283057
[11:12:12] <janneg> peloverde: is it ok to mark ffaacenc as experimental?
[11:13:12] <kshishkov> of course
[11:13:22] <janneg> DonDiego: adding CODEC_CAP_EXPERIMENTAL
[11:13:26] <kshishkov> Alex will unmark it when cosiders it's ready
[11:13:30] <kshishkov> *considers
[11:16:38] <nietsu> I have experienced some crashes when decoding certain h264 streams. mb_height seems to change after alloc_tables and cause overflows.
[11:17:02] <DonDiego> svn HEAD?
[11:17:09] <DonDiego> then we need samples to reproduce
[11:17:58] <nietsu> I have created a small patch which at least seems to fix it: http://dl.ksenos.fi/tmp/h264_crash_fix.diff
[11:18:39] <nietsu> The same crash occurred on svn and 0.5.2
[11:19:17] <DonDiego> then please submit the patch on ffmpeg-devel or on the issue tracker
[11:19:32] <merbzt> nietsu: != -> >= maybe
[11:20:09] <nietsu> merbzt: Hmm, might make sense
[11:20:28] <merbzt> I'm not sure as I don't know the rest of the code
[11:21:09] <merbzt> nietsu: anyway, provide sample and attach patch so someone can confirm the issue
[11:22:29] <nietsu> Getting a sample might be a bit tricky, but I'll see what I can do
[11:23:13] <wbs> merbzt: also, > instead of >= I guess, otherwise you'd reallocate stuff all the time?
[11:25:53] <merbzt> true
[11:28:43] <pross-au> https://review.source.android.com/#patch,sidebyside,14699,1,libc/memset.c
[11:29:13] <merbzt> why did they remove that optimization ?
[11:37:02] <_av500_> pross-au: yeah!
[11:37:55] <pross-au> that made me laugh
[11:38:15] <_av500_> the old code compiled much better
[11:38:25] <janneg> at least arm has an asm memset
[11:41:30] <bilboed-pi> pross-au, that'll teach them for NIH'ing like mad
[11:41:39] <Tjoppen> hehe
[11:42:00] <_av500_> lol: google has founded theora for dsps, where is it then?
[11:42:10] <Evgeny> hi. in my subdir.mak file i have  error "commands commence before first target.  Stop.". How to solve it?
[11:42:25] <_av500_> that half finished things that is noteven realtime forsub sd content?
[11:42:38] * _av500_ buys more spaces
[11:45:04] <_av500_> grah, that lwn article is just crap
[11:45:28] <janneg> "            " sells them for $1 a dozen
[11:45:47] * _av500_ buyssomefromjanneg
[11:49:03] <kshishkov> _av500_: funding != immediate result
[11:55:00] <superdump> _av500_: did you mean theora or vp8?
[11:57:06] <DonDiego> _av500_: i already commented on that article, you should, too..
[12:00:23] <pross-au> theora de-motivates me
[12:00:58] <_av500_> it mentions the gg effort to port theora
[12:01:25] <_av500_> now, gg being able to spend 125mio on on2, they could have spent 50k on a theora dsp port
[12:03:35] <_av500_> DonDiego: i am on 2g for this week, all things web take ages
[12:04:10] <pross-au> _av500_: http://webcache.googleusercontent.com/search?q=cache:http://lwn.net/SubscriberLink/389029/33b71acac7c6ffd8/&hl=en&strip=1
[12:04:51] <_av500_> pross-au: yes, i read it
[12:05:08] <_av500_> now need to motivate myself to create lwn login
[12:05:23] <_av500_> maybe if gg sponsors me
[12:08:23] <_av500_> ok, i cannot comment, i am not a subscriber...
[12:10:23] <KotH> hmm?
[12:10:50] <KotH> you should be able to comment w/o being a subscriber
[12:13:50] * KotH wonders how many subscribers lwn has these days
[12:14:27] <_av500_> it wont let me
[12:17:28] <KotH> then subscribe :)
[12:17:34] <KotH> lwn is cheap, and it's worth it
[12:18:11] <mru> really?
[12:18:23] <mru> I can read xiph rants for free elsewhere
[12:19:03] <KotH> yeah, the xpih rants are nasty, but otherwise it gives a quite good overview of what is going on in the linux scene
[12:19:27] <mru> oh, I don't do "scene"
[12:19:44] <mru> and I don't care about gnome and kde etc
[12:20:19] <mru> and linux-kernel has anything kernel-related
[12:27:40] <nfl> merbzt: ping
[12:29:33] <merbzt> pong
[12:30:18] <nfl> you have mail
[12:33:18] <DonDiego> siretart: what is the status of ffmpeg in debian now?
[12:33:28] <DonDiego> that reminds me of a certain wiki page :)
[12:34:11] <siretart> DonDiego: squeeze currently has 0.5.1, need to prepare an 0.5.2 upload
[12:34:38] <siretart> DonDiego: experimental currently ships an 0.6 prerelease package (and has already cleared NEW)
[12:34:46] <DonDiego> ok
[12:34:54] <DonDiego> with full source but some encoders disabled?
[12:35:10] <siretart> yes, as usual
[12:35:32] <DonDiego> ok
[12:35:55] <siretart> DonDiego: I've also uploaded that prerelease package to ubuntu maverick, but it currently doesn't build for transient issues (libdirectfb-dev is currently uninstallable)
[12:38:01] <mru> how does libdirectfb affect ffmpeg?
[12:39:16] <siretart> it declares a build dependency on directfb
[12:39:22] <mru> wtf?
[12:39:28] <mru> we don't use directfb
[12:39:34] <siretart> indirectly.
[12:39:37] <mru> how?
[12:39:38] <mru> sdl?
[12:39:44] <siretart> we depend on sdl, which itself depends on directfb
[12:40:12] <mru> I've never understood the purpose of directfb
[12:40:20] <mru> there seems to be nothing direct about it
[12:41:37] <siretart> the issue is transient after all. maverick has just opened and a lot of packages are being thrown in the archive. most of that will clear up itself the next few days/weeks
[12:42:14] <hyc> just out of curiosity - are you using --enable-librtmp ?
[12:43:56] <siretart> no, not yet. Is there already an librtmp-dev package yet?
[12:44:30] <siretart> no, there isn't. so I'd need to package librtmp first
[12:44:40] <hyc> I don't know. rtmpdump itself was only recently accepted in debian
[13:26:21] <CIA-93> ffmpeg: maxim * r23335 /trunk/libavcodec/ (indeo5data.h indeo5.c ivi_common.h ivi_common.c):
[13:26:22] <CIA-93> ffmpeg: moves indeo5 scan patterns into ivi_common.c
[13:26:22] <CIA-93> ffmpeg: so those can be shared by indeo4.
[13:29:03] <jai> that might tick off the commit log police
[13:29:48] <lu_zero> ?
[13:30:01] <DonDiego> third person singular
[13:33:16] <mru> unusual grammar, but at least it's clear about what the change is
[14:14:36] <BBB> roundup is so slooooooooow
[14:17:16] <kierank> doesn't work at all for me
[14:18:09] <BBB> same here :(
[14:18:13] <BBB> lu_zero: ping?
[14:26:43] <lu_zero> BBB: pong
[14:27:35] <lu_zero> the server that had it on had its contract expired since the payment notice was eaten by spamassassin...
[14:27:50] <KotH> ouch
[14:27:57] <lu_zero> I'll reinstate it soonish
[14:27:59] <kshishkov> well, teach it that  bills != spam
[14:28:38] <BBB> haha :)
[14:28:47] <lu_zero> kshishkov: apparently the sender had his clock/calendar set wrongly
[14:28:56] <lu_zero> and spamassasin disliked it a lot
[14:29:22] <KotH> lu_zero: if you want, we could move roundup somewhere else
[14:29:41] * KotH has a bunch of servers idly sitting around waiting for some work to do
[14:30:01] <lu_zero> I was thinking about moving it to the topix
[14:30:18] * kshishkov concludes that all those servers were unfit for rendering Big Buck Bunny
[14:30:24] * lu_zero has servers in 2 other different locations
[14:30:34] <lu_zero> topix renders bbb AND sintel
[14:30:37] <KotH> http://www.topix.ch/ ?
[14:30:59] <lu_zero> http://www.top-ix.it/
[14:31:13] <KotH> kshishkov: unfortunately, yes
[14:31:32] <lu_zero> s/renders/mirrors
[14:31:38] <KotH> kshishkov: these servers are usually in the 1-2GB ram ball park
[14:32:36] <KotH> http://www.top-ix.it/traffic-summary
[14:32:45] * KotH concludes, italians dont get up before noon
[14:33:18] <kshishkov> why should they?
[14:33:31] <twnqx> you still need to finish BBB for linuxtag?
[14:33:44] <lu_zero> what are you doing with bbb?
[14:34:06] <BBB> he's crunching me
[14:34:30] <lu_zero> mru: btw there are updates regarding linuxtag?
[14:35:04] <janneg> twnqx: almost complete, there are a couple of frames which need more than 8G
[14:35:18] <twnqx> get me a list...
[14:35:19] <janneg> http://www.jannau.net/bbb_videowall/
[14:36:13] <lu_zero> just one remaining?
[14:37:09] <janneg> I think 200-250 frames remaining
[14:37:19] <lu_zero> job I mean
[14:37:29] <janneg> yes
[14:37:48] <janneg> but I can split it
[14:37:56] <janneg> it needs more than 6G
[14:38:55] <lu_zero> I have an 8g box somewhere
[14:39:15] <lu_zero> but you should ping me this night about this ^^;
[14:39:45] <janneg> twnqx: I'll prepare a list
[14:41:08] <kierank> hyc: have you seen this: http://lists.infradead.org/pipermail/get_iplayer/2010-May/000016.html
[14:41:21] <kierank> get_iplayer is also looking for an rtmp expert
[14:44:06] <BBB> lu_zero: can you point us to an alternate address for roundup?
[14:44:08] <BBB> I'm stuck :)
[14:44:54] <lu_zero> BBB: let me have the server reinstated and everything will be fine...
[14:45:03] <BBB> ok
[14:45:04] <BBB> I think
[14:50:22] <lu_zero> KotH: roundup is python btw
[14:50:46] <lu_zero> are you sure you want to start learning about virtualenv AND roundup now?
[15:00:15] <Tjoppen> how nice.. just worked out that drop frame time codes have a time base about 1 ppm lower (faster) than "normal" ntsc. this of course means collisions once every million frames (~10h) even if one is very careful
[15:34:36] <Compn> anyone still working on sun/sparc stuff? someone is selling them and i dunno if these are useful to fate or whatever
[15:34:37] <Compn> LX - $5
[15:34:37] <Compn> Sparc5 and 10 - $10
[15:34:37] <Compn> Sparc1000 - $15
[15:34:37] <Compn> Ultra2 - $20
[15:35:11] <kshishkov> buy one and ship to mru
[15:35:22] <hyc> $20, woohoo
[15:35:53] <mru> sparc is rather uninteresting
[15:36:08] <lu_zero> why?
[15:36:14] <mru> for ffmpeg
[15:36:20] <kshishkov> mlib?
[15:36:24] <mru> it's an interesting cpu in many other ways
[15:36:27] <mru> but it's dead
[15:36:31] <Compn> well thats why i said for whatever , doesnt have to be ffmpeg :P
[15:36:35] <kshishkov> and opensourced :P
[15:36:49] <lu_zero> sparc is gpl somehow
[15:36:51] <Compn> i know you guys have special/rare hardware
[15:37:22] <kshishkov> not me
[15:38:13] <Compn> thought you had a geode? or loonghen
[15:38:22] <KotH> lu_zero: i want to learn it somewhen, i'm not sure i want to learn it now :)
[15:38:29] * Compn cant remember names of these cpus anymore
[15:38:37] <kshishkov> Compn: shortchicken-based netbook
[15:38:43] <Compn> lol
[15:38:56] <lu_zero> KotH: eh eh
[15:40:02] <KotH> Compn: if you can get your hands on a ultra2, that'd be cool
[15:40:11] <KotH> Compn: the others are.. unintersting
[15:40:35] <KotH> Compn: ok, maybe the sparc1000 as it's a bigger machine, but the others are just small pizza boxes
[15:40:54] <KotH> lu_zero: there is an gpl'ed vhdl code of an sparc cpu implentation, called leon
[15:42:33] <lu_zero> http://en.wikipedia.org/wiki/LEON
[15:43:52] <lu_zero> http://en.wikipedia.org/wiki/UltraSPARC_T3 <- that seems interesting
[15:44:36] <Compn> sparcserver 1000 - The fastest cpu modules were 85MHz:
[15:44:37] <Compn> heh
[15:45:03] <hyc> T3? will it ever see the light of day?
[15:45:07] <KotH> Compn: i used to own a sparcstation 5 back in 2000
[15:45:18] <kshishkov> hyc: that's why it's interesting
[15:45:31] <KotH> Compn: by that time it was already a few years old and the company i got them from were throwing them away after they were sitting in the cellar for years
[15:45:33] <hyc> I still have a sparcstation sitting in the office. unplugged now tho ;)
[15:45:38] <jai> btw, maybe we can delete http://samples.mplayerhq.hu/sub/DivX%2bSubtitles.divx ?
[15:45:46] <KotH> Compn: i think my brother has still one of those
[15:46:11] <Compn> heh, i dont think i want one...
[15:46:11] <jai> the subs don't work with the divx player too, so its just misleading to carry it around
[15:46:33] <Compn> jai : which version divx player? i'm assuming it worked at one time and divx player just outdated it
[15:46:43] <ramiro> all this computing power... only so that we may watch pictures of cats with captions...
[15:46:51] <KotH> Compn: the ss5 had iirc a 5MHz sparc-II cpu, which felt like a 100 MHz pentium in work speed
[15:46:59] <KotH> 50MHz, not 5 ^^'
[15:47:01] <Compn> like how realplayer doesnt play every realmedia file, or official ogg demuxer cant handle all files...
[15:47:17] <KotH> ramiro: can i haz cheezburger?
[15:47:17] <jai> Compn: v8
[15:47:20] <kshishkov> luckily, it's not the case with FFmpeg
[15:47:34] <Compn> jai : you might want to try a version of divx player that is closer to the date on that file
[15:47:48] <Compn> luckily :)
[15:48:28] <Compn> ffmpeg is quickly becoming the only software which can play these old crappy files no one cares about anymore
[15:48:39] <jai> except this one ;)
[15:48:51] <jai> i havent found _any_ player which handles this
[15:48:56] <Compn> i thought reimar got those subs working in mplayer ...
[15:48:57] * jai goes to look on filehippo
[15:49:10] <jai> xsub works in mplayer/vlc/ffplay
[15:49:13] <jai> not this file though
[15:49:17] <Compn> ah
[15:50:00] <Compn> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=634
[15:50:04] <Compn> theres the bug for that file
[15:50:24] <Compn> could be invalid, could be antique version of xsub file ? hehe
[15:54:40] <jai> Compn: well yeah the xsub decoder works pretty well
[15:55:00] <jai> my problem with that specific sample is that it doesnt seem to have any xsub packets :(
[15:55:29] <Compn> ah heh
[15:55:43] <Compn> i thought i ran strings on it and found subs but its been 4 years so i dotn remember now
[15:56:09] <Compn> but yeah, i can delete it if no one wants it around
[15:56:51] <hyc> hmm. seems like neither rtsp nor rtmp has provision for a subtitle track in the stream.
[15:56:56] <hyc> anyone know for sure?
[15:57:12] <_av500_> burned in subs :)
[15:57:15] <kshishkov> Compn: why delete a sample?
[15:57:49] <BBB> Yuvi: vp8data.h doesn't compile, TM_VP8_PRED is missing
[15:58:10] <_av500_> kshishkov: make a backup 1st of course...
[15:58:20] <jai> Compn: strings wont yield anything, the subs are rle coded rects
[15:59:41] <jai> kshishkov: well, we can atleast rename it and move it to the divx dir
[16:02:30] <wbs> hyc: don't think there's anything stopping it from being implemented in rtsp/rtp, but I don't know any specs on it offhand
[16:02:40] <wbs> hyc: there's shitloads of different rfcs on  how to pack different formats in rtp
[16:03:12] <wbs> hyc: rtsp itself doesn't mind what's being wrapped, rtsp just sets up the connection... anything you can fit into rtp/sdp then should be fine
[16:05:33] <Compn> hyc : i remember a few articles about ripping rtmp hosted subs from cruncyroll
[16:06:19] <hyc> right, I just think no one has written a spec for it
[16:06:32] <Compn> hyc : for rtsp subs here is a sample >> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=296
[16:06:36] <Compn> oh specs, no idea :P
[16:06:42] <hyc> Compn: re: crunchyroll - the point was that subs weren't part of the rtmp stream, so they were hosted separately
[16:07:07] <Compn> everybody just puts their stuff in X-perimental and ignores specs anyhow
[16:07:13] <hyc> likewise with hulu, they provide closed captions in a separate SMIL file
[16:11:17] <lu_zero> let me see
[16:11:24] <hyc> I should write a subtitle spec for RTMP. see how Adobe responds. "Damn, some freetard is extending our proprietary spec!!"
[16:13:04] <lu_zero> ugh...
[16:13:35] <BBB> Compn: that rtsp link works fine in ffmpeg
[16:13:46] <BBB> Compn: or was the bug in the mov file?
[16:13:49] <BBB> (then I don't know)
[16:13:57] <lu_zero> 17:55 <+hyc> hmm. seems like neither rtsp nor rtmp has provision for a subtitle  track in the stream.
[16:14:10] <lu_zero> rtp has at least two ways to provide subtitles
[16:14:15] <lu_zero> one is using rtp-text
[16:14:23] <lu_zero> the other is using/abusing rtcp-xr
[16:14:31] <mru> the proper freetard way is to create a new spec, loosely based on (but deny this) the proprietary one, mostly by removing any nice features it might have, then adding the missing feature in a way that makes almost impossible to use
[16:14:53] <lu_zero> mru: you are describing...
[16:14:56] <lu_zero> hmm
[16:15:03] <lu_zero> ogg feels completely original
[16:15:59] <mru> yes, ogg is 100% original crap
[16:16:02] <lu_zero> hyc: josh wants to have subtitles working in rtsp so something will be done about it
[16:16:15] <hyc> lu_zero: cool, thx for info
[16:16:32] <Compn> BBB : which rtsp link? the first playlist one that pulls in video and subs ?
[16:16:41] <BBB> in that mplayer bug report
[16:16:46] <BBB> rtsp://vstream.acm.org/10.1145/siggraph2004/courses4/crs022-1.mp4
[16:17:32] <Compn> BBB : does it work if you call it from the http mov playlist? http://www.siggraph.org/soma/SIG04/Media/disc4/crs022-1.mov
[16:17:40] <Compn> i guess i could check :)
[16:17:55] <ohsix> mru: any proof on what its loosely based on?
[16:18:33] <BBB> no
[16:18:38] <BBB> it has 23 chapters of metadata though
[16:18:42] <BBB> each seems a subtitle :)
[16:18:50] <Compn> hehe
[16:20:02] <mru> ohsix: I wasn't talking about anything specific
[16:20:28] <ohsix> ok; the "they deny this" part seemed to point at something specific, as in they've done it already :]
[16:23:15] <janneg> mru: have you ordered sponsored linuxtag social event tickets? "deadline" is Sunday, May 30th
[16:23:55] <mru> wtf? where did you read that?
[16:24:08] <janneg> http://wiki.linuxtag.org/w/fp:Social_Event
[16:24:27] <mru> linuxtag organisation gets worse every year
[16:24:52] <janneg> but that was afaik always the case, just nobody cared
[16:25:34] <mru> they used to send out emails about such things
[16:25:38] <mru> not make you hunt obscure wikis
[16:26:06] <janneg> the location is nicer this year if we have good weather
[16:26:21] <mru> and as usual I have no fucking clue how many people will be turning up
[16:26:36] <ohsix> roll 2d6
[16:26:52] <ohsix> if one die is under 4 multiply it with the other
[16:27:26] <janneg> 1*1
[16:27:46] <ohsix> o noes
[16:30:19] <janneg> mru: you, av500, kshishkov, DonDiego, Stefan, mchinen, me
[16:30:37] <janneg> maybe lu_zero
[16:30:49] <mru> cehoyos
[16:31:45] <janneg> he said friday, saturday. so he might not be in berlin thursday evening
[16:31:53] <mru> right
[16:32:45] <janneg> Thilo Borgmann?
[16:33:18] <mru> I don't remember him saying anything about coming
[16:33:51] <janneg> yes, but he seems to have access to the free passes
[16:34:05] <mru> then he must be registered with another project
[17:01:09] <lu_zero> I'm next to surely in =)
[17:02:19] <lu_zero> and hopefully I'll be able to help setting up =P
[17:02:42] <lu_zero> and that reminds me
[17:03:05] <mru> great
[17:03:16] <lu_zero> which hotel you'll stay?
[17:03:29] <mru> need to book that
[17:03:33] <mru> probably the ibis
[17:04:01] <lu_zero> I see
[17:09:04] <lu_zero> the ibis seems full
[17:09:37] <mru> crap
[17:10:16] <lu_zero> Ibis Berlin Messe is it?
[17:10:29] <mru> yes, good location
[17:10:31] <mru> for linuxtag
[17:11:18] <lu_zero> too good apparently =P
[17:11:47] <mru> not full, but insanely expensive
[17:12:15] <mru> as usual the first price they show is only half of what it ends up at
[17:15:33] <lu_zero> mru: for me it was claimed full
[17:15:43] <mru> where did you look?
[17:16:07] <lu_zero> between 8 and 13
[17:16:13] <mru> yes, but what website?
[17:16:27] <lu_zero> ibishotel.com
[17:19:05] <mru> stupid hotels
[17:19:11] <mru> arrival on 7th has rooms
[17:19:13] <mru> but not 8th
[17:19:21] <mru> how the fuck does that make sense?
[17:19:35] <mru> but I'm not paying 112 euros per night for that hotel
[17:22:02] <kierank> give them a ring
[17:22:32] <lu_zero> 112 it's a bit for it
[17:22:32] <kierank> a lot of the time the price is totally different
[17:22:32] <kshishkov> mru: train in Denmark first, looks like their hotels are with the highest prices
[17:22:39] <spaam> kierank: one ring to rule them all?
[17:23:04] <kshishkov> spaam: one phone ring definitely rules in ex-USSR
[17:23:15] <kshishkov> in direct sense
[17:23:44] * kierank picks up the phone and asks for spaam to be whacked
[17:24:00] <spaam> kierank: <3
[17:24:12] <kierank> say hi to the horse in your bed
[17:24:30] <CIA-93> ffmpeg: michael * r23336 /trunk/libavcodec/h263dec.c: Treat SIPP like xvid, fixed issue1966
[17:24:37] <jai> whoa godfather reference
[17:24:44] <spaam> kshishkov: ok :D
[17:24:56] <spaam> jai: teh best :)
[17:25:30] <spaam> three weeks ago me and some friends watched god father one to three ;D
[17:25:35] <spaam> it was nice :)
[17:25:49] <jai> :)
[17:26:58] <mru> same rate on the phone
[17:27:06] <kshishkov> spaam: and in Ukraine we had a term "phone law"
[17:27:35] * kshishkov had once to spent a night in three-star hotel in Copenhagen for 700 DKK
[17:27:38] <spaam> kshishkov: what about that law? :D
[17:27:42] <lu_zero> uff maporama sucks
[17:28:15] <kshishkov> spaam: if somebody from top calls you by phone, his words have higher priority than any other rules or law
[17:28:55] <spaam> kshishkov: ok :)
[17:36:21] <Dark_Shikari> so yeah mru, after seeing my post and the 15-line C functions that now _actually_ exists, what do you think of deblock strength on neon? ;)
[17:36:28] <Dark_Shikari> s/functions/function
[17:36:58] <spaam> kshishkov: does that law exists today? :)
[17:37:55] <lu_zero> mru: what about http://www.hotel-funkturm-messe.de/preise.html ?
[17:38:03] <mru> looking at it now
[17:39:02] <Dark_Shikari> deblock_strength_c is the relevant bit.
[17:39:06] <lu_zero> the english prices look quite different
[17:41:59] <mru> different in all languages
[17:46:27] <Tjoppen> interesting - drop frame time codes work out to exactly be 29.97 fps, not 30000/1001
[17:47:02] <Tjoppen> 107892 frames to the hour, not 108000. good to know
[17:52:55] <Compn> Tjoppen : you should write down your findings somewhere for others
[17:53:34] <Compn> gah roundup is down
[17:54:47] <Tjoppen> I'm thinking of writing down my quicktime findings on the wiki. particularly regarding the 'avis' tag in the 'dref' tag
[17:54:55] <Tjoppen> have to nag mike a bit I guess
[17:56:42] <kierank> the wiki needs a section called "things that should be long dead". I would add ntsc framerates, interlacing and drop frame to it
[17:56:55] <kierank> ac-3 and mpeg-2 as well
[17:56:59] <_av500_> avi?
[17:57:03] <kierank> yes
[17:57:03] <_av500_> :(
[17:57:06] <mru> ac3 and mpeg2 are fine
[17:57:13] <_av500_> err :)
[17:57:17] <mru> avi _is_ dead
[17:57:22] <_av500_> no
[17:57:23] <peloverde> avi is not dead
[17:57:33] <peloverde> check demonoid if you disagree
[17:57:40] <mru> the only avi files on my computer are the ones in the samples archive
[17:57:52] <_av500_> fine for you
[17:58:12] <_av500_> the hdds and ssds of our users are full of avi
[17:58:15] <peloverde> The bulk of US TV on demonoid is Xvid in AVI
[17:58:38] <ohsix> i have terabytes :]
[17:59:22] <kierank> there are a lot of places that mandate xvid in avi
[17:59:40] <Tjoppen> I'd call the article "Headaches" or something like that
[17:59:53] <kierank> mainly because people want their old divx dvd players to keep working
[18:00:40] <kierank> just like ac-3 survives because people want their old amps to still work
[18:01:28] <mru> and because the dvd spec isn't changing
[18:01:33] <mru> and they're still selling dvds
[18:01:49] <mru> besides, what's the problem with ac3?
[18:01:58] <_av500_> it works
[18:02:19] <mru> I don't see anything particularly annoying about it
[18:02:29] <_av500_> me neither
[18:02:34] <mru> nor mpeg2
[18:02:35] <kierank> it's being used in new applications when there's something better
[18:02:37] <_av500_> except the dolby cert...
[18:02:53] <mru> kierank: what would you use instead?
[18:02:55] <kierank> aac
[18:03:07] <mru> aac is much more annoying
[18:03:31] <mru> the good thing about aac is that there are so many of it to choose from
[18:03:35] <_av500_> well, it is way waychaeper
[18:03:43] <kierank> aac lc
[18:03:54] <_av500_> ac3 is awfully expensive
[18:04:22] <mru> licensing aside, ac3 works well for the intended application
[18:04:29] <_av500_> i agree
[18:04:44] <mru> decent quality and reasonably cheap to decode
[18:04:58] <_av500_> and even self syncing
[18:09:01] <Tjoppen> hm. at 10;00;00;00, which is where smpte recommends you start counting, the difference between those two time bases is one frame
[18:10:56] <peloverde> It seems like AAC-LC should be transparent at ac-3 optical disc bitrates
[18:14:06] <Tjoppen> I bet SMPTE 12M has something to say about this. it even deals with leap seconds, recommending you re-count that second rather than count up to 60
[18:14:17] <Tjoppen> instead of 59. hooray
[18:35:42] <CIA-93> ffmpeg: cehoyos * r23337 /trunk/ (libavcodec/avcodec.h Changelog): Bump minor version and add Changelog entry after r23334.
[18:46:03] <CIA-93> ffmpeg: stefano * r23338 /trunk/ (libavcodec/avcodec.h doc/APIchanges):
[18:46:04] <CIA-93> ffmpeg: Bump minor version bump and add an APIchanges entry after addition of
[18:46:04] <CIA-93> ffmpeg: CODEC_CAP_EXPERIMENTAL.
[18:46:20] <ramiro> has the minor version just been bumped twice for the same thing?
[18:47:24] <peloverde> Such things have been known to happen from time to time
[18:47:34] <mru> it does no harm
[18:55:47] <CIA-93> ffmpeg: cehoyos * r23339 /trunk/libavcodec/vorbis_enc.c: Mark vorbis encoder as experimental.
[19:01:50] <CIA-93> ffmpeg: cehoyos * r23340 /trunk/libavcodec/ (h264.c h264.h):
[19:01:50] <CIA-93> ffmpeg: Factorize ff_h264_decode_extradata().
[19:01:50] <CIA-93> ffmpeg: Patch by Howard Chu, hyc highlandsun com
[19:04:21] <Kovensky> < kierank> the wiki needs a section called "things that should be long dead". I would add ntsc framerates, interlacing and drop frame to it <-- telecine, srt, deen, tsukihime anime
[19:04:30] <Kovensky> rmvb
[19:04:31] <Kovensky> ._.
[19:12:47] <mru> lu_zero: that hotel with the strange rates... they have yet another rate when you use the form on the webpage
[19:12:51] <mru> 90 euro per night
[19:12:53] <mru> idiots
[19:15:49] <_av500_> hrs.de
[19:16:17] <spaam> mru: germans....
[19:16:41] <mru> germans have the most complex rules and rituals around hotels I've ever seen
[19:17:33] <kierank> especially involving sun loungers and towels
[19:20:19] <twnqx> :>
[19:20:44] <twnqx> you should witness buffets.
[19:21:20] <mru> the best hotel breakfasts I've had were in america
[19:21:29] <mru> they know how to make breakfast there...
[19:21:58] <_av500_> +1
[19:22:06] <twnqx> hm
[19:22:08] <peloverde> Really, generally I'm not a fan of American hotel breakfast
[19:22:10] <mru> the german breakfast buffets usually look impressive at a distance
[19:22:21] <mru> when you get closer, you see there's really nothing to it at all
[19:22:38] <twnqx> never been to america
[19:22:44] <dgt84_> I'm always surprised how much people outside the US love US breakfast
[19:22:49] <mru> peloverde: try more expensive hotels
[19:22:54] <mru> hilton is usually nice
[19:23:28] <twnqx> also i don't really benefit from huge breakfasts... since i just eat two slices of bread
[19:23:36] <twnqx> sometimes egg, sometimes fruit...
[19:24:36] <dgt84_> marriott and ritz are also nice but really at that point you can get a cheapo room and go out to Denny's / IHOP / etc (depending on where in the US) in the morning for a decent meal
[19:24:43] <twnqx> anyway, i agree that most german breakfast selections can't compete with some things i've seen in the middle east (where the majority of hotels i've been in is located)
[19:25:04] <dgt84_> twnqx, what sort of breakfast stuff do you get there?
[19:25:18] <mru> don't expect any bacon :-(
[19:25:28] <twnqx> mru: depends, in dubai you have bacon everywhere
[19:25:34] <twnqx> hyatt in cairo as well
[19:25:58] <twnqx> also, i've learnt how nice veal bacon is
[19:26:06] <twnqx> which you get all over saudi arabia :P
[19:26:16] * dgt84_ mostly eats turkey bacon
[19:26:28] <mru> real bacon is made from pigs
[19:26:34] <twnqx> dgt84_: basically american breakfast, just replace pork with veal/turkey etc, pluz arab mezzah
[19:26:51] <twnqx> plus "continental" breakfast
[19:27:04] <mru> but sure, there's lots of good food from the middle east
[19:27:05] <twnqx> usually with omelett/eggs made to order
[19:27:06] <dgt84_> twnqx, ah okay, cool
[19:36:33] <ramiro> what's the link to ffmpeg.org's awstats?
[19:36:34] <FFFF-RAGE> Does anyone else experience corrupted sound when encoding 5.1 audio with: ffmpeg -i temp.ac3 -acodec libvorbis -aq 5 -y temp.ogg
[19:37:04] <lu_zero> 21:25 <@mru> real bacon is made from pigs
[19:37:08] <lu_zero> uhmm
[19:37:48] <kierank> military breakfast > all
[19:37:50] <lu_zero> that reminds me that I want to try ostrich
[19:40:43] <FFFF-RAGE> ostrich is good
[19:41:31] <thresh> i never could eat at the morning
[19:42:01] <_av500_> redefine morning
[19:42:08] <thresh> when I wake up
[19:42:31] <mru> so redefine it
[19:42:41] <mru> define morning as when you get hungry
[19:49:31] <wbs> FFFF-RAGE: it seems like the libvorbis wrapping only supports 1 or 2 channels, patch welcome I guess
[19:49:51] <FFFF-RAGE> ah
[19:50:08] <FFFF-RAGE> I don't think I'll be submitting one
[19:50:10] <wbs> FFFF-RAGE: check lines 149-156 in lavc/libvorbis.c
[19:50:37] <wbs> I don't think it's complicated to fix that
[19:50:44] <FFFF-RAGE> that may be so
[19:50:58] <FFFF-RAGE> but nobody applies my patches
[19:52:10] <twnqx> thanks for ffwmv3, plays the stream from BP's oil valve, even though it's a bit boring
[19:52:30] <ramiro> FFFF-RAGE: ffmpeg-cvslog says otherwise
[19:52:35] <_av500_> it plays the oil directly?
[19:52:42] <twnqx> sadly not
[19:52:42] <FFFF-RAGE> colours on windows?
[19:52:53] <FFFF-RAGE> vorbis comments in ogg vorbis files?
[19:53:30] <ramiro> FFFF-RAGE: wasn't colours on windows rejected until a cleaner solution is found?
[19:53:44] <mru> if you're talking about that patch that either doesn't work, doesn't do anything, or breaks stuff, there's a good reason it's rejected
[19:53:51] <FFFF-RAGE> What's wrong with someone else re-writing it later?
[19:54:05] <FFFF-RAGE> And it works just fine in cmd
[19:54:24] <FFFF-RAGE> and wil probably only ever work in cmd
[20:00:56] <bamiaux> does anyone know which codec (m2v?) stress ffmpeg bitstream readers enough so that their speed is critical ?
[20:01:19] <Dark_Shikari> huffyuv?
[20:01:54] <peloverde> AAC at high bitrates
[20:02:30] <bamiaux> huffyuv looks more bandwith constrained
[20:02:37] <bamiaux> i'll check both anyway
[20:03:46] <peloverde> AAC does have bitstream primitives inlined these days, so that changes some results
[20:03:55] <BBB> yuvi: ping (once you're awake)
[20:04:54] <bamiaux> aren't they supposed to be always inlined though ?
[20:06:50] <peloverde> By primitives I mean directly using OPEN_READER/UPDATE_CACHE/GET_VLC/SHOW_UBITS/etc rather than get_vlc2, get_bits
[20:06:56] <pengvado> huffyuv spends about 70% of its time in the bitstream reader
[20:07:01] <pengvado> 90% if you turn off median
[20:07:38] <FFFF-RAGE> That was simple but now I have mis-matched channels
[20:08:16] <kierank> [20:52] <+twnqx> thanks for ffwmv3, plays the stream from BP's oil valve, even though it's a bit boring --> that live stream is a PR diversion imo
[20:08:32] <twnqx> sure is, nothing happens
[20:08:48] <ohsix> that live stream was hard fought for, they coveted any video at all for nearly a month
[20:09:09] <ohsix> becuase even if it is a distraction people can make their own estimates and see that they were lowballing them
[20:09:42] <twnqx> there's nothing to see
[20:09:48] <twnqx> zero, nada, rien
[20:10:13] <ohsix> heh, when they do the topkill there will be something to see, but the point was to get the public to see the flow rate
[20:10:33] <twnqx> have you looked at it? you see no flow...
[20:10:44] <bamiaux> Ok, but I assume huffyuv spend most of its time inside get_vlc*, and not regular get_bits
[20:10:45] <kierank> erm there's a lot of flow
[20:10:53] <twnqx> in the picture?
[20:11:00] <kierank> yes
[20:11:06] <twnqx> mh
[20:11:06] <peloverde> It's ridiculous that these days we expect big business to act in a substantively fraudulent manner (I say substantively because they control the legislative process, so nothing they do is illegally fraudulent)
[20:11:12] <mru> it probably looks small because you don't have a sense of scale
[20:11:13] <ohsix> then we might be talking about different things :] http://globalwarming.house.gov/spillcam
[20:11:28] <FFFF-RAGE> Is there a standard way to remap channels in ffmpeg?
[20:11:29] <kierank> they've moved it around
[20:11:43] <twnqx> mms://a246.l9789246245.c97892.g.lm.akamaistream.net/D/246/97892/v0001/reflector:46245 is what i'm looking at
[20:11:45] <kierank> yes
[20:11:59] <kierank> the camera isn't facing the leak
[20:12:30] <ohsix> bummer, it was the last few days
[20:23:24] <CIA-93> ffmpeg: maxim * r23341 /trunk/libavcodec/ (indeo5.c ivi_common.h ivi_common.c): Add the forgotten ff_ prefix to the shareable scan patterns.
[20:23:48] <peloverde> Is roundup down?
[20:23:54] <BBB> yes
[20:24:27] <peloverde> So much for fixing bugs :)
[20:24:52] <ohsix> snow day \m/
[20:32:10] <hyc> kierank: heh I didn't evn know they had a mailing list. but I'm in regular contact with the get_iplayer author...
[20:35:30] <hyc> BBB: hmm, this would all be pretty easy if I just add an AVCodecContext pointer inside the AVCodecParserContext. wdyt?
[20:35:32] <Dark_Shikari> mru: ping
[20:36:14] <hyc> of course it would render the AVCodecContext on the parse argument list redundant
[20:36:28] <Dark_Shikari> or just general question to here
[20:36:32] <Dark_Shikari> I need a video format that:
[20:36:39] <hyc> does anybody use a single ParserContext with multiple CodecContexts at once?
[20:36:40] <Dark_Shikari> a) compresses fast enough to do realtime 720p
[20:36:47] <Dark_Shikari> b) decodes 2-2.5x faster than h264 without cabac or deblocking
[20:36:49] <Dark_Shikari> c) on ARM
[20:36:50] <BBB> hyc: uh... so why can't you do all initialization (delayed) in _parse(), as Michael suggested?
[20:36:59] <Dark_Shikari> d) compresses _enough_ to work over wireless g
[20:37:31] <peloverde> 802.11 a/b/g/n?
[20:37:33] <hyc> BBB: I can, that's what my last posted patch does. I just think it's stupid to add an "did we do this yet" flag to the H264Context and check it on every call to Parse.
[20:37:57] <BBB> hyc: fair enough
[20:38:02] <Dark_Shikari> Yuvi: ping maybe
[20:38:11] <hyc> when it's obviously an init-type step, and we have an explicit init entry point...
[20:38:19] <kierank> hyc: that's the get_iplayer fork mailing list
[20:38:20] <Dark_Shikari> peloverde: g I think
[20:38:37] <Dark_Shikari> so in other words it can't be totally uncompressed/crap
[20:38:39] <Dark_Shikari> but it can be close
[20:38:42] <BBB> hyc: I think somehow changing api all the time might not be ideal also, though
[20:39:58] <hyc> BBB: true... oh well. it just nags at me, I think this API is wrong but I can see the value in not disturbing it.
[20:40:42] <hyc> Dark_Shikari: DV is 25Mbit/sec. in a noise-free environment, it will work over 802.11g
[20:40:43] <BBB> hyc: I'm not maintainer, so my opinion adds little value to the discussion ;) in this case, if michael prefers X, then you probably don't want to waste your time on proposing Y unless there's a really good reason to waste your time on it
[20:40:44] <BBB> :)
[20:41:01] <hyc> well his last reply was that he was open to it
[20:41:02] <janneg> Dark_Shikari: .g means 20mbps netto
[20:41:34] <BBB> hm...
[20:41:34] <Dark_Shikari> hyc: I don't think it's fast enough
[20:41:41] <Dark_Shikari> too high bitrate
[20:41:51] <BBB> hyc: I think you should add it to init then, or as I said before, add an init2() that has it
[20:42:00] <BBB> then at least the api change is obvious
[20:42:10] <janneg> Dark_Shikari: which ARM?
[20:42:11] <BBB> adding it to parsectx is hackish because it might not be immediately clear to users
[20:42:29] <Dark_Shikari> janneg: Cortex A8
[20:42:36] <Dark_Shikari> must decode 1024x768 in realtime
[20:42:41] <Dark_Shikari> actually, 2x realtime
[20:42:47] <Dark_Shikari> we have to spend ~10-15ms per frame displaying it
[20:42:57] <Dark_Shikari> so we only have about 10-15ms left after overhead and network time to actually decode
[20:44:20] <hyc> Dark_Shikari: bummer, it's close. I've streamed DV over my home wireless-G, but any change in the weather and it glitches
[20:44:35] <Dark_Shikari> we have full control, the wireless can be right next to it if we want
[20:44:39] <FFFF-RAGE> Can I make libvorbis.c depend on vorbis_data.c?
[20:44:53] <Dark_Shikari> in short, we need to cheat to put video on an ipad.
[20:45:15] <BBB> get a faster h264 encoder
[20:45:19] <BBB> decoder
[20:45:19] <Dark_Shikari> encoder isn't the problem
[20:45:23] <BBB> (sorry)
[20:45:24] <Dark_Shikari> decoder?  coreavc is too slow
[20:45:27] <Dark_Shikari> by a factor of 1.5-2x
[20:45:32] <BBB> didn't ipad have a hw decoder?
[20:45:32] <Dark_Shikari> With deblocking off
[20:45:33] <Dark_Shikari> cabac off
[20:45:34] <Dark_Shikari> and subpel off
[20:45:43] <Dark_Shikari> ipad has a hw decoder that we can't use.
[20:45:48] <BBB> why not?
[20:45:49] <Dark_Shikari> and if we get access, it will be too late.
[20:45:52] <Dark_Shikari> Ask Steve.
[20:45:56] <BBB> there's an api for it
[20:46:01] <Dark_Shikari> Where?
[20:46:04] <BBB> or was that a generic mac api?
[20:46:09] <Dark_Shikari> Our iphone dev says no.
[20:46:11] <hyc> what clock rate is that A8?
[20:46:12] <wbs> FFFF-RAGE: sure, just add it at the correct spot in the makefile
[20:46:12] <BBB> apple released an api to their hw decoding features a while ago
[20:46:29] <Dark_Shikari> where?
[20:46:29] <BBB> also, the quicktime api on the iphone should give you access to it
[20:46:34] <Dark_Shikari> hyc: 1ghz
[20:46:35] <janneg> Dark_Shikari: have you tried mpeg2?
[20:46:37] <hyc> BBB: that API works for their Nvidia cards
[20:46:38] <BBB> how else does decoding h264 work in any application?
[20:46:41] <ramiro> Dark_Shikari: Steve seems to be listening to you, maybe you should ask him =)
[20:46:42] <Dark_Shikari> BBB: it doesn't
[20:46:45] <Yuvi> BBB: pong
[20:46:49] <BBB> you've gotta be kidding me
[20:46:52] <Dark_Shikari> I'm not
[20:46:53] <kierank> have you checked there's not a way through OpenGL?
[20:47:00] <Dark_Shikari> kierank: opengl can do yuv conversion for us
[20:47:02] <Dark_Shikari> Not decoding
[20:47:03] <wbs> BBB: the hw decoding API was desktop only
[20:47:06] <BBB> Yuvi: ah, hi, is decode_mb() for macroblock intra or inter decoding? I'd like to implement that now
[20:47:11] <BBB> wbs: oh. damnit
[20:47:12] <Dark_Shikari> apple has _repeatedly_ said no
[20:47:18] <Dark_Shikari> to requests from various people to use the hardware decoder
[20:47:20] <Dark_Shikari> with no explanation
[20:47:25] <Yuvi> BBB: oh, both, let me push what I have
[20:47:26] <BBB> Dark_Shikari: email steve
[20:47:26] <wbs> BBB: and all video APIs on iphone are way, way too highlevel for what they're trying to do
[20:47:27] <BBB> he owes you
[20:47:28] <BBB> :)
[20:47:35] <BBB> damnit
[20:47:40] <BBB> I bet you implemented what I just did
[20:47:42] <Yuvi> also, TM_VP8_PRED is in h264pred.h
[20:47:47] <BBB> it isn't
[20:47:49] <Dark_Shikari> Yuvi: you got an arm?
[20:47:51] <hyc> Dark_Shikari: hm, I thought mru had already tweaked the neon h264 code pretty well
[20:47:51] <BBB> check github
[20:47:56] <Dark_Shikari> hyc: yes, it's still too slow
[20:48:01] <Dark_Shikari> I'm saying it will NEVER be fast enough
[20:48:02] <BBB> I grepped for it
[20:48:04] <Dark_Shikari> not in a million years
[20:48:05] <Yuvi> Dark_Shikari: yeah
[20:48:14] <Yuvi> BBB: hm, maybe I forgot to push that too
[20:48:20] <Dark_Shikari> Yuvi: What decoder do you think would be 2.5x faster than ffh264 with no deblock and no cabac
[20:48:23] <Dark_Shikari> on arm
[20:48:24] <Dark_Shikari> And could you bench it?
[20:48:31] <Dark_Shikari> (mjpeg, dv, mpeg2, etc are fine)
[20:48:36] <Dark_Shikari> even svq1...
[20:48:43] <Yuvi> the best I can think of is a h263 derivative
[20:48:51] <hyc> too bad. I also keep thinking OMAP when I see Cortex, and want to suggest DSP but obviously that's not here, oh well
[20:48:55] <Dark_Shikari> Yuvi: flv1?
[20:49:06] <Yuvi> iirc A8 at 5-600 MHz can do mpeg-4 at 720p24
[20:49:15] <Dark_Shikari> I need two things benched
[20:49:29] <Dark_Shikari> 1) mpeg4/flv1 (pick one) at say qscale 4, 1024x768
[20:49:45] <Dark_Shikari> 2) x264 with --preset ultrafast at say qp 25, 1024x768
[20:49:46] <hyc> I have 600MHz A8 w/1024x600 screen
[20:49:54] <Dark_Shikari> I need to know how much faster 1) is compared to 2)
[20:50:08] <Dark_Shikari> if the answer is "at least twice", this may be possible.
[20:50:25] <janneg> Yuvi: barely, without sound and buffering lot of frames.
[20:50:27] <Dark_Shikari> (I can do it myself, of course, if I had ssh)
[20:50:45] <hyc> those are encoder benches, I thought you were worried about the decoder
[20:50:47] <Dark_Shikari> decoder.
[20:50:55] <Dark_Shikari> Yes, I mean decoding the output of those encodes
[20:50:59] <hyc> ok
[20:51:49] <hyc> I may be ble to get to it in a little bit if no one else jumps up
[20:51:52] <Dark_Shikari> k
[20:52:09] <kierank> have you tried erm theora
[20:52:22] <kierank> arm*
[20:52:34] <hyc> 1024x768? can you cheat the rez and upscale on playback?
[20:53:10] <hyc> that's what I do for hulu on my touchbook, play the 512x288 stream and scale to 1024x576
[20:53:38] <Dark_Shikari> kierank: theora is slower than mpeg4 I'd assume
[20:53:46] <Dark_Shikari> hyc: Yeah we can do that, it sucks
[20:54:08] <hyc> I doubt most users will know the difference
[20:54:16] <Dark_Shikari> It's kinda obvious when playing a game.
[20:54:25] <hyc> mmm
[20:54:32] <lu_zero> Dark_Shikari: you'd like having ssh on an efikamx and/or a beagleboard?
[20:54:38] <hyc> a game with live video background huh
[20:54:40] <Dark_Shikari> lu_zero: that would be cool
[20:54:48] <Dark_Shikari> hyc: no, the game is the video background ;)
[20:54:52] <lu_zero> ping me insistently in the next days
[20:55:01] <Yuvi> BBB: pushed
[20:55:13] <BBB> Yuvi: was my patch quarter-way useful?
[20:55:14] <lu_zero> so I prepare an image for the beagleboard and boot both of them
[20:55:25] <BBB> oh, see there, my patch is in there :)
[20:55:40] <wbs> BBB: getting used to git? :-)
[20:55:49] <BBB> no
[20:55:55] <BBB> I send yuvi patches by mail and he applies
[20:55:58] <BBB> I'm confused by git
[20:56:02] <wbs> ah ;P
[20:56:07] <lu_zero> BBB: bad =E
[20:56:30] <BBB> I know
[20:56:34] <BBB> I'm cloning his repo now
[20:56:37] <BBB> let's see if this works
[20:57:09] <Yuvi> BBB: oh, I misread the patch, it should be rac_get_nn not _sint2
[20:57:34] <BBB> wait what?
[20:57:46] <Yuvi> I made a wrong change
[20:57:55] <BBB> get_uint() was wrong?
[20:58:08] <Yuvi> no, it was right
[20:58:20] <Yuvi> I just thought it was another instance of sint2 that the spec didn't name
[20:58:30] <Yuvi> but it's an instance of _nn like in vp5/6
[20:59:12] <BBB> error: Unable to find d1ec4470be04fba3ff10fbecd455a14ab322d14e under http://github.com/yuvi/ffmpeg.git
[20:59:12] <BBB> Cannot obtain needed object d1ec4470be04fba3ff10fbecd455a14ab322d14e
[20:59:12] <BBB> while processing commit 0681684c9eaad2aaad060fbd664c28041378fb5c.
[20:59:12] <BBB> fatal: Fetch failed.
[20:59:15] <BBB> what is that?
[20:59:42] <ohsix> missing a pack?
[20:59:52] <BBB> I don't know what that means
[21:00:15] <wbs> BBB: you've probably got an old git version and using the http url.. even if that shouldn't fail, you'd be better off either using the git:// url or upgrading to a newer git
[21:01:01] <wbs> their old http transport mechanism is slow and failure prone, the new smart http is about as fast as over git:// or ssh
[21:01:42] <Yuvi> never seen that before, but yeah, use git:// if possible
[21:02:10] <Yuvi> anyway, fixed my screwing up your patch
[21:02:35] <ohsix> shallow clones and repacks can make stuff unreferenced, git gc will clean it up if its a real problem
[21:02:49] <ohsix> theres a thing to display loose refs too
[21:02:54] <Yuvi> git gc on whose end?
[21:02:54] <BBB> Yuvi: is decode_mb() for the stuff directly after the mvprob prediction?
[21:03:23] <Yuvi> yeah, it uses data from the same partition
[21:04:06] <Yuvi> or the header does
[21:05:19] <BBB> hm, the //reset s->mvc fell off the patch somehow
[21:05:41] <BBB> yeah I should use git instead of quilt, quilt is painful at mistakes
[21:06:04] <ohsix> hurf my git doesn't seem to know about repack or anything anymore; they might have ditched that whole thing
[21:06:23] <FFFF-RAGE> A patch to look at: http://pastebin.org/284035
[21:06:47] <astrange> git 1.7 still has repack
[21:07:18] <ohsix> git version 1.7.0.4
[21:07:27] <Yuvi> basically (since the spec doesn't explain this): each macroblock mode is stored in the frame header, right after all the probability updates
[21:07:27] <Yuvi> the coeffs are in the partitions after, and use separate arith coder contexts
[21:07:28] <Yuvi> macroblock row i is in partition i%(num partitions)
[21:07:32] <ohsix> was it optional or deprecated?
[21:08:22] <BBB> Yuvi: I have the source in front of me ;)
[21:08:24] <ohsix> ah they hid all the applets from the path
[21:08:30] <BBB> I don't read the spec, too often it's wrong
[21:08:34] <FFFF-RAGE> wbs: can you look at: http://pastebin.org/284035
[21:08:41] <astrange> FFFF-RAGE: send it to ffmpeg-devel
[21:09:15] <FFFF-RAGE> I will if people don't say that it needs a major change
[21:09:18] <ohsix> and the man pages aren't in a reachable spot for those moved applets either, hrmph
[21:09:33] <wbs> FFFF-RAGE: I'm not sure if someone wants to keep the separate mono codepath or not
[21:10:04] <wbs> FFFF-RAGE: and for the channel mapping, at least for decoders, they're able to declare their channel mapping somewhere, but I have no clue about how to do this for encoders
[21:10:18] <wbs> FFFF-RAGE: so I can't help you, but hopefully someone on the mailing list can
[21:10:23] <Dark_Shikari> hyc: ping me when you have time to test it then.
[21:10:39] <wbs> FFFF-RAGE: I think superdump has been meddling with channel mappings at least
[21:10:47] <Yuvi> the spec is helpful for some stuff, even if it's not clear and dead wrong in places
[21:10:47] <Yuvi> figuring out coeff decode is a lot easier to read chapter 13 first than piece out detokenize.c
[21:11:14] <FFFF-RAGE> I'll send it off then
[21:11:26] <BBB> Yuvi: true
[21:11:38] <BBB> yuvi: although in 50% of the cases the spec code is literally the decoder code :)
[21:11:44] <BBB> I mean literally
[21:11:51] <Yuvi> heh, yeah
[21:12:05] <Dark_Shikari> chapter 13 is detokenize.c
[21:12:05] <Dark_Shikari> seriously
[21:12:21] <BBB> :-p
[21:12:44] <Yuvi> Dark_Shikari: in theory, no clue (yet) how accurate it is
[21:14:41] <BBB> Yuvi: more generally, how can I be helpful at this?
[21:14:52] <BBB> Yuvi: would you like me to focus on particular chapters, different functions?
[21:15:07] <BBB> 2 people on 1 code is a little complex
[21:15:49] <mru> Dark_Shikari: have you tried mpeg4 asp?
[21:16:05] <Dark_Shikari> mru: that's what I want to test the speed of now
[21:16:26] <DonDiego> Yuvi: did you check out my crash?
[21:16:28] <peloverde> I would try SP
[21:16:28] <Yuvi> BBB: yeah, maybe you could work on interframe-only stuff for the moment? either that or verify that the bitstream parsing I've done so far is right
[21:16:52] <Yuvi> DonDiego: that only happens with theora?
[21:17:01] <drv> FFFF-RAGE: it might be worth it to factor out the l*context->vi.channels part, unless gcc already does that
[21:17:05] <mru> Dark_Shikari: don't use qpel or gmc
[21:17:10] <Dark_Shikari> mru: I know
[21:17:13] <mru> there's no neon for those
[21:17:20] <Dark_Shikari> mru: oh, so normal MC has neon for mpeg-4?
[21:17:23] <mru> yes
[21:17:24] <Yuvi> BBB: I don't plan on looking at chapters 16+ until keyframes are bitexact
[21:17:27] <Dark_Shikari> sweet, thx
[21:17:33] <Dark_Shikari> anything in mpeg-4 sp/h263 that doesn't have neon?
[21:17:45] <mru> "normal" is same as mpeg2 more or less
[21:17:48] <BBB> Yuvi: I'll start a rough verify and then I'll do inteframe
[21:17:49] <BBB> thanks
[21:17:56] <Dark_Shikari> mru: yeah, with the +1/-1 rounding
[21:18:01] <Dark_Shikari> which alternates
[21:18:05] <DonDiego> Yuvi: what do you mean only with theora - it's a crash in the theora testsuite..
[21:18:07] <Dark_Shikari> or did mpeg2 do that too
[21:18:13] <mru> there's neon for both rounding variants
[21:18:16] <Dark_Shikari> k
[21:18:24] <Yuvi> DonDiego: I mean, the crash is from av_picture_copy
[21:18:40] <mru> whatever the mpeg4 big buck bunny clip uses is optimised
[21:18:49] <Dark_Shikari> lol
[21:18:55] <Yuvi> which I think is copying into a buffer sdl provided
[21:19:26] <BBB> Yuvi: second half of patch now also in your inbox
[21:19:34] <BBB> it fell off the first patch (not sure why)
[21:19:51] <BBB> it resets s->prob.mvc for keyframes
[21:21:23] <FFFF-RAGE> drv: thanks for the tip
[21:22:55] <Yuvi> BBB: thanks pushed
[21:23:07] <DonDiego> Yuvi: well, i have not found any other samples to reproduce so far..
[21:23:15] <DonDiego> Yuvi: does the duck sample work for you?
[21:23:53] <mru> Dark_Shikari: btw mpeg2 is slower than mpeg4 to decode at acceptable quality
[21:24:22] <Yuvi> DonDiego: yeah
[21:24:30] <DonDiego> hmm
[21:24:51] <DonDiego> Yuvi: can you reproduce the funky colors gmaxwell talked aobut?
[21:25:17] <Yuvi> DonDiego: already fixed (r23304)
[21:25:29] <Yuvi> which isn't backported to 0.6 yet I think?
[21:26:57] <DonDiego> could be, dunno..
[21:27:03] <Dark_Shikari> mru: why is that, differetn vlc tables?
[21:27:09] <BBB> how do I switch branch in git?
[21:27:20] <Yuvi> git checkout <branch name>
[21:27:38] <BBB> git checkout vp8?
[21:27:41] <BBB> doesn't work :(
[21:27:49] <Yuvi> if it's remote, add origin/<branch name>
[21:27:50] <mru> Dark_Shikari: higher bitrate required for same quality
[21:28:07] <Yuvi> git checkout -b vp8 origin/vp8 will set up a local branch to track the remote
[21:28:29] <BBB> why would I want that?
[21:28:54] <Yuvi> because otherwise you're going to loose your local commits into the ether
[21:29:04] <BBB> oh
[21:29:05] <BBB> ok
[21:29:11] <BBB> and then git pull?
[21:29:26] <Yuvi> yeah
[21:29:27] <mru> you might want git pull --rebase
[21:29:39] <mru> otherwise you end with lots of merge commits
[21:29:43] <mru> which is annoying in a private tree
[21:29:55] <BBB> I'm confused
[21:30:01] * BBB runs configure and hopes nothing breaks
[21:30:31] <BBB> it's like this ultra-sharp swiss-army knife and I just know I'm gonna cut myself
[21:30:35] <BBB> somehow I still play with it
[21:31:16] <astrange> well git has advanced recovery tools (revlog and git reset --hard) to go with the advanced breaking-everything tools
[21:31:19] <ohsix> but it has a freakin' toothpick and a woodsaw!,  scissors!
[21:31:39] <mru> git usually lets you undo mistakes
[21:31:46] <BBB> the "usually" scares me
[21:31:57] <BBB> but ok, I'll try it
[21:32:00] <mru> just don't git gc --prune=now
[21:32:06] <ohsix> ^
[21:32:08] <BBB> worst case I keep sending patches by mail to yuvi
[21:32:23] <BBB> Yuvi: how do I commit patches myself?
[21:32:25] <ohsix> unreached objects eventually get tossed, but operations just unlink them, so you can link them back in
[21:32:42] <Yuvi> BBB: git commit
[21:32:43] <ohsix> at least in your working copy
[21:32:49] <Yuvi> -a to be like svn
[21:33:02] <mru> don't commit -a
[21:33:04] <mru> it's evil
[21:33:08] <mru> try git gui
[21:33:11] <mru> it's quite nice
[21:33:51] <astrange> i prefer git diff + commit -a, partial commits seem like they could create commits you haven't tested on their own
[21:34:59] <BBB> ok
[21:35:03] <BBB> so is it locally or remotely committed now?
[21:35:11] <Yuvi> locally
[21:35:11] <BBB> I did a commit in git gui
[21:35:14] <BBB> git gui is nice, btw
[21:35:22] <Yuvi> git push is for remote
[21:35:25] <BBB> so can I commit remotely somehow?
[21:35:31] <BBB> push, aha
[21:36:01] <BBB> does the push button push the last commit, all commits or the current commit?
[21:36:08] <Yuvi> all
[21:36:19] <BBB> that sounds dangerous
[21:36:20] * BBB tries
[21:36:58] <BBB> source branch, vp8?
[21:37:04] <BBB> destination repo: origin?
[21:37:13] * BBB feels like he'll break something
[21:37:52] <Yuvi> can't yet since github is timing out in giving you commit rights
[21:38:00] <BBB> shouldn't it "push" to origin/vp8?
[21:38:03] <BBB> instead of origin?
[21:38:27] <Yuvi> no, branches are separate from repos in push
[21:38:50] <Yuvi> geh, I have to go, bbl
[21:38:54] <BBB> bye :)
[21:41:41] <BBB> -((col * 16) << 3) -> would gcc automatically optimize that to col << 7?
[21:42:08] <mru> BBB: try and see
[21:42:23] <mru> I suspect it does
[21:44:53] <Dark_Shikari> mru: what's a configure line for ffmpeg on a cortex a8?
[21:44:56] <Dark_Shikari> i.e. with neon and all that jazz
[21:45:50] <mru> fate should have a good one
[21:46:00] <janneg> depending on your tools --arch=armv7 --cpu=cortex-a8 --extra-cflags="-mfpu=neon -mfloat-abi=softfp"
[21:46:10] <mru> --arch=arm is fine
[21:46:24] <mru> --cpu is the detailed one
[21:50:28] <Dark_Shikari> softfp?
[21:50:29] <Dark_Shikari> why
[21:50:42] <mru> that's just the calling convention
[21:51:02] <mru> it took gcc like 15 years to add proper fpreg parameter passing
[21:51:37] <mru> and even now it takes some serious acrobatics to bootstrap a system with it
[21:51:53] <mru> so most systems still pass fp args in integer regs
[21:51:57] <ohsix> isn't codesourcery over that junk
[21:51:59] <Dark_Shikari> ah k
[21:52:02] <hyc> I think the Angstrom ffmpeg build is already configured pretty well
[21:52:08] <mru> ohsix: recent gcc versions support it, yes
[21:52:31] <hyc> Dark_Shikari: you can see its settings anyway, seems to cover all the bases for cortex a8
[21:52:33] <ohsix> i mean weren't they the first, relatively recent interest in doing so
[21:52:39] <mru> Dark_Shikari: it doesn't matter for performance in ffmpeg
[21:52:43] <peloverde> Doesn't that suck when functions returning float are called in a tight loop?
[21:53:00] <mru> peloverde: yes, but we don't do that
[21:53:18] <mru> calling _anything_ in a tight loop is usually a bad idea
[21:53:25] <astrange> lto would allow internal functions to violate abi anyway
[21:53:33] <astrange> though i doubt it'd be worth it
[21:53:50] <mru> astrange: gcc simply didn't have the ability to generate such calls _at all_
[21:54:31] <peloverde> I could have sworn we ran into that in SBR land, though the SBR filterbank needs a rewrite
[21:54:54] <BBB> you just wrote it
[21:54:59] <mru> my profiling shows nothing like that
[21:55:21] <mru> most of the time is spent in easily simdable loops
[21:55:57] <mru> which I'm not going to spend time optimising if it's slated for rewriting anyway
[21:57:19] <peloverde> meh, it's still faster than faad
[21:57:48] <mru> if I can triple the speed again, I will
[21:59:03] <BBB> peloverde: we love you for that
[21:59:57] <peloverde> most of the speed advantage comes from LC and dsputil
[22:00:19] <mru> and fft
[22:00:27] <mru> which isn't technically part of dsputil
[22:00:32] <peloverde> fair enough
[22:01:26] <peloverde> Also I think faad uses doubles some places where it doesn't need to
[22:02:53] <Dark_Shikari> 2fps encoding! woohooo
[22:02:56] <Dark_Shikari> <3 cortex a8
[22:03:03] <peloverde> I guess not
[22:08:14] <janneg> Dark_Shikari: -vcodec mpeg -qscale 3 is twice as fast as -vcodec libx264 -vpre ultrafast and has similiar filesize
[22:08:24] <janneg> decoding
[22:10:57] <Dark_Shikari> janneg: on an arm?
[22:13:06] <bcoudurier> janneg, which mpeg ? mpeg2video ?
[22:14:50] <janneg> mpeg4
[22:14:57] <janneg> Dark_Shikari: on omap3
[22:16:43] <janneg> just decoding, i.e. -f null /dev/null
[22:17:27] <janneg> it's a little bit faster with -flags -qpel-gmc
[22:17:43] <mru> aren't those off by default?
[22:19:06] <Dark_Shikari> yes they are
[22:27:08] <CIA-93> ffmpeg: stefano * r23342 /trunk/ (libavformat/nut.c libavcodec/raw.c):
[22:27:08] <CIA-93> ffmpeg: Add support for the newly added Nut codec tags (added in Nut r669):
[22:27:08] <CIA-93> ffmpeg: Y1[00][16], [16][00]1Y, Y3[11][16], [16][11]3Y, Y3[10][16],
[22:27:08] <CIA-93> ffmpeg: [16][10]3Y, Y3[00][16], [16][00]3Y, Y4[11][ 8], Y2[00][ 8].
[22:38:36] <janneg> mpeg2 -qscale4 is a little bit faster but still more factor 2 than 2.5
[22:38:55] <Dark_Shikari> mpeg2 is faster than mpeg4?
[22:42:40] <janneg> yes, 5-10% at qscale 4.
[22:43:01] <janneg> testing with a 1280x720 video
[22:47:32] <pengvado> why is mpeg2 faster than mpeg4? what work is it skipping?
[22:54:45] <janneg> theora is not even 50% faster as h264 --ultrafast at the same bitrate and same speed at double bitrate
[22:57:44] <astrange> mpeg12 bitstream might be faster than mpeg4 bitstream
[22:58:03] <astrange> or maybe one isn't using simpleidct
[22:59:13] <janneg> ffv1 is around 50mbps, i.e. too much for 802.11 g
[23:02:41] <pengvado> janneg: decoding speed? that's called --tune=fastdecode, not --preset=ultrafast
[23:08:34] <janneg> pengvado: Dark_Shikari asked for --preset ultrafast, testing --tune=fastdecode now
[23:09:28] <Dark_Shikari> already benched it here
[23:09:34] <Dark_Shikari> ffv1 is way too slow =p
[23:09:44] <Dark_Shikari> what about svq1?
[23:10:25] <Dark_Shikari> or other similar fast things?
[23:10:31] <Dark_Shikari> is svq1 fast enough to encode in realtime anyways?
[23:10:44] <janneg> mjpeg is slower than mpeg4
[23:12:11] <Dark_Shikari> interesting
[23:12:15] <Dark_Shikari> not surprising though
[23:12:20] <janneg> doesn't look like it is without multithreading
[23:12:34] <Dark_Shikari> I could always go hack in optimizations to svq1 of course
[23:12:40] <Dark_Shikari> how fast does it decode?
[23:12:54] <janneg> --tune=fastdecode is slower than --preset=ultrafast
[23:13:03] <janneg> Dark_Shikari: still encoding
[23:14:07] <janneg> 3fps
[23:15:33] <mru> astrange: mpeg2 and mpeg4 should use the same idct by default
[23:16:14] <Dark_Shikari> mru: also note that we can modify video formats however we want
[23:16:21] <mru> doubling the svq1 encoder speed is probably trivial
[23:16:21] <Dark_Shikari> e.g. if we wanted, we could swap out the transform for h264's transform
[23:16:28] <Dark_Shikari> we control encoder and decoder
[23:16:34] <Dark_Shikari> (the mpeg-2 transform, that is)
[23:16:48] <mru> mpeg2 or mpeg4 with h264 transform would be interesting
[23:16:54] <Dark_Shikari> it would have to be simple enough to be a small project though; we don't really have time right now for something complicated
[23:17:06] <mru> idct is a huge chunk of cpu time in mpeg2/4
[23:17:09] <Dark_Shikari> how much faster is h264 transform than mpeg-2 on arm?
[23:17:30] <mru> I haven't measured the transform separately
[23:17:44] <mru> but it's much simpler
[23:18:00] <Dark_Shikari> and of course I mean the 8x8 one
[23:18:03] <Dark_Shikari> to make it a direct swap-out
[23:18:05] <mru> yes, of course
[23:18:25] <Dark_Shikari> you'd need to mess with quant ofc
[23:18:34] <astrange> how much sparse row handling does arm simpleidct have?
[23:18:47] <mru> some
[23:19:00] <astrange> also, mpeg4 with a flat dct will have really bad blocking, even if the qscale is precise
[23:19:08] <Dark_Shikari> "flat dct"?
[23:19:11] <mru> the decoders don't track last nonzero unfortunately
[23:19:15] <astrange> flat cqm
[23:19:19] <Dark_Shikari> oh.
[23:20:18] <astrange> iirc last nonzero doesn't help if you use ac prediction
[23:21:01] <mru> eh?
[23:21:47] <mru> if last nonzero is low enough you can skip large chunks of the transform
[23:21:55] <Dark_Shikari> ac pred is only for intra iirc
[23:22:23] <astrange> mpeg4videodec.c:1082
[23:22:26] <astrange> ah
[23:22:44] <astrange> yeah, that is in intra
[23:22:49] <mru> but without a last nonzero indicator you have check all the coeffs
[23:23:48] <mru> and that's not much faster than doing the transform in neon
[23:24:11] <astrange> yeah
[23:24:27] <astrange> it should be really cheap in sse4, i need to rewrite the xvid idct for that. but i can't understand my own macros anymore
[23:34:01] <janneg> Dark_Shikari: svq1 is another 10% faster
[23:37:53] <janneg> factor 2.1 compared to --preset=ultrafast (which somehow got or more likely I mixed up utime and real time the first time)
[23:38:00] <janneg> +faster
[23:39:24] <spaam> astrange: "but i can't understand my own  macros anymore" <-- haha.. thats bad ;S
[23:39:27] <mru> once in a while I've seen utime > real time on a single-core
[23:39:35] <mru> no idea what's going wrong when that happens
[23:39:55] <mru> spaam: no, it's very clever macros
[23:40:13] * mru hopes he'll never have to debug his own macros
[23:40:51] <spaam> mru: why is that clever?  you write it so you can understand it .
[23:41:19] <astrange> i understand them when they're expanded
[23:41:45] * mru points at brian kernighan
[23:42:08] <spaam> whos that?
[23:42:24] <mru> go away, you are not worthy to be here
[23:43:14] <spaam> haha
[23:43:28] <spaam> ah thats him.. ;S
[23:43:35] <spaam> one of the K&R guys..
[23:43:35] <mru> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
[23:44:20] <spaam> nice