[FFmpeg-devel-irc] IRC log for 2010-03-19

[irc at mansr.com]

[00:00:36] <ohsix> maybe you should post a bug for it :>
[00:01:21] * Kovensky usually runs autogen with --help
[00:02:29] <ohsix> thats a good idea, but the people normally running it are rolling tarballs, or developing from source control
[00:06:48] * Kovensky still wonders if it was a good idea to commit configure and assorted files to version control
[00:07:29] <mru> never was
[00:07:37] <ohsix> its not, but circumstances vary, much like you wouldn't commit other generated files
[00:07:38] <mru> but with autohell it's the only viable option
[00:08:29] <Kovensky> lulz
[00:08:40] <Kovensky> I think I did it accidentally, but decided to keep it so I wouldn't hear from MSYS users
[00:12:28] <ohsix> sometimes you can get away with just generating some of the generated files for certain programs to a static copy or something; like a config.h thats presetup for stuff thats only available on windows
[00:12:46] <ohsix> autotools can do some nutty stuff though, like generate compatibility wrappers
[02:29:48] <MrNaz_yma> now that ffmpeg has lavf, how feasible is it getting yadif implemented within ffmpeg? decent interlacing would be a pretty big thiong
[02:30:04] <mru> you mean lavfi
[02:30:10] <mru> lavf is libavformat
[02:30:14] <MrNaz_yma> oh
[02:30:17] <MrNaz_yma> well them
[02:30:19] <MrNaz_yma> then
[02:30:26] <MrNaz_yma> please excuse me while i go back to my corner
[02:30:29] <mru> patches welcome I guess
[02:30:43] <MrNaz_yma> me? submit a patch? why do you hate ffmpeg so?
[02:30:59] <mru> $$$ welcome
[02:38:51] * kierank gives mru some zimbabwe $$$
[02:39:31] <mru> £££ welcome
[02:40:28] <bcoudurier> humm where is my euro symbol :(
[02:41:28] <astrange> option-3 on mac keyboards (us anyway)
[02:50:35] <kierank> alt-gr + 4 on uk keyboards
[03:00:28] <mru> http://daringfireball.net/linked/2010/03/18/wikipedia-ogg
[03:00:33] <mru> well said
[03:08:23] <ohsix> abscence of evidence isn't evidence of absence, you can look on commons and see all the junk on there
[03:08:47] <mru> that's not what he said
[03:09:21] <mru> he said that although wikipedia does host videos, they are not something you typically use wikipedia for
[03:09:39] <mru> I've never watched a video on wikipedia
[03:09:42] <mru> have you?
[03:09:42] <ohsix> i know what he said, he elided how much time he spends looking for theora files on wikipedia
[03:09:48] <ohsix> yes
[03:10:04] <ohsix> back when it was just the java player even :P
[03:10:10] <mru> when I use wikipedia, I'm looking for text 90% of the time
[03:10:20] <mru> pictures for the rest
[03:10:44] <mru> I can't recally _ever_ reading an article that had a video
[03:10:47] <ohsix> not like you can actually look for video or audio on wikipedia; they accompany the article they're relevant to
[03:11:31] <mru> so?
[03:11:57] <mru> I read something on wikipedia more or less every day
[03:12:07] <mru> and I've still not seen a single video
[03:12:42] <mru> it is thus utterly irrelevant to me what format they're in
[03:12:54] <mru> might as well be realvideo for all I care
[04:27:45] <MrNaz_yma> [mpeg2video @ 0x1c4dd70]warning: first frame is no keyframe
[04:27:51] <MrNaz_yma> "That's no keyframe!"
[04:46:37] <peloverde> It's a battle station?
[04:56:34] <Dark_Shikari> a fully operational battlestation?
[04:57:03] <relaxed> It's too big to be a space station!
[04:57:18] <Dark_Shikari> ohsix: the java player is great
[04:57:22] <Dark_Shikari> it crashes firefox 100% of the time
[04:58:21] <ohsix> never did here
[04:58:45] <Dark_Shikari> I finally ended up upgrading to 3.5 even though it sucks so much just because of javascript performance
[04:58:49] <Dark_Shikari> I mean, BALLS, 3.0 was slow
[04:58:55] <Dark_Shikari> gmail was getting to take 30 seconds to load emails
[04:59:10] <ohsix> i remember during an api interface change thing & the limbo plugin would crash all the time, but that was just running
[04:59:17] <votz> Dark_Shikari: my favorite is when the prompt window just asking you if its ok to run a java applet crashes firefox
[04:59:32] <ohsix> on x86_64 theres still no jit
[04:59:51] <Dark_Shikari> ohsix: oh wow
[05:00:02] <votz> ohsix: have they said why?
[05:00:21] <votz> 64 bits is just TOO much
[05:00:23] <ohsix> what extensions? 30sec is bizarre & the "js going slow, stop?" would have appeared even for the chrome if it was js
[05:01:13] <Dark_Shikari> ohsix: chrome ran it faster though
[05:01:17] <ohsix> theres no "why", nanojit didn't have an x86_64 backend when they switched, it does now; but with their release stuff it wont be until 3.7 (though you can run it now, if you want)
[05:01:19] <Dark_Shikari> extensions?  a bunch but mostly trivial ones
[05:01:22] <Dark_Shikari> adblock is probably the primarily slowdown
[05:01:42] <ohsix> chrome is every part of the browser that isn't a webpage, not chrome the browser
[05:02:20] <ohsix> i haven't seen anhything like that with adblock, but the tab thing for certain elements has a storied history
[05:03:09] <Dark_Shikari> oh, I thought you meant google chrome
[05:03:39] <ohsix> theres a cycle collector that will unfuck most, even bad extensions still in the wild; but bindings can still leak all over if they aren't properly written
[05:04:07] <ohsix> nah, it was a general term for "the bits around the edges" before google chrome even existed :P
[05:05:02] <ohsix> 30sec bespeaks an extension/nativre code plugin doing something awful, though
[05:06:37] <ohsix> it does give you enough rope to hang yourself though, people tend to be fascinated with extensions when they first switch, too; and they generally leave em there even if they dont use them, so its a cruftbomb waiting to happen
[05:07:53] <Dark_Shikari> well lets look at mine
[05:07:58] <Dark_Shikari> adblock plus: critical
[05:08:00] <ohsix> in my main session i run with all the native plugins disabled, so they don't lurk in some far off tab
[05:08:02] <Dark_Shikari> chatzilla: don't use it anymore
[05:08:09] <Dark_Shikari> cutemenus: well, it makes the menus nicer.
[05:08:17] <Dark_Shikari> download statusbar: awesome, the built-in download manager is utter garbage
[05:08:21] <Dark_Shikari> downthemall: amazing
[05:08:30] <Dark_Shikari> fireftp: awesome, the builtin ftp client is garbage
[05:08:33] <Dark_Shikari> flashblock: critical obviously
[05:08:36] <Dark_Shikari> greasemonkey: sorta cool
[05:08:40] <Dark_Shikari> rikaichan: awesome
[05:08:44] <ohsix> ahhh download statusbar, thats not broken itself but can lead to huge delays
[05:08:50] <Dark_Shikari> menu editor: critical for removing all that junk the extensions add
[05:08:54] <Dark_Shikari> organize status bar: same
[05:09:00] <Dark_Shikari> resizable text area: OMG WHY IS THIS NOT IN TRUNK
[05:09:05] <Dark_Shikari> screengrab: cool
[05:09:21] <ohsix> the download history can get years long with it; and that eventually slows stuff up tons
[05:09:43] <Dark_Shikari> searchbar autosizer: same as resizable text area
[05:09:44] <Dark_Shikari> stylish: meh
[05:09:46] <ohsix> i dunno if the moved downloads from rdf to sqlite/places at all; they might have
[05:09:48] <Dark_Shikari> tab mix plus: critical
[05:09:52] <Dark_Shikari> tree style tabs: the single best extension in firefox history
[05:09:58] <Dark_Shikari> url fixer: cool beans
[05:10:01] <peloverde> because the mozilla devs are complacent jerks?
[05:10:03] <Dark_Shikari> so yeah, basically all of my extensions are sorta important.
[05:10:10] <elenril> you dont' use noscript?
[05:10:15] <Dark_Shikari> no, noscript is useless
[05:10:17] <Dark_Shikari> it breaks the entire internet
[05:10:24] <ohsix> tabmixplus is another one that likes to break often, and taking ff with it too
[05:10:28] * elenril wonders how he didn't notice
[05:10:35] <peloverde> There is a ton of stuff where they basically said this is too much work/no one will ever want this until chrome did it and they back peddled
[05:10:43] <astrange> i use wp-hashcash and people with noscript always end up in the spam queue
[05:11:06] <astrange> but people with noscript are always really angry so i don't bother approving the comments sometimes
[05:11:15] <ohsix> tabkit covers a lot of those too, and its less omgexplode-y
[05:12:19] <ohsix> other than that i dont see any problematic ones
[05:13:37] <ohsix> mines adblock, flashblock, greasemonkey (in a pinch can bodge anything, even stuff you'd want an extension for), tab counter (for no real reason, 361 tabs open now :), tab history & tab kit
[05:13:38] <Dark_Shikari> I recall adblock creates lots of lag
[05:13:40] <Dark_Shikari> due to its regexes
[05:13:51] <Dark_Shikari> oh yeah, and my firefox crashes every 3 days
[05:13:54] <Dark_Shikari> clockwork
[05:13:59] <Dark_Shikari> I think it's because it's running out of address space
[05:14:11] <Dark_Shikari> and firefox, being crap, doesn't have graceful handling of malloc failures.
[05:14:29] <ohsix> adblock wasn't that bad even when i was doing my own bad lists, they have subscriptions now & vet for expensive patterns before they get in
[05:14:30] <Dark_Shikari> then again, it doesn't seem to know how to free memory anyways
[05:14:55] <ohsix> you cant be graceful about malloc failing
[05:15:03] <Dark_Shikari> sure you can.  you can at least tell the user what happened
[05:15:19] <Dark_Shikari> x264 tells you what failed, where it failed, and closes without a segfault
[05:15:20] <ohsix> why, when they can just suspect? :P
[05:15:47] <ohsix> are you running without a swap file?
[05:16:03] <ohsix> /partition
[05:16:03] <Dark_Shikari> no
[05:16:09] <Dark_Shikari> default windows 7 settings
[05:16:15] <Dark_Shikari> _address space_.  it caps at 2 gigabytes
[05:17:05] <peloverde> Really? I don't seem to run into that?
[05:17:21] <ohsix> heh its not as cut & dry as that
[05:17:58] <peloverde> I thought it was 16 GB for home premium?
[05:18:16] <Dark_Shikari> 32-bit processes
[05:18:19] <Dark_Shikari> have a 2gb address space limit.
[05:18:20] <Dark_Shikari> period.
[05:18:21] <Dark_Shikari> full stop.
[05:18:30] <peloverde> Dark_Shikari: 32-bit is obsolete
[05:18:32] <Dark_Shikari> (unless you compile with and run with /LARGEADDRESSAWARE, in which case they have 3.)
[05:18:37] <ohsix> address space availalable to an app is different than page table chicanery
[05:18:38] <Dark_Shikari> peloverde: And yet firefox still has no JIT for 64-bit ;)
[05:18:56] <peloverde> Yet another reason I don't use firefox
[05:19:18] <ohsix> its not as big a difference as you'd suspect
[05:19:45] <ohsix> the chrome tends to get pulled into webpages that are slow though, which is a drag
[05:19:55] <peloverde> I think Mozilla has creeped up to the top of my organizations-I-want-to-see-fail list
[05:20:24] <Dark_Shikari> peloverde: The really funny thing will be when IE9 comes out
[05:20:42] <Dark_Shikari> remember when Mozilla touted them as supporting all the web standards and IE not
[05:20:43] <ohsix> heh, then the magic vacuum left in its wake can generate The Singularity(tm)
[05:20:56] <Dark_Shikari> and now we're going to have everyone supporting stuff except firefox
[05:21:20] <Dark_Shikari> Then again, firefox should have died in a fire around the time it started using 1.5 gigs of memory
[05:21:40] <ohsix> vma size (brk size) != rss
[05:21:49] <peloverde> And Opera, who are their own special brand of crazy
[05:22:09] <Dark_Shikari> ohsix: I'm talking about actual used memory, not commit size
[05:22:19] <Dark_Shikari> opera are funny
[05:22:24] <Dark_Shikari> opera is like the plan 9 of browsers
[05:22:28] <Dark_Shikari> or the BeOS
[05:23:17] <ohsix> 32303 ohsix     21   1 2250M  921M 21580 S 20.0 32.6  8h31:26     0     0  `- /usr/lib/firefox-3.5.8/firefox
[05:24:23] <ohsix> oh, wait there is the one thing without jit; it tends to use 5% cpu servicing timers and dom junk even when otherwise "idle", with jit it barely breaks 1% for the hugest sessions
[05:27:31] <ohsix> computers i've tried to restore my ff session on in other browsers (open all bookmarks, wait an hour) have failed it hard, ie still uses heavyweight processes too; so opening a new "tab" makes the chrome go through the motions while you wait for an shdocvw instance to appear
[05:28:38] <ohsix> someone else can make the argument for or against having 3-500 tabs open in the first place; but at least it works still :P
[05:29:03] <Dark_Shikari> it's the only way to browse tvtropes
[05:29:12] <Dark_Shikari> I use a depth-first search
[05:29:20] <Dark_Shikari> and even that spawns a huge ton of pages
[05:29:23] <Dark_Shikari> breadth-first must be even worse
[05:29:27] <ohsix> it does have one "heap" problem thats still present on windows though, it indiscriminately uses gdi objects without regard to the limits
[05:30:27] <ohsix> plus it creates a brush per object & never releases them, lik CreateBrush to create a white one _every time_, wheb theres getstockobject & a fixed table of free ones that include black
[05:31:03] <ohsix> once it hits 10000 its quite a show, windows actually starts to fail :P
[05:31:33] <Dark_Shikari> lol
[05:32:36] <Dark_Shikari> http://en.wikipedia.org/wiki/File:IE7_Errors_caused_by_10000_GDI_Objects_2.jpg
[05:32:41] <ohsix> re" tvtropes, for real; any wiki worth a shit is usually a tabgasm waiting to happen, one reason idon't really like wiki's is i cant control myself & end up with a month long reading task
[05:33:30] <ohsix> notice he took that with a camera
[05:33:54] <ohsix> cuz windows is broke, it cant even create a compat dc for a clipboard object
[05:34:01] <Dark_Shikari> yup
[05:34:01] <Dark_Shikari> lol
[05:35:09] <ohsix> that gdi out of resources thing is a good example of why you cant really "handle" those situations, windows certainly cant provide ui to inform you of the problem
[05:35:41] <Dark_Shikari> of course you can handle it
[05:35:43] <Dark_Shikari> oomkiller-style
[05:35:59] <ohsix> for OOM/malloc = null, you need some stack or otherwise to dig you out of an unknown program state, or you wrap allocations & fail insitu
[05:36:19] <Dark_Shikari> the latter is fine
[05:37:51] <ohsix> depends on the type of software, if its at all sensitive to memory consumption it should probably just be run when the environment is suitable; people try and check every allocation & stuff though, and not with a wrapper; that is fail
[05:38:33] <ohsix> insitu warnings don't really inform anyone of the whys
[05:41:26] <ohsix> and unwinding, or hacks to get around it for proper diagnosis just litter the place up, its best to just crash, then someone who cares can dig through the core file; it a really rare circumstance to such mindfully handle
[05:42:11] <Dark_Shikari> it's nice to tell the user what went wrong though
[05:42:14] <Dark_Shikari> particularly with x264 at least
[05:42:18] <Dark_Shikari> a ton of people were reporting "crashes"
[05:42:22] <Dark_Shikari> when it was really avisynth eating up all the ram
[05:42:43] <ohsix> def, but it depends on the software
[05:43:40] <ohsix> if its something like that with interactions then the people reporting the bug or doing triage probabbly didn't do due diligence with reproducing the circumstance
[05:43:44] <Dark_Shikari> of course
[05:44:42] <ohsix> if its ff theres really nothing to do but to report a crash to upstream via apport or the google reporting thing, or that other thing moz used to use, even for OOM
[05:45:23] <ohsix> though they might not get a chance at it if some other software kills it first
[05:46:48] <ohsix> fwiw windows still reports to a window station when its "resources" are low, it doesn't say what, and it just suggests closing things, if you miss the app thats got all the stuff, the notice comes up a bit later; repeat until system is nonresponsive
[05:47:37] <ohsix> thats mostly per window station type resources though, or when a service starts failing acquiring handles
[05:49:13] <ohsix> firefix has a pretty big resource punchdown in the event it starts getting anywhere near system capacity, it cant do shit about what some ad-hoc extension does though
[05:50:07] <ohsix> http://msdn.microsoft.com/en-us/library/aa366586%28VS.85%29.aspx
[05:50:47] <ohsix> ff is kind of like its own os or bigtime db when it comes to memory use, its really amazing that it even scales as far as it does on windows
[05:51:27] <ohsix> if you have 2 self tuning memory hogs, stuff tendsw to get broke real fast as their usage policies battle it out for swap bandwidth
[05:56:19] <ohsix> windows is in rare form when theres no swap; and globalmemorystatus gets very noisy to boot
[06:21:38] <jai> hmm, videolan wants to rewrite their mkv demuxer
[06:21:52] <jai> can't they just use lavf
[06:22:02] <Dark_Shikari> NIH
[06:22:16] <jai> :(
[06:22:20] <kshishkov> it's funny when applied not to FFmpeg
[06:22:29] <elenril> lavf mkv demuxer f4ilz0rz
[06:22:36] <jai> elenril: elaborate
[06:22:48] * kshishkov thinks about having RTMP as an external protocol handler
[06:23:05] <kshishkov> jai: not enought metadata for him obviously
[06:23:12] <kshishkov> *enough
[06:23:44] <jai> lol
[06:24:15] <jai> also, they are running a task for dvda support
[06:24:23] * elenril shoots kshishkov 
[06:24:26] <jai> maybe that can be done in ffmpeg instead
[06:24:34] <elenril> it butchers ass subs
[06:24:40] <av500> how?
[06:24:44] <ohsix> ass :D
[06:25:05] <elenril> av500: just try mplayer -demuxer lavf <some random anime>
[06:25:08] <ohsix> libass is busted to a degree everywhere else too
[06:25:36] <ohsix> of the last few bugs i've reported to some media junk, 2 ended up being ASS related
[06:26:13] <kshishkov> elenril: seems fine
[06:26:25] <jai> elenril: worked for me last i tried
[06:26:29] <ohsix> with the embedded fonts?
[06:26:37] <av500> elenril: besides rewrtiting the timestamp, what else is there except to output the sub as stored?
[06:26:41] <ohsix> there can be several, its quite lame
[06:26:45] <jai> though i dont have a lot of ass
[06:26:55] <av500> jai: :)
[06:26:56] <jai> err, *media with ass streams
[06:27:17] <ohsix> do you want some? there are some xdcc bots with the "samples" wink wink, that i have
[06:27:33] <kshishkov> since MPlayer renders them as any other non-fancy text subtitles, what's the difference?
[06:27:57] <elenril> Warning: no style named '0:00:06.77' found
[06:28:06] <jai> Dark_Shikari: ah, I see audio input support for x264
[06:28:47] <jai> that would pose some competition for ffmpeg :)
[06:28:48] <kshishkov> jai: why, you don't like your audio encoded as H.264?
[06:28:55] <jai> kshishkov: lolwut
[06:29:08] <jai> they want vorbis and aac output support
[06:29:21] <kshishkov> and h.264 in ogg
[06:29:25] * drv encodes all his important documents with Theora, works better than a shredder
[06:29:33] * av500 wonders if x264 needs a dll codec wrapper too....
[06:30:00] <ohsix> hah, wild; they are really broken, lemme post a screen
[06:30:12] <kshishkov> av500: it will use once from lavc eventually ;)
[06:31:40] <av500> so I can use binary codecs in lavc by using x264 with a special flag :)
[06:32:40] <drv> x264 --install-windows
[06:33:20] <av500> x264 -i random.vid -o made_for_mozilla.ogg
[06:33:46] <drv> i doubt they'd like h.264 any better even if it were in ogg
[06:33:49] <ohsix> http://img715.imageshack.us/img715/913/bustedass.png
[06:33:54] <jai> x264 --subvert-ffmpeg
[06:34:10] <kshishkov> drv: tHeora.264 in Ogg then
[06:34:27] <elenril> ohsix: fail
[06:34:36] <ohsix> ya
[06:34:39] <av500> ohsix: and there is tearing too!
[06:34:43] <elenril> you didn't -ass
[06:34:45] <ohsix> dunno what that tear is
[06:34:54] <kshishkov> ohsix: looks like you also need to rename directory with those files
[06:35:23] <ohsix> hur [ass] [0x2517270] Warning: no style named '0:00:17.12' found, using 'Default'
[06:35:40] <ohsix> meh, its /media/9<tab>
[06:35:50] <ohsix> its one of the internal volumes without a label
[06:41:38] <thresh> morning
[06:42:48] <jai> moro
[06:43:22] <thresh> yes, sorry :(
[06:43:36] <jai> wat
[06:43:59] <kshishkov> something went wrong so it appears to be not so bad morning for thresh
[06:45:35] <av500> his kbd swallowed an "o"
[06:48:21] <kshishkov> taken by FSB to interrogation maybe
[06:53:42] <thresh> tsss.
[06:55:35] <av500> keylogger acting up
[06:56:08] <kshishkov> keystealer
[06:56:10] <thresh> every ISP in .ru has hw to monitor traffic for FSB
[06:56:20] <av500> and it works?
[06:56:30] <av500> it does not replay last month traffic like the cameras?
[06:56:32] <thresh> so that effectively makes you watched by FSB as well :)
[06:56:34] <kshishkov> in traditional Russian way
[06:56:38] <thresh> well, not quite sure
[06:56:44] * av500 waves at FSB
[07:02:54] <kshishkov> av500: just hope they don't have peering agreement with Stasi
[07:03:56] <votz> jai: ping
[07:04:11] <av500> kshishkov: I will ask my commanding officer :)
[08:13:56] <twnqx> 20603 charlie   20   0 6515M 5813M 1690M S 796. 36.1 16:40.86 blender -b ./production/scenes/0
[08:13:56] <twnqx> 20382 charlie   20   0 6543M 5919M 1755M S 785. 36.8 34:38.74 blender -b ./production/scenes/0
[08:14:03] <twnqx> so it is possible to run two blenders :P
[08:15:19] * twnqx needs to figure out tasksets to stop the threads from migrating to cpus further away from the memory
[08:17:08] <twnqx> meh, taskset can be used retroactively, but numactl can't...
[08:18:57] <jai> votz: pong
[08:29:19] * av500 reads Kalman, Hilbert and Wiener in the same patch....
[08:30:34] <twnqx> Wiener Würstchen?
[08:30:39] <kshishkov> av500: then it must to do something with matching filtration
[08:30:44] <kshishkov> and denoising
[09:27:54] <jai> btw, we should propose the halting problem for gsoc and see how many proposals we get :)
[09:29:13] <kshishkov> it seems to have to relation to FFmpeg
[09:30:06] <jai> i bet we'll still receive a huge bunch of proposals
[09:30:17] <kshishkov> so?
[09:30:37] <kshishkov> how it will benefit FFmpeg or can benefit at least?
[09:30:48] <jai> no way at all, its just funny
[09:31:54] <kshishkov> funny thing is ralf encoder
[09:32:15] <jai> O_O
[09:34:24] <kshishkov> or at least commit Flash Screen Video 2 encoder
[09:39:01] <pJok> goda morgonor, kshishkov :)
[09:39:50] <kshishkov> hej-hej
[09:42:46] <janneg> jai: as long as the qualification task for the halting problem is solving traveling salesperson problem in exponetial time it would be fine
[09:43:05] <jai> janneg: lol
[09:43:13] <kshishkov> janneg: even proving it can be done is enough ;)
[09:43:44] <av500> janneg: I guess it will not work on a 4GB machine though...
[09:44:01] <kshishkov> "FFmpeg 0.7 - powered by Improbability Drive"
[09:44:15] <pJok> infinite improbability drive
[09:44:17] <jai> > "I can't prove that an algorithm, but neither can michael" > Patch looks ok
[09:44:26] <jai> +exists
[09:44:40] <av500> kshishkov: with x264 gettings all the lavc/lavf features, I think we can reduce 0.8 to ffplay.c
[09:45:27] <janneg> jai: "neither micheal can disprove that an algorithm doesn't exists" patch ok
[09:45:40] <jai> :)
[09:46:54] <kshishkov> do something easier - like bugfree GCC for embedded platforms
[09:47:43] <pJok> why not just a bugfree gcc overall?
[09:47:47] <av500> and it is bugfree for non embedded?
[09:48:02] <twnqx> pJok: you'd need to make that a gsoc project first
[09:48:05] <kshishkov> it's less noticeable there
[09:48:26] <pJok> twnqx, i don't think $5k pay would be enough for that task ;)
[09:48:29] <av500> then better improve qemu to run x86 binaries on embedded :)
[09:48:30] <merbzt> we need more reasonable projects that people can do
[09:48:45] <kshishkov> ATRAC3+
[09:49:08] <merbzt> yeah, that can be added
[09:49:16] * av500 saw a minidisk player for sale in berlin 2mo ago...
[09:49:33] <kshishkov> av500: you can still buy record players here I think
[09:49:54] <twnqx> i wonder if i should get one or two of the last technics DJ players
[09:49:56] <kshishkov> merbzt: have they finished REing bitstream format?
[09:50:06] <av500> kshishkov: that I can understand more acually :)
[09:50:06] <merbzt> don't think so
[09:55:06] <kshishkov> av500: BTW, soon it will be 325th anniversary of The Composer's birthday. Any preparations in Germany?
[09:56:53] <av500> 2 of them actually
[09:57:32] <kshishkov> 2 of what?
[09:57:49] <janneg> birthdays?
[09:58:01] <kshishkov> could be
[09:58:09] <av500> händel too
[09:58:09] <kshishkov> 21th/31th old/new style
[09:59:01] <kshishkov> it should have been celebrated by now
[09:59:57] <av500> they did not invite me
[10:00:07] <av500> but there is/was stuff: http://www.google.com/search?as_q=bach+325&lr=lang_de
[10:01:10] * kshishkov remembers hearing nothing about celebrating 200th birthday of Gogol at Ukraine last year.
[10:01:46] <superdump> kshishkov: <anything>-first is abbreviated <anything>1st
[10:02:16] <superdump> and 2nd, 3rd
[10:02:26] <superdump> but the rest are th, i think
[10:02:39] <twnqx> yes indeed
[10:02:58] <thresh> 11st
[10:03:00] <thresh> ;P
[10:03:16] <twnqx> eleventh, it's not ten-first
[10:04:36] * pJok hands Arthur_Dent a cup of tea
[10:05:01] <jai> hello pJok :)
[10:05:15] <pJok> afternoon jai :)
[10:32:31] <tborg> Do we have a pendant to get_unary() somewhere in libavcodec?
[10:39:38] <astrange> a which?
[10:42:37] <tborg> me? in other words: a counterpart to get_unary()
[10:43:04] <tborg> something better than put_sbits(.., n, ~0) (if that would work...)
[10:46:10] <kshishkov> superdump: yes, that's what you got without thinking first. It's still better than "2rd floor" though
[10:48:23] <kshishkov> s/got/get/
[10:48:24] <superdump> :)
[10:48:51] <MrNaz_out> hey i work on the 2rd floor
[10:48:54] <superdump> yeah, 11th, 12th, 13th are special
[10:49:45] <kshishkov> unless it's tenty-first, tenty-second and tenty-third
[10:50:08] <kshishkov> (could happen after language reform in USA I think)
[10:50:17] <superdump> :)
[10:50:33] <MrNaz_out> language reform in the USA? i think that'd involve just discarding half of the vocabulary
[10:50:38] <MrNaz_out> "you're" would go first
[10:50:45] <av500> ur
[10:50:48] <MrNaz_out> followed by "they're"
[10:50:51] <kshishkov> y'all
[10:51:05] <MrNaz_out> and their
[10:51:07] <selves> hello, I am new to ffmpeg, actually i need to use ffplay to play my media content.. I am getting the media content through streaming in bytes chunks.so either I can save the bytes to a file and then play the file through ffplay. but I need to input the bytes every time I receive it.. can any body tell me how I can implement this.or where to start from?? thanks
[10:51:41] <av500> -> #ffmpeg
[10:52:18] <kshishkov> MrNaz_out: Americans misspell worlds like "colour" and "centre" already
[11:44:22] <KotH> ---
[11:44:24] <KotH> Hi,
[11:44:24] <KotH> This is a very nice collection of various media files.
[11:44:24] <KotH> I think I'll need it all.
[11:44:26] <KotH> ---
[11:44:42] <twnqx> lol
[11:44:44] <kshishkov> pokemons.mplayerhq.hu?
[11:55:54] <astrange> who wants to write get_cabac() for arm? it might be useful
[11:56:40] <kshishkov> look into mru direction
[12:52:09] <twnqx> heh
[12:52:16] <twnqx> nodelocking blender wasn't the best idea :P
[12:52:52] <twnqx> poor thing was oom killed :(
[12:54:14] <KotH> join the club
[12:54:38] <mru> hey, you guys are lucky
[12:54:46] <mru> it *killed* my quadcore
[12:55:02] <twnqx> how's that even possible?
[12:55:12] <av500> killed the I7?
[12:55:35] <merbzt> so a 4gb machine wont do it ?
[12:55:45] <twnqx> that node had 8G...
[12:56:00] <twnqx> well. has.
[12:56:09] <merbzt> omg :(
[12:56:23] <merbzt> is it caused by the resolution ?
[12:56:41] <twnqx> guess i'll put it on the list of rerenders without nodelocking
[12:56:55] * janneg hasn't seen a single oom since the upgrade to 6G
[12:57:01] <merbzt> ok
[12:57:41] <janneg> merbzt: only partially, most of the memory seems to be used for scene data
[12:58:33] <janneg> i.e. it doesn't use much less memory to render at cif
[12:58:42] <mru> av500: no, not the i7
[12:58:42] <merbzt> is it only one segment that is buggy ?
[12:58:50] <mru> it killed the old c2q
[12:58:54] <av500> ah
[12:58:57] <twnqx> physically?
[12:58:58] <av500> mercy killing
[12:59:00] <mru> just tried again, doesn't boot
[12:59:03] <twnqx> wow
[12:59:05] <twnqx> bad fan?
[12:59:05] <mru> not even the bios screen
[12:59:18] <merbzt> mru: blown caps ?
[12:59:28] <mru> I'll have to open it and check
[12:59:44] <merbzt> I revived 2 c2d at work with
[12:59:47] <merbzt> blown caps
[13:00:02] <twnqx> on the mobo?
[13:00:13] <twnqx> or on the cpu? :>
[13:00:19] <mru> the c2 has thermal protection, right?
[13:00:28] <twnqx> afaik yes, though i never triggered it
[13:00:30] <merbzt> yes
[13:00:39] <twnqx> the c2d here in the laptop hits ~90°C
[13:00:42] <merbzt> intel has since the p3 afaik
[13:00:53] <mru> so even with bad cooling, it wouldn't toast the cpu permanently
[13:00:59] <av500> should not
[13:01:00] <merbzt> twnqx: on the mobo
[13:01:15] <merbzt> mru: should just lockup
[13:01:26] <mru> but not permanently...
[13:01:34] <mru> as in after cooloff and reboot
[13:01:37] <merbzt> yes
[13:01:51] <twnqx> don't they just throttle?
[13:01:57] <merbzt> does the box (fans, harddrive) start ?
[13:02:18] <mru> fans start, and some LEDs light up
[13:02:23] <mru> vga stays dead
[13:02:28] <merbzt> ok, blown cap then
[13:02:30] <mru> kbd too
[13:02:33] <twnqx> no beeps from the speaker?
[13:02:42] <mru> it never beeped
[13:02:55] <merbzt> the 2 I fixed din't beep either
[13:02:55] <av500> speaker coupling cap also dead :)
[13:03:19] <merbzt> but started enough to light some leds and spin the fan
[13:03:52] <mru> I'll open it and have a look later
[13:04:25] <merbzt> the cap farads just need to be close enough
[13:04:32] <twnqx> and low esr
[13:04:33] <merbzt> voltage the same or higher
[13:05:31] <mru> I know how filter capacitors work
[13:05:45] <twnqx> those usually aren't really filters :P
[13:05:56] <mru> not in the audio sense, no
[13:06:09] <twnqx> also not in the voltage stabilization sense
[13:06:20] <twnqx> more like parts of the charge pumps
[13:06:39] <mru> I don't know yet what's dead
[13:06:55] <twnqx> let's hope it's just some caps
[13:08:04] <twnqx> hm
[13:08:13] <twnqx> process stays below 6G
[13:08:19] <twnqx> why was it OOMed :S
[13:09:31] <ramiro> twnqx: maybe you should close firefox and google earth =)
[13:09:47] <twnqx> that things doesn't even have X running
[13:09:50] <twnqx> thing*
[13:10:06] <ramiro> wow, google earth through libcaca? nice...
[13:10:12] <twnqx> :P
[13:10:21] <ramiro> that would be funny actually
[13:10:27] <twnqx> that would be something to to actually
[13:10:35] <twnqx> "Xcaca"
[13:10:50] <twnqx> world's first textmode X server
[13:12:12] <twnqx> hm, completed now without OOM
[13:12:14] <twnqx> funny
[13:14:07] <twnqx> rendering time is about 1:15h cpu time... fer frame
[13:14:13] <twnqx> per*
[13:14:27] <twnqx> we should get michael to optimize blender :P
[13:18:52] <janneg> rendering time differs wildly, from 5 minutes to over 1 hour real time on a quadcore
[13:19:35] <twnqx> so i got all the hard scenes? :P
[13:21:28] <janneg> seems so
[13:24:52] <merbzt> janneg: have you talked to the peach guys about the broken scenes ?
[13:32:37] <janneg> no, it's imho too funny. but it would a nice thing to do
[13:33:18] <av500> wasnt the plan to replace the eyes with zigzag logo? :)
[13:36:05] <twnqx> wtf
[13:36:20] <twnqx> i'm trying to redo an order at digikey it did half a year ago
[13:36:28] <twnqx> NONE of the components are in stock :S
[13:36:34] <av500> :)
[13:36:56] <av500> companies dropped a lot of stock during the "recession"...
[13:37:07] <av500> and manufs stopped a lot of production
[13:37:30] <twnqx> estimated shipping date... 20.05.2010
[13:37:32] <twnqx> THANK YOU
[13:38:19] <av500> YOURE WELCOME
[13:39:21] <av500> twnqx: what parts are you after?
[13:39:36] <KotH> twnqx: that's nomral
[13:39:50] <twnqx> but i can't even place an order :X
[13:39:55] <twnqx> like "ship when you got it"
[13:40:21] <twnqx> av500: stepdown voltage regulators, bus tranceivers
[13:40:49] <twnqx> hm, they have the 1.2V stepdown regulators
[13:40:52] <av500> no alternatives?
[13:40:53] <twnqx> 32 pieces left :S
[13:41:01] <twnqx> well.. i have the PCBs....
[13:41:23] <twnqx> no fitting alternatives
[13:43:22] <twnqx> hm avnet has stock...
[13:43:29] <twnqx> do they even have an online shop for germany
[13:43:53] <av500> maybe some downstream distri
[13:43:55] <av500> of them
[13:43:56] <KotH> twnqx: we've the same prob with nearly everythng that is not 100% 0815
[13:44:11] <twnqx> av500: do you know any? :X
[13:44:17] <av500> EBV
[13:44:18] <KotH> twnqx: all manufacturers closed fabs and now can't get up to speed with production
[13:44:36] <twnqx> and keep in mind, i don't want to buy full reels :P
[13:44:50] <av500> well, there arent any anyway :)
[13:45:27] <twnqx> not in stock with digikey, no.
[13:45:48] <av500> try speorle
[13:45:52] <av500> err spoerle
[13:46:09] <twnqx> hm
[13:46:21] <twnqx> EBV has 0 stock as well
[13:46:38] <KotH> findchips.com?
[13:46:50] <av500> chinese spot market ftw!
[13:47:04] <twnqx> spoerle has 0 stock as well :P
[13:47:11] <av500> reichelt?
[13:47:15] <twnqx> nah, the point is i don't care if delivery takes 2 months
[13:47:18] <twnqx> lol reichelt
[13:47:23] <av500> reichelt is not bad
[13:47:34] <av500> they are not dk of course
[13:47:36] <twnqx> for the parts i'm after they are :P
[13:49:18] <twnqx> TPS62205DBVT, TPS62207DBVT, SN74CB3T16210DGVR
[13:49:36] <twnqx> and those are the first three i tried :X
[13:50:31] <av500> thats all TI stuff
[13:50:36] <twnqx> yes.
[13:50:39] <av500> TI shutdown a lot mid last year
[13:50:51] <av500> that is the fallout
[13:51:02] <twnqx> yeah, some are already late for delivery to digikey even
[13:51:23] <av500> I guess you need to order a lot of free Maxim samples :)
[13:51:57] <twnqx> well.. are they pin compatible? :X
[13:52:31] <twnqx> XC3S250E-4VQG100C weee xilinx is available
[13:53:23] <av500> \o/
[13:58:39] <twnqx> so it really is a TI problem... gah
[13:58:53] <av500> not only
[13:59:10] <av500> industry is full of it If I am to believe free trade magazines...
[13:59:34] <nfl> jai: are u there?
[13:59:44] <twnqx> CSX325FHC48.000M-UT <- also not available
[14:00:04] <twnqx> but maybe, just maybe, there's a replacement part...
[14:00:39] <jai> nfl: yeah
[14:00:46] <nfl> jai: can i pm you?
[14:01:08] <jai> nfl: k
[14:46:24] <superdump> merbzt: do you know what the missing features in the qcelp decoder are?
[14:46:35] <superdump> i've been marked as a mentor for it but i don't know what's missing
[14:46:43] <superdump> i thought reynaldo had finished the postfilters
[14:46:48] <superdump> so it's done afaik
[14:47:16] <superdump> and why is there "Write or improve WB spec"?
[14:48:02] <BBB> because the spec for NB sucked
[14:48:08] <BBB> so they rewrote it
[14:48:16] <BBB> I think the qcelp task can be removed
[14:48:20] <BBB> I wasn't sure what it meant either
[14:48:39] <merbzt> superdump: post filter afaik
[14:48:53] <superdump> i thought that was done
[14:49:00] <merbzt> might have been
[14:49:01] <superdump> BBB: you mean i rewrote it ;)
[14:49:05] <merbzt> I don't remember
[14:49:12] <BBB> oh yes it was you
[14:49:13] <superdump> we can check
[14:49:15] <BBB> so WB same thing
[14:49:17] <BBB> you should know :)
[14:49:19] <superdump> it's the tilt/blah filter
[14:49:31] <superdump> BBB: well, i don't think it will be so bad now i've done it once
[14:49:35] <merbzt> superdump: no no, lets inestead argue on the internet
[14:49:47] <superdump> lol
[14:50:54] <merbzt> 2 crap keyboards or a broken usb hub...
[14:52:44] <twnqx> mh?
[14:55:31] <merbzt> I get misstrokes and key repeatings on 2 different keyboards connected to this computer
[14:55:43] <av500> keylogger acting up?
[14:55:51] <merbzt> must be
[14:56:09] <merbzt> it's all connected to a crap monitor hub
[14:56:22] <merbzt> guess it is the weak link
[14:57:28] <KotH> the bus is only as strong as its weakest hub!
[14:57:54] <av500> I once had a monitor with a hub, 2port, usb1
[14:58:02] <av500> it was obsolete before it was designed...
[14:59:04] <merbzt> would work for a keyboard and a mice
[14:59:26] <av500> youcan see how well it works for you :)
[15:03:24] <pJok> a shame ffmpeg doesn't support -r for specifying the framerate for a non-raw format :/
[15:06:16] <superdump> agreed
[15:26:07] * pJok blames jai
[15:30:38] <jai> pJok: wut :)
[15:31:28] <pJok> 16:03 < pJok> a shame ffmpeg doesn't support -r for specifying the framerate for a non-raw format :/
[15:31:53] <kshishkov> blame demuxers setting it
[15:32:34] <av500> option could override it :)
[15:32:47] <merbzt> av500: add it to the small task page
[15:32:56] <av500> or send a patch? :)
[15:33:23] <merbzt> that is an option also
[15:34:11] <av500> override per default?
[15:34:17] <kshishkov> or better yet, add some feature to apply options _after_ everything was set up but before decoding start
[15:34:29] <av500> or new option -r_i_mean_it
[15:34:32] <kshishkov> so you can totally override crappy settings in AVI for example
[16:09:27] <jai> j0sh: good work so far :)
[16:09:38] <j0sh> thanks
[16:12:50] <kshishkov> what work?
[16:13:36] <jai> theora depayloader
[16:14:02] <kshishkov> ah
[16:14:11] <wbs> j0sh: yeah, it looks quite good :-)
[16:14:24] <wbs> j0sh: care to make a payloader, too, to keep things symmetric? :-)
[16:14:31] <wbs> what gsoc task were you aiming at, btw?
[16:15:22] <kshishkov> wbs: any position on replacing lavf rtmp proto with rtmpdump?
[16:16:55] <wbs> kshishkov: well, if it's easy to compile, it's ok for me... but librtmp isn't generally packaged in distros yet afaik
[16:17:20] <kshishkov> well, it will be outdated even before release
[16:17:26] <wbs> true
[16:17:29] <kshishkov> RTMP is too mutable
[16:18:07] <j0sh> wbs, i was thinking rtsp
[16:18:23] <wbs> j0sh: ok, what more specifically?
[16:18:31] <wbs> (haven't read the gsoc page for a while)
[16:18:35] <BBB> there's a general rtsp task
[16:18:42] <wbs> ah, ok
[16:18:42] <j0sh> minor improvements, looks like
[16:18:45] <BBB> implement several missing rtp depayloaders
[16:18:51] <BBB> add http transport support (apple)
[16:18:57] <wbs> ah
[16:19:04] <BBB> maybe port vlc to use ffmpeg's rtsp stack
[16:19:09] <wbs> bbl, but please continue the discussion :-)
[16:19:12] <BBB> (as primary/default, over others)
[16:19:59] <j0sh> that sounds good, i could do a theora payloader too as wbs suggested
[16:20:41] <BBB> it's really up to you
[16:20:44] <BBB> the task is relatively free
[16:20:51] <BBB> I'd recommend that you don't make it too small
[16:20:59] <BBB> so don't say "I'll implement 3 depayloaders and 1 payloader"
[16:21:21] <BBB> make it a bigger-picture thing, so something that you could hopefully grow into, if you're for example interested in staying on and continuing to work on it after the end of GSoC
[16:21:53] <BBB> hence the VLC task (which would really pu you in between the two projects, could be interesting) and also the apple/http transport, which might also mean you have to implement the currently-missing x-qt/x-quicktime payload
[16:21:58] <j0sh> yeah i would like to keep contributing.. the gsoc tasks sound ambitious enough
[16:22:09] <BBB> I wrote a patch for that once but it's a little dusty
[16:22:17] <j0sh> although i havent used ffmpeg's rtsp enough to have an idea of what else could to be done
[16:22:42] <kshishkov> j0sh: in previous years some people managed to do them, so mentors just raised level a bit
[16:22:57] <kshishkov> s/to do/to complete in time/
[16:23:25] <j0sh> so the goal is make it hard enough not to finish
[16:23:46] <j0sh> so th students will stick around and continue contributing? ;)
[16:23:49] <mru> the goal is to have a moving goal
[16:23:55] <kshishkov> gsoc is only for summer, FFmpeg is for life ;)
[16:24:22] <j0sh> heh
[16:25:48] <kshishkov> for example, one guy here failed his first task, then completed task from another guy and stayed here as a developer
[16:26:07] <kshishkov> or look at jai
[16:26:25] <kshishkov> started with gsoc two? years ago, still here
[16:26:26] <j0sh> yeah i failed to optimize h264, michael send out an email about low hanging h264 fruits
[16:26:44] <mru> low is a relative measure
[16:26:49] <kshishkov> heh, those are low-hanging coconuts
[16:26:59] <kshishkov> (carried by laden African swallow)
[16:27:55] <j0sh> heh oh well, i still learned from it... i could post what i have for h264 on the ML in case someone else wants to pick it up
[16:28:20] <j0sh> the problem was the CRCs are off, otherwise videos decode fine
[16:28:31] <jai> kshishkov: heh
[16:29:37] <jai> j0sh: how much speedup are we talking?
[16:29:47] <kshishkov> j0sh: wrong CRC means you've screwed something
[16:30:03] <j0sh> yeah, i didnt benchmark yet caus the crcs weren't perfect
[16:30:44] <j0sh> i was working on was for 16x8 and 8x16 temporal direct prediction, btw
[16:33:10] <j0sh> BBB, is "-vcodec copy" supposed to work when decoding from rtsp? it's not doing anything for me, just hangs
[16:33:32] <BBB> not sure
[16:33:33] <BBB> ..
[16:33:38] <BBB> does it work for theora files?
[16:33:55] <jai> if it doesnt then its a bug :)
[16:33:56] <j0sh> no, it actually gets sent through libtheora and re-encodes
[16:34:13] <j0sh> (i think)
[16:35:17] <BBB> that  would be surprising
[16:35:18] <BBB> and a bug
[16:35:26] <gangil> merbzt: Hi , did I list the steps correctly in the mail I sent you after the discussion ?
[16:35:28] <BBB> btu sounds like a bug
[16:35:41] <BBB> feel free to submit an issue tracker entry for now
[16:35:50] <merbzt> gangil: yes, I forgot to reply
[16:35:55] <BBB> I have some other stuff to do so can't look at it right now
[16:36:00] <BBB> GSoC is on the homepage now
[16:36:07] <merbzt> gangil: before you do anything. talk to BBB and kostya
[16:36:20] <merbzt> will save you a few days of work :)
[16:36:55] <gangil> merbzt: sure :)
[16:37:02] <BBB> talk to kostya ;)
[16:37:07] <BBB> he knows more than me
[16:37:12] <j0sh> BBB, alright will submit as a bug, will also try to investigate once the depayloader is done
[16:37:13] <kshishkov> merbzt: and actually it's they who save me days of work :)
[16:37:16] <BBB> in fact, he's straight scary
[16:37:40] <BBB> j0sh: I'll review the patch later today, poke me if I haven't done it in 2-3hrs
[16:37:54] <j0sh> will do
[16:39:31] <gangil> is kostya in the channel right now ? (just wanted to know , I dont see anyone by this nick  :-/)
[16:39:49] <jai> kostya == kshishkov
[16:40:35] <gangil> ah! sorry didnt know that :)
[16:41:04] <kshishkov> I have some others names too ;)
[16:41:15] <andoma> gangil: no! We must ban you from this channel for all time now!
[16:41:27] <lu_zero> uhm
[16:41:30] <lu_zero> now I'm around
[16:41:47] <gangil> andoma: ?
[16:42:17] <mru> /ban gangil <-- like that
[16:42:18] <jai> your sarcasm detector needs patching :)
[16:42:34] <BBB> lu_zero, you should review that rtsp patch
[16:43:10] <kshishkov> jai: maybe it was turned off because of constant blinking
[16:43:26] <jai> heh
[16:43:51] <j0sh> BBB, lu_zero: i have a new one coming shortly
[16:44:17] <BBB> so I shouldn't review this one?
[16:44:19] <BBB> I'll do it anyway
[16:44:22] <BBB> give me a sec
[16:44:37] <merbzt> gangil: valgrind with callgrid might be usable to find out what functions are called in a binary
[16:45:33] <j0sh> BBB, alright, i addressed most of the issues that were mentioned
[16:50:57] * BBB goes for lunch
[16:50:58] <BBB> review sent
[16:52:22] <lu_zero> BBB: the website doesn't show much
[16:52:27] <lu_zero> or I'm mislead?
[16:52:30] <BBB> ?
[16:52:40] <BBB> which?
[16:53:26] <lu_zero> the gsoc one
[16:53:59] <BBB> link?
[16:54:07] <lu_zero> I cannot register anyway
[16:54:34] <BBB> http://socghop.appspot.com/gsoc/org/apply_mentor/google/gsoc2010
[16:54:57] <lu_zero> where is that link?
[16:55:05] <lu_zero> found
[16:55:09] <lu_zero> last one ...
[16:56:12] <lu_zero> done =E
[16:56:32] <lu_zero> BBB: do you have an rtsp url that redirects?
[16:56:44] * lu_zero doesn't recall which was the one he was using to test stuff
[16:56:50] <BBB> no
[17:44:44] <j0sh> is "if(!avfunc(..))" an effective catchall for averror?
[17:49:03] <j0sh> nvm
[17:53:25] <CIA-92> libswscale: cehoyos * r30934 /trunk/libswscale/ (utils.c swscale.c):
[17:53:25] <CIA-92> libswscale: Extend the generic path of the yuv2rgb converter with support for rgb444
[17:53:25] <CIA-92> libswscale: output format.
[17:53:25] <CIA-92> libswscale: Patch by Janusz Krzysztofik, jkrzyszt A tis D icnet D pl
[17:53:26] <CIA-92> ffmpeg: stefano * r22586 /trunk/ (13 files in 4 dirs):
[17:53:26] <CIA-92> ffmpeg: Add some ad-hoc tests for libavfilter.
[17:53:39] <CIA-92> ffmpeg: A patched version of ffmpeg supporting video filters is required for
[17:53:39] <CIA-92> ffmpeg: getting this working; thus make lavfitest is supposed to work only in
[17:53:39] <CIA-92> ffmpeg: the libavfilter repository for now.
[17:54:04] <elenril> what's keeping lavfi from getting merged?
[17:55:48] <mru> you
[17:56:39] * elenril throws http://tvtropes.org/pmwiki/pmwiki.php/Main/InsaneTrollLogic at mru 
[17:57:36] <kierank> throw it as xiph as well
[17:57:44] <kierank> at*
[18:07:36] <jai> poor xiph
[18:31:34] <j0sh> BBB, im looking at using the url_dyn_buf stuff... im wondering if it's more overhead because we're not reusing the buffer space after each packet?
[18:31:48] <BBB> j0sh: we can optimize dyn_buf for that later
[18:32:00] <BBB> the amount of code needed will get smaller
[18:32:30] <j0sh> ok
[18:32:43] <BBB> in fact, we could make that part of your SoC project if you like
[18:32:54] <BBB> again, up to you, millions of possibilities
[18:34:12] <j0sh> alright cool
[18:35:08] <elenril> do i need to bump anything when adding a new public func?
[18:36:00] <kshishkov> minor version IIRC
[18:37:48] <jai> yep
[18:38:00] <jai> elenril: moar metadata i guess
[18:39:40] <elenril> no, chapters
[18:39:56] <elenril> otoh chapters are probably metadata too
[18:41:10] * elenril should learn something about video coding
[18:41:47] <kierank> write me an api for per packet metadata ;)
[18:42:19] <elenril> why would you need something like that
[18:42:45] <kierank> because dolby e has per packet metadata
[18:43:01] <elenril> "this packet's name is Marisa and that other one is Alice"?
[18:43:02] <jai> wow, thats insane
[18:43:45] <jai> elenril: and we lost Bob on the wire
[18:43:47] <kshishkov> it's not metadata, it's packet extradata :|
[18:43:49] <elenril> kierank: can't you just ignore it?
[18:44:12] <kshishkov> he can
[18:44:21] <kierank> what's the difference between metadata and extradata?
[18:44:30] <kierank> but that data is fundamental to the foramt
[18:44:39] <kierank> format*
[18:45:54] <kshishkov> extradata is essential, metadata is just some silly descriptions of data
[18:47:15] * elenril is deeply hurt
[18:47:32] <kierank> then by that definition it's metadata in dobly e
[18:47:34] <kierank> dolby*
[18:47:59] <kshishkov> no, it's decoder hints
[18:48:40] <kierank> you can decode the audio without it
[18:48:49] <kierank> it's hints for the encoder afterwards
[18:49:05] <kshishkov> it's part of bitstream
[18:49:37] <kshishkov> just ignore it as our AC3 decoder does
[18:50:14] <kierank> it's an half the format's use case imo. it would be like decoding video without chroma
[18:50:46] <kshishkov> for me it's like cake without GLaDOS
[18:51:29] <elenril> <obvious statement about cake's existence here>
[18:52:42] <kshishkov> kierank: it's useless when data is processed. And for specific case you may try to write bitstream filter e_to_3
[18:53:31] <kierank> it's not useless if you were using dolby e in the real-world
[18:54:00] <kierank> and dolby e doesn't have to go to ac3, it can go to aac or he-aac
[18:54:19] <kshishkov> oh yeah, store that data in AAC bitstream!
[18:54:35] <kierank> that is what dolby have done with dolby pulse
[18:55:51] * kshishkov is probably glad to not hear about it
[19:00:36] * elenril wonders why av_rescale_q(INT64_MAX) returns a negative number
[19:01:53] <kshishkov> input was not positive?
[19:02:07] <elenril> INT64_MAX
[19:02:07] <kshishkov> look at the code
[19:03:03] <kshishkov> probably it overflows in rescaling
[19:03:33] <elenril> don't av_rescale_* funcs exist to avoid that?
[19:04:01] <kshishkov> what are other inputs?
[19:04:24] <elenril> from miliseconds to nanoseconds
[19:04:49] <elenril> yeah, it overflows
[19:04:59] <Dark_Shikari> under what conditions will configure generate .pc files?
[19:05:00] <elenril> but i'd expect it to handle that
[19:05:01] <Dark_Shikari> I can't make it do it
[19:07:10] <kshishkov> --enable-shared?
[19:07:30] <Dark_Shikari> ok, so it's generating them but I can't figure out where it's installing them
[19:07:38] <Dark_Shikari> INSTALL libavformat/libavformat.pc
[19:07:42] <Dark_Shikari> what does this do?  I have no idea.
[19:07:50] <Dark_Shikari> it certainly doesn't put them in /usr/share/pkgconfig
[19:07:57] <kshishkov> look at prefix
[19:07:58] <janneg> make V=1 install
[19:08:08] <kshishkov> probably /usr/local/share/pkgconfig
[19:08:40] <Dark_Shikari> ah cool, V=1
[19:23:37] * peloverde wonders why the math in the PS spec is informal to the point of ambiguity
[19:24:01] <CIA-92> ffmpeg: stefano * r22586 /trunk/ (13 files in 4 dirs):
[19:24:01] <CIA-92> ffmpeg: Add some ad-hoc tests for libavfilter.
[19:24:01] <CIA-92> ffmpeg: A patched version of ffmpeg supporting video filters is required for
[19:24:01] <CIA-92> ffmpeg: getting this working; thus make lavfitest is supposed to work only in
[19:24:01] <CIA-92> ffmpeg: the libavfilter repository for now.
[19:24:02] <CIA-92> ffmpeg: stefano * r22587 /trunk/tests/lavfi-regression.sh:
[19:24:03] <CIA-92> ffmpeg: Make ad-hoc lavfi tests use random values for the slice height used
[19:24:03] <CIA-92> ffmpeg: per each frame, useful for testing slicification.
[19:24:04] <CIA-92> ffmpeg: stefano * r22588 /trunk/ (doc/ffplay-doc.texi ffplay.c):
[19:24:04] <CIA-92> ffmpeg: Add a -window_title option, which sets the FFplay window title.
[19:24:05] <CIA-92> ffmpeg: Patch by Robert Kr?ger "krueger ET signal7 DOT de".
[19:24:05] <CIA-92> ffmpeg: stefano * r22589 /trunk/cmdutils.c:
[19:24:06] <CIA-92> ffmpeg: Remove printing of frame sizes and frame rate abbreviations from
[19:24:06] <CIA-92> ffmpeg: show_protocols().
[19:24:07] <CIA-92> ffmpeg: The list of abbreviations is both outdated and out of context.
[19:24:08] <CIA-92> ffmpeg: stefano * r22590 /trunk/libavformat/aviobuf.c:
[19:24:20] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik foo=zyszt <jkr$foo at tis.icnet.pl>.
[19:24:21] <CIA-92> ffmpeg: benoit * r22598 /trunk/ffmpeg.c:
[19:24:21] <CIA-92> ffmpeg: ffmpeg.c: copy chapters by default.
[19:24:21] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com
[19:24:22] <CIA-92> ffmpeg: mru * r22599 /trunk/ffmpeg.c: Register atexit handler only when needed
[19:25:55] <CIA-92> libswscale: cehoyos * r30934 /trunk/libswscale/ (utils.c swscale.c):
[19:25:56] <CIA-92> libswscale: Extend the generic path of the yuv2rgb converter with support for rgb444
[19:25:56] <CIA-92> libswscale: output format.
[19:25:56] <CIA-92> libswscale: Patch by Janusz Krzysztofik, jkrzyszt A tis D icnet D pl
[19:25:56] <CIA-92> libswscale: diego * r30937 /trunk/libswscale/swscale.c:
[19:25:56] <CIA-92> libswscale: Check whether COMPILE_ALTIVEC is defined, not if it is set to a 0/1 value.
[19:25:57] <CIA-92> libswscale: COMPILE_ALTIVEC is never set to 1, it is just #defined.
[19:25:57] <CIA-92> libswscale: diego * r30938 /trunk/libswscale/swscale_template.c: Replace wrong condition name in #endif comment by correct instance.
[19:29:11] <kierank> peloverde: because it's a spec
[19:29:29] <kierank> on the one hand it tries to define everything ever so precisely yet in other situations just messes it up
[19:38:12] <j0sh> BBB, about the dyn_url stuff... when i do a put_buffer, it flushes to *somewhere* after a certain size. how do i recover my original data?
[19:40:41] <peloverde> Reddit boggles my mind... what does "Mozilla: Stick to Your Ideals, Shun H.264" have to do with Linux?
[19:41:24] <elenril> obviously all linux users are freetards who hate h.264
[19:42:00] <j0sh> BBB, close_dyn_buf?
[19:43:53] <iive> elenril: i guess you are not linux user
[19:44:31] <elenril> iive: http://tvtropes.org/pmwiki/pmwiki.php/Main/SarcasmFailure
[19:44:44] <peloverde> I use linux and I think a few others here do, anyway codec choice for HTML5 seems completely disjoint form the topic of "Linux"
[19:50:38] <iive> yep, don't forget that the best h264 decoder and the best x264 encoder are free GPL native linux programs, that also work in other OS-es
[19:56:54] <elenril> decoder? i hear coreavc is much faster than ffh264
[19:58:52] <BBB> j0sh: yes
[20:00:47] <iive> elenril: old news :P
[20:01:30] <j0sh> BBB, yup got it... figures, after an hour of figuring out the dyn_buf api, i got it 30 seconds after asking :)
[20:02:26] <j0sh> BBB, im also going to submit a separate patch in the same thread refactoring out similarities with vorbis, that OK?
[20:02:46] <Kovensky> <@Dark_Shikari> it certainly doesn't put them in /usr/share/pkgconfig <@kshishkov> probably /usr/local/share/pkgconfig <-- $prefix/lib/pkgconfig is the correct path
[20:03:27] <Kovensky> <iive> yep, don't forget that the best h264 decoder and the best x264 encoder are free GPL native linux programs, that also work in other OS-es <-- x264 encodes x264 video? :o
[20:04:08] <pJok> x264 is the new format
[20:04:10] <iive> Kovensky: don't twist my twist.
[20:04:19] <pJok> its better than h264 because it has an x instead of an h
[20:04:53] <jai> pJok: you should be in marketing ;)
[20:05:23] <pJok> jai, i shouldn't...
[20:05:40] <pJok> i would just stab the other marketing people with pencils
[20:08:23] <jai> :)
[20:10:02] <BBB> j0sh: of corudse
[20:10:15] <BBB> j0sh: I would've been ok with that afterwards also, but if you want to do it before, that's great
[20:10:26] <BBB> anything decreasing amount of code is ok
[20:10:52] <j0sh> is there private common code somewhere? utils.c is all public
[20:11:07] <BBB> anything ff_* is private
[20:11:20] <BBB> you can make it rtp_xiph.c if you want
[20:11:51] <j0sh> ok
[20:13:52] <hyc1> what is the point to keeping the old rtmp implementation? it's incomplete. When is it ever going to be useful to have it around at the same time as the new one?
[20:19:30] <thresh> grievening
[20:29:43] <j0sh> BBB, looks like the vorbis refactoring will have to wait until the weekend, but i'm submitting an updated patch shortly
[20:42:58] <Compn> hyc : ffmpeg rtmp works with red5 or whatever it was tested with, so it does work...
[20:49:58] <hyc> Compn: ok
[20:50:08] <hyc> still, it hangs on some other servers
[20:50:55] <hyc> if it wasreliably usable, that'd be great. but since it's not, and it's not being actively maintained, and it's missing features...
[20:51:32] <hyc> it's not like I have any particular reason to be pushy, I just don't like to wait
[20:52:42] <Compn> well michael said he wanted native rtmp to stick around if librtmp was added
[20:52:49] <Compn> so best to agree with him :)
[20:53:01] <j0sh> wbs, BBB, just sent a updated patch to the ML. thanks for the help!
[20:53:08] <Compn> if you wanted it to be added that is
[20:53:30] <hyc> Compn: yeah, fine.
[20:53:51] <hyc> I think I already made my point. it's only going to cause confusion.
[20:54:09] <Compn> quite
[20:58:08] <hyc> meanwhile I've got it working in xbmc now
[20:58:30] <hyc> xbmc also has libavformat. could cut down some size by just using a single implementation
[20:59:24] <hyc> but the API still needs to be extended to handle time-based seeks better
[20:59:39] <hyc> xbmc's native code does that OK
[20:59:51] <hyc> even though they use the lavf flv demux
[20:59:59] <hyc> still trying to figure out why that works...
[21:02:09] <BBB> hyc: because we prefer having something in?
[21:02:41] <BBB> and inactive maintenance is a chance for you to contribute to one of the greatest free software projects :)
[21:04:18] <hyc> BBB: I've already contributed
[21:04:56] <hyc> and I'd rather spend my time working on expanding the feature set (e.g., getting seek working consistently)
[21:05:06] <hyc> than rehashing old code
[21:05:30] <BBB> like I said before, ffmpeg is not a libXY wrapper toolkit
[21:05:44] <BBB> ffmpeg integrates multimedia functionality
[21:05:51] <BBB> submit rtmpe into ffmpeg
[21:06:18] <hyc> BBB: adding rtmpe to the existing ffmpeg code would be a waste of time
[21:06:28] <bcoudurier> too bad
[21:06:47] <bcoudurier> I agree with michael
[21:07:00] <hyc> librtmp is already a complete superset of the existing code
[21:07:00] <bcoudurier> and I'd prefer the native code to be improved
[21:07:11] <bcoudurier> https would be a nice feature also
[21:07:30] <bcoudurier> we do not like external dependencies much
[21:07:42] <hyc> you can all do what you prefer. but clearly the lead maintainer isn't spending any time on it.
[21:07:51] <bcoudurier> it's a nightmare for users
[21:08:03] <bcoudurier> hopefully someone will take over
[21:08:08] <bcoudurier> why don't you ?
[21:08:19] <bcoudurier> it's a great opportunity to understand rtmpe
[21:08:21] <hyc> you have no choice - you need an external TLS library. unless you want to write that too.
[21:08:51] <hyc> I already understand rtmpe inside and out. probably better than anyone else in the free software community.
[21:09:28] <hyc> as for external libs - rtmpdump is hosted on the same svn as ffmpeg and mplayer. just make it an external SVN reference. users will never know the difference.
[21:09:38] <hyc> except that it works with more sites.
[21:09:38] <bcoudurier> oh is librtmp your lib ?
[21:09:54] <hyc> yes
[21:10:11] <bcoudurier> I understand better
[21:10:39] <bcoudurier> good work btw
[21:10:44] <hyc> ;)
[21:12:37] <andoma> hyc: path to the repo?
[21:12:45] * BBB thinks hyc is an arrogant piece of shit that needs to grow up
[21:12:53] <BBB> good luck with libXY
[21:13:09] <BBB> I can see 5 yrs from now I have to ask a gsoc student to integrate the dead project into ffmpeg, just like with libmms now
[21:13:10] <BBB> great
[21:13:12] <BBB> just great
[21:13:26] <hyc> BBB: you can ask Compn how much labor / research has gone into it
[21:13:49] <hyc> andoma: svn.mplayerhq.hu/rtmpdump/trunk/librtmp
[21:13:55] <andoma> hyc: thanks
[21:14:21] <hyc> BBB: compare that to how much maintenance has gone into ffmpeg rtmp
[21:14:31] <hyc> and you tell me which one is going to be dead in 5 years.
[21:14:46] <bcoudurier> I hope ffmpeg won't be
[21:15:21] <hyc> bcoudurier: I don't mean ffmpeg as a whole.
[21:15:31] <hyc> just looking at the rate of development of ffmpeg rtmp.
[21:15:42] <bcoudurier> besides rtmp code is kinda new
[21:16:21] <bcoudurier> and it seems some users are actually using it, I don't know if it is that much though
[21:17:05] <hyc> in the time since we entered mplayerhq SVN till now (~Sep 2009) we've done more work to stabilize it, extend it,make it portable.
[21:18:55] <bcoudurier> that's great, I wish it would be the same for native rtmp and I understand you don't want to improve the native one
[21:19:37] <hyc> and it's great that users are using the native one
[21:19:48] <hyc> again, switching doesn't lose them anything. it only gives them more.
[21:21:39] <hyc> anyway, that argument is over. if they want to keep the old code in place, that's fine, not my problem.
[21:21:50] <Dark_Shikari> ffmepg is all about leaving around old code that sucks
[21:21:54] <Dark_Shikari> see vorbisenc ;)
[21:22:29] <bcoudurier> encoding is different
[21:22:38] <bcoudurier> and code sucking != code missing features
[21:22:42] <Dark_Shikari> True.
[21:23:02] <bcoudurier> so instead of bashing ffmpeg why don't you go on doing something better ?
[21:23:25] <bcoudurier> like coding _on_ ffmpeg since you claim to be a ffmpeg developer
[21:24:10] <hyc> bcoudurier: I have a task in mind already - getting time-based seek working consistently. I said that already
[21:24:34] <hyc> but there's no point in adding frills to an inadequate foundation.
[21:26:37] <hyc> I'm not bashing - just pointing out the obvious. users will get confused if they some rtmp streams work and some don't, because there are two "parallel" implementations active at the same time, and one doesn't implement all the security features of the other.
[21:34:32] <BBB> hyc: I'm seeing the situation in 5 yrs where the world has moved away from rtmp, like MS moves away from mms, and everyone uses new techniques (most likely modified versions of rtsp, maybe even straight http) through html5 (MS did that also)... we'll be left with 2 dead codebases, one of which sucking more than the other, but the other not being shipped because it's obsolete anyway
[21:35:06] <BBB> hyc: and people keep wondering why half of their radiostations don't work (for whatever crap reason) - we could've fixed that here, today
[21:35:17] <BBB> but nobody cares about that in 5 yrs, it's history
[21:39:40] <hyc> frankly, I hope that happens. I hope that in 5 years everyone is using HTML5 video and rtmp dies a well deserved death
[21:39:48] <hyc> it's all crap anyway
[21:41:28] <hyc> in the meantime, the two main arguments I'm hearing are both nonsense. you can't add rtmpe support without a crypto library. so if you're opposed to adding external dependencies, well, tough.
[21:42:31] <hyc> and as for maintaining existing code - librtmp existed first...
[21:44:20] <hyc> if you care about providing stable features, the more mature code base is naturally the better bet.
[21:47:47] <bcoudurier> we agree, but we cannot reasonably refrain people from coding something new if they want to
[21:48:27] <bcoudurier> for encoders quality produces will matter though
[21:48:35] <bcoudurier> produced
[21:49:35] <peloverde> The first google result for librtmp is a dead link
[21:49:58] <hyc> http://rtmpdump.mplayerhq.hu
[21:50:13] <hyc> that shouldn't be hard for the folks around here to find...
[21:52:17] <thresh> what about xbmc fork?
[21:52:46] <hyc> thresh: what do you mean?
[21:53:31] <peloverde> If that's such a mature codebase why isn't it on the first page for "librtmp"?
[21:53:37] <iive> i thought that ffmpeg rtmp effort started when rtmpdump run into legal trouble
[21:54:13] <hyc> peloverde: because everyone just called it rtmpdump
[21:54:25] <thresh> oh, that's google providing wrong links, sorry
[21:55:03] <hyc> the rtmpdump code started from XBMC's libRTMP.
[21:55:26] <hyc> then the DMCA thing hit and it got deleted from sourceforge
[21:55:58] <hyc> then a couple months later the mplayer folks offered to host it
[21:56:32] <hyc> so, the current rtmpdump web site is rather new and no, it's not #1 in the google results
[21:57:57] <hyc> I started working on it because I was working with the guys at AlwaysInnovating to write a watch_hulu app for their Touchbook
[21:58:13] <hyc> the original code was in C++ and it triggered an ARM g++ bug
[21:58:27] <BBB> btw who's against a crypto library in ffmpeg?
[21:58:28] <hyc> that would send it into an infinite loop while opening a connection.
[21:58:42] <BBB> is libssl portable? I thought it was
[21:59:09] <hyc> yes, libssl works fine on many platforms. works fine on ARM
[21:59:37] <hyc> BBB: I don't know if anyone is against a crypto library in ffmpeg
[21:59:58] <hyc> I see you have several of the necessary functions already in libavutil
[22:00:08] <iive> BBB: we already have some crypto functions from wmv drm. check avutil.
[22:00:29] <BBB> well that's one argument gone
[22:00:34] <hyc> but again, it seems to me to be a better use of time to expand functionality, not just keep duplicating existing features.
[22:01:02] <hyc> what's the motivation to keep adding crypto functions to libavutil?
[22:01:26] <iive> hyc: when there is enough of them, we'll make avcrypt
[22:01:30] <hyc> do you have a team of subject-matter experts here just chomping at the bit, waiting to write their next crypto function?
[22:01:48] <bcoudurier> people like and want to
[22:02:19] <BBB> hyc: anything wrong with that?
[22:02:27] <BBB> oh no! we'll share code between wmv and rtmp
[22:02:27] <BBB> th
[22:02:35] <BBB> that must mean it's patent-encumbered
[22:02:42] <BBB> they'll sue each other to death! so let's not
[22:02:43] <BBB> ohwait
[22:02:46] <BBB> we don't give a shit
[22:04:04] <hyc> ok, let me know when you have ffmpeg tls working...
[22:05:34] <iive> hyc: is that the only problem? do you need full tls functionality?
[22:06:15] <hyc> iive: from what I've seen with rtmp, there are very few sites using rtmps (RTMP over SSL/TLS)
[22:06:21] <hyc> so you can probably live without it
[22:06:52] <hyc> but RTMPE still requires a Diffie-Hellman key exchange in the handshake
[22:07:10] <hyc> and generally, code for D-H is part of TLS libraries since that is one of their possible handshakes
[22:07:33] * iive checks avutil as D-H sounds familiar
[22:07:48] <kierank> how is swf verification going to operate in ffmpeg?
[22:07:48] <hyc> librtmp was originally written for OpenSSL, but I've adapted it to work with GnuTLS too
[22:08:30] <hyc> kierank: librtmp will do the verification and maintain a cache of verify info
[22:09:42] <hyc> we just append option switches to the RTMP URL
[22:09:44] <hyc> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-March/063988.html
[22:10:30] <hyc> I setup the same options in my ffmpeg patch, so ffplay would do the same
[22:14:55] <iive> hyc: i don't see any commits in mplayer related to rtmp
[22:15:09] <hyc> iive: uau pulled them into his git tree
[22:15:31] <hyc> but if we go into ffmpeg, then most of those commits could be ignored
[22:15:40] <iive> you know that would benefit only uau own fork.
[22:16:27] <BBB> who is uau?
[22:16:33] <hyc> yes, I see...
[22:17:45] <iive> BBB: Uoti Urpala
[22:18:08] <BBB> oh I see that's a flamewar subject right?
[22:18:18] * BBB not very familiar with the mplayer history
[22:18:20] <hyc> looks like it
[22:21:10] <ramiro> BBB: mplayer started as an entry to the IOCCC.
[22:21:22] <iive> well, my version is that uau didn't follow project rules. few times there was a call to be removed from project. he was kept in as viable contributor. now he doesn't contribute anything and pretends that his fork is the real mplayer.
[22:21:23] <ramiro> the coding standards haven't changed since then.
[22:26:18] <ramiro> hyc: what did paypal do?
[22:27:39] <hyc> ramiro: they froze our account after our first donation
[22:27:51] <hyc> I guess they think I'm an international terrorist money launderer
[22:28:09] <hyc> (it was 10 euros)
[22:28:44] <ramiro> did they give any explanation?
[22:28:58] <hyc> I went back and forth with them for a week
[22:29:20] <ramiro> they're assholes... they froze my account once too
[22:29:22] <hyc> they said if I wanted a full explanation I would have to send them a subpoena from a judge for their documents
[22:29:32] <hyc> yeah, assholes.
[22:29:52] <ramiro> luckily now I can cash money to my bank account in brazil.
[22:30:07] <iive> hyc: did you had money in the frozen account?
[22:30:07] <ramiro> so I get it out as soon as I have enough to not pay fees =)
[22:30:19] <ramiro> iive: he said 10 euros
[22:30:36] <hyc> I was considering adding some PayPal Sucks logos to the page, but decided I didn't want to distract from our main mission
[22:31:09] <ramiro> btw I would never trust paypay. it seems like a huge scam.
[22:31:20] <ramiro> starting by the name =)
[22:31:34] <hyc> in fact some of their policies are just as bad as paypal
[22:31:51] <hyc> so, we'll see what happens when the next donor comes along, if we get another hassle or not
[22:32:16] <hyc> but they do seem to have a lot of recommendations out there
[22:34:14] <hyc> i don't expect much will come of it. I only set up the first paypal account because someone emailed the list and asked where to send donations to. we didn't have anything on the web site before that.
[22:34:43] <hyc> I'm sure he'll be pleased to know that his 10 euros are locked away in paypal's bank account now.
[22:35:41] <kierank> ^^ small claims court
[22:36:29] <BBB> btw
[22:36:38] <iive> kierank: e.g. i'm not sure my country have such thing at all.
[22:36:39] <BBB> hyc, if you want to be part of the ffmpeg foundation that's fine with me
[22:36:41] <BBB> we can sue for you
[22:36:50] <BBB> we have good lawyers
[22:39:53] <hyc> lol... for 10$ it's not worth the time
[22:40:15] <hyc> but it's good to know re: the lawyers. may need them if rtmpe support moves forward.
[22:40:38] <kierank> BBB: ok if I PM you about something?
[22:46:56] <BBB> yes
[23:35:23] <CIA-92> ffmpeg: stefano * r22600 /trunk/libavutil/error.h: Extend description for AVERROR_INVALIDDATA.
[23:35:24] <CIA-92> ffmpeg: stefano * r22601 /trunk/libavutil/error.h:
[23:35:24] <CIA-92> ffmpeg: Change the definition of AVERROR_INVALIDDATA at the next libavutil
[23:35:24] <CIA-92> ffmpeg: major bump, using an FFmpeg specific error code rather than EINVAL,
[23:35:24] <CIA-92> ffmpeg: which has a quite different semantics.