[FFmpeg-devel-irc] IRC log for 2010-10-01

[irc at mansr.com]

[00:00:00] <kierank> it is exactly how ac3/dts are "open standards" yet the standards themselves are broken routinely by the creating company
[00:00:22] <Dark_Shikari> Exactly
[00:00:27] <Dark_Shikari> VP8 and AC3 are the same
[00:00:38] <Dark_Shikari> supposedly "open" but controlled by one company
[00:02:52] <ohsix> are ac3 and dts really messed with that often? like do they have a "2.0" or constant "upgrade" without trademark markings and stuff so devices with the same can actually work together?
[00:03:29] <skal> i just don't get it. How is vp8 controlled when there's a mailing list to discuss options, a git repo to propose patch, etc?
[00:03:38] <Dark_Shikari> skal: "propose patch"
[00:03:46] <skal> it's controlled because we didn't ask you to acquire the techno? what?
[00:03:47] <kierank> ohsix: well the specs of ac3/dts are not complete
[00:03:53] <Dark_Shikari> skal: you are entirely missing the point
[00:03:57] <Dark_Shikari> even if every other person in the world wanted feature X
[00:03:58] <skal> explain
[00:04:00] <Dark_Shikari> google could choose to reject feature X
[00:04:08] <Dark_Shikari> there is absolutely no community control
[00:04:09] <Dark_Shikari> no consensus
[00:04:13] <Dark_Shikari> no standards process
[00:04:18] <Dark_Shikari> there is just a big company telling everyone what to do
[00:04:23] <Dark_Shikari> "suggestions" are just that -- "suggestions"
[00:04:30] <Dark_Shikari> having a "suggestion box" on the side of your building does not make you open
[00:04:44] <skal> doesn't mean the dev on vp8-discuss are obtruse dictators
[00:04:45] <ohsix> that doesn't neccisarily go on with "open" projects either
[00:04:51] <skal> they didn't strike me as such
[00:04:56] <ohsix> kierank: oic
[00:05:06] <Dark_Shikari> ohsix: find me an open standard that was developed by a single company and is controlled by one company
[00:05:10] <Dark_Shikari> and I'll find you a standard that isn't open.
[00:05:14] <Dark_Shikari> skal: that doesn't mean anything
[00:05:16] <kierank> ohsix: the specs are there to give the illusion that the standards are open
[00:05:20] <Dark_Shikari> people can be as nice as you want; that doesn't make it open
[00:05:59] <ohsix> but i'm talking about community control; even when there are multiple entities it doesn't work out that way
[00:06:23] <Dark_Shikari> I'm pretty sure that H.264 falls quite effectively under "community control"
[00:06:30] <Dark_Shikari> Unless you think that, say, Sony owns it.
[00:06:31] <Dark_Shikari> Or Apple.
[00:06:48] <ohsix> community being the member companies
[00:07:03] <ohsix> its all in the sense of the word
[00:07:04] <Dark_Shikari> yes.  the point being -- it's a community with many different interests, often competing
[00:07:12] <Dark_Shikari> as opposed to a single company dictating how the world should do things.
[00:07:24] <kierank> I think anyone can turn up and participate in the standards process (it's definitely like that with smpte, not sure about jvt)
[00:07:34] <Dark_Shikari> And what kierank said, the standards process is pretty open
[00:07:42] <Dark_Shikari> there's literally hundreds of organizations represented there
[00:07:52] <kierank> its the free market in action
[00:07:54] <ohsix> good
[00:07:55] <Dark_Shikari> Here we have.... Google.  Just Google.
[00:08:16] <ohsix> just sayin' the analogy wasn't all that demonstrative of your point
[00:08:37] <Dark_Shikari> oooh.  michael agrees with me.
[00:08:46] <Dark_Shikari> Oh burn.
[00:08:56] <Dark_Shikari> "
[00:08:56] <Dark_Shikari> > Should we really support every single arbitrary file format released
[00:08:56] <Dark_Shikari> > by everyone, even if it isn't actually used by anyone for anything?
[00:09:00] <Dark_Shikari> "Your description there sums up the WebM format as well."
[00:09:05] <ohsix> they just need a webp decoder in javascript then it'll be moot :]
[00:09:17] <Dark_Shikari> ohsix: that's what I already said!
[00:09:22] <Dark_Shikari> not here, we were talking about it in #theora
[00:09:28] <ohsix> nice
[00:09:42] <ohsix> thats how the web adapts to that sort of thing in this era, it was different in the 90s
[00:09:48] <Dark_Shikari> It'll take 5 minutes to decode, too
[00:10:09] <ohsix> you could even do it with google's web tools :]
[00:10:17] <Dark_Shikari> btw, just on the topic of what michael said
[00:10:29] <Dark_Shikari> I think there's a danger with ffmpeg being hijacked to promote file formats
[00:10:36] <Dark_Shikari> i.e. by inserting encoders into ffmpeg as a way of pushing a new format
[00:10:40] <ohsix> the decoder could rewrite it in png or jpg with a data: url; firefox caches those in the bfcache, dunno what other browsers do, but it would stick after decode
[00:10:47] <Dark_Shikari> ohsix: it'll be really freaking slow
[00:11:14] <ohsix> i use ffmpeg as the last resort to work with random file formats, i'd want webp in there if i had to work with them
[00:11:22] <Dark_Shikari> ohsix: decode is fine imo
[00:11:24] <Dark_Shikari> encode, not so much.
[00:11:28] <ohsix> right
[00:11:34] <Dark_Shikari> someone wrote an h.261-like decoder in javascript a while back.  it took about 100ms to decode a 352x288 frame on a high-end computer
[00:11:37] <kierank> [01:10] <@Dark_Shikari> i.e. by inserting encoders into ffmpeg as a way of pushing a new format --> this is why ffmpeg needs a formal mission statement
[00:11:54] <Dark_Shikari> that means it'd take about 2 seconds to decode 1080p
[00:12:01] <Dark_Shikari> probably more for a keyframe, so say 5 seconds
[00:12:03] <ohsix> i'd be interested in seeing that decoder again with all the recent js one upsmanship
[00:12:09] <Dark_Shikari> that was a relatively recent one
[00:12:17] <Dark_Shikari> now, of course, vp8 is more complicated
[00:12:20] <Dark_Shikari> so I'd say 10-20 seconds
[00:12:28] <Dark_Shikari> kierank: agreed
[00:12:32] <ohsix> that seems pretty high :D
[00:13:49] <ohsix> but assuming something like that is written just to cover the "no webp support" case, people can start using it in some degree; then there'd be some support for having it native in stuff that are holdouts
[00:14:22] <ohsix> it might take ages, like transparent png's in internet explorer; but they eventually come around :D
[00:14:23] <Dark_Shikari> if 99% of the case is the "no webp support"...
[00:14:27] <Dark_Shikari> probably not
[00:14:28] <Dark_Shikari> look at apng
[00:14:30] <Dark_Shikari> mpng
[00:14:35] <Dark_Shikari> firefox dumped support for those iirc
[00:15:05] <ohsix> yea but one of those animated png things were of their own making, too
[00:15:12] <Dark_Shikari> And they still dumped it.
[00:15:15] <Dark_Shikari> Even though it was a fucking good idea.
[00:15:18] <ohsix> ya
[00:16:11] <ohsix> but they put a not inconsiderate amount of weight behind it when they introduced it; just adding webp to see if it dies out isn't a bad thing alltogether; when it dies it'll be really dead
[00:16:56] <Kovensky> as if they'd let their pet die ._.
[00:17:03] <Dark_Shikari> google has ADHD
[00:17:07] <Dark_Shikari> they cannot focus on a single idea for more than 2 months
[00:17:10] <Kovensky> I'm pretty sure they'll start using webp everywhere as soon as chrome support hits it
[00:17:10] <ohsix> they probably would have been better off by giving webm more time to breathe and let people shake off the "wwgd" stuff
[00:17:13] <Dark_Shikari> people will eventually notice this.
[00:17:26] <Dark_Shikari> Kovensky: no.  they can't focus.
[00:17:31] <Dark_Shikari> won't happen.
[00:17:54] <ohsix> google can use webp to make their own properties better; and if it does more power to them, it might make difference enough that people will just use chrome for the luxury
[00:18:03] <Dark_Shikari> I doubt it.
[00:18:35] <ohsix> i dont' not doubt it, but they maintain both chrome and their web properties
[00:18:52] <Dark_Shikari> You're implying the left hand knows what the right hand is doing.
[00:19:01] <Dark_Shikari> Google is a bunch of engineers who largely don't talk to each other.
[00:19:21] <ohsix> dunno, i'm sure the webp people could go "hey we should try and use this stuff, chrome can do it"
[00:19:32] <ohsix> they've lefthand righthanded things with other chrome features already
[00:19:48] <Dark_Shikari> dunno, history has shown repeatedly that google loves releasing things and then never using them
[00:20:07] <ohsix> i see chrome as their point to make argument for vendor standards
[00:20:28] <ohsix> otherwise i don't see the point in it; they can do all the js/rendering games and hw acceleration stuff and get some press
[00:20:51] <ohsix> google and gmail are boring by now, thats where they can go "hey we're doing web stuff!!11"
[00:22:06] <ohsix> if it isn't doa they'll do something with it in chrome & their web properties
[00:23:00] <ohsix> i didn't think that hd picture stuff ms' did was all that bad; maybe fragmenting, but they didn't even properly support it or try and normalize users experience with it with tools and browsers, theys upported their own stuff and let it go tits up
[00:23:25] <Dark_Shikari> well it was bad because as a format it just sucked
[00:24:35] <skal> Dark: just fyi, the webkit patch for webp is ready
[00:24:56] <skal> as said on blog.chromium.org
[00:25:00] <Dark_Shikari> Yes, and?
[00:25:09] <Dark_Shikari> A browser by Google will support a proprietary format by Google.
[00:25:10] <skal> so yes, i happen to talk to might right hand
[00:25:15] <skal> my
[00:25:15] <Dark_Shikari> Call me when someone else supports it.
[00:25:23] <skal> sure.
[00:25:24] <Dark_Shikari> skal: that's right talking to right
[00:25:26] <Dark_Shikari> they're the same team
[00:25:31] <Dark_Shikari> notice blog.CHROMIUM
[00:25:38] <Dark_Shikari> of course the chromium blog will know about chromium
[00:25:45] <Dark_Shikari> Now, tell me when Google Maps supports it.
[00:29:39] <ohsix> hm google maps supporting it would be really interesting
[00:29:50] <ohsix> that'd directly impact its use on my phone :D
[00:30:13] <Dark_Shikari> Yup.  It'd eat even more battery!
[00:30:14] <skal> hope you noticed the "Android.mk" file on my webp decoding lib :)
[00:30:21] <skal> anyway.
[00:30:25] <ohsix> how? :P
[00:30:32] <skal> gotta run
[00:30:37] <skal> but i'll be back
[00:30:39] <skal> (heh :))
[00:30:53] <Dark_Shikari> ohsix: because vp8 is about 10 times more complex than jpeg?
[00:31:35] <ohsix> but that could be offset by lots of other things, including radio time; which is the most power hungry part
[00:32:43] * Compn has a bunch of .jp2 files and no jp2 viewer :P
[00:34:30] <ohsix> doesn't the jp2k toolkit have something that outputs pnms?
[00:35:19] <ohsix> theres also 'display' from imagemagick
[00:36:36] <Compn> [20:23] <Dark_Shikari> I think there's a danger with ffmpeg being hijacked to promote file formats
[00:36:36] <Compn> [20:23] <Dark_Shikari> i.e. by inserting encoders into ffmpeg as a way of pushing a new format
[00:36:44] <Compn> thats probably the dumbest thing i've heard today.
[00:37:23] * Kovensky wonders if Compn uses a text2speech engine
[00:37:38] <ohsix> especially since a lot of projects that might want to use the new formats can't touch ffmpeg
[00:38:18] <Compn> heard/read
[00:38:34] <Dark_Shikari> Compn: er... wtf?
[00:38:37] <Dark_Shikari> People actively try to do this
[00:38:41] <ohsix> ffmpeg benefits, at least from my usage of it
[00:38:57] <Dark_Shikari> libavcodec is pretty much the world's most popular decoding lib
[00:38:58] <Compn> does ffmpeg support apng/mpng ?
[00:39:05] <Dark_Shikari> nobody ever submitted patches for those, afaik
[00:39:08] <Compn> bah
[00:39:20] <Compn> who are you to reject patches ?
[00:39:25] <Dark_Shikari> michael rejected it
[00:39:29] <Dark_Shikari> talk to michael
[00:39:49] * Compn hasnt read thread yet
[00:39:50] <Compn> :P
[00:40:17] <Dark_Shikari> He agreed with my reasoning fyi
[00:40:18] <Compn> michael prefers mike's patch
[00:40:47] <Dark_Shikari> "to be honest i dont want to support encoding before this is actually used
[00:40:47] <Dark_Shikari> anywhere."
[00:41:33] <Compn> i like the burn about sonic and nut :D
[00:41:51] <Dark_Shikari> I actually kind of agree there.
[00:41:53] <Dark_Shikari> NUT is really stupid.
[00:42:00] <Dark_Shikari> I mean, it might be a good idea, but nobody even _tried_ to promote it.
[00:42:20] <Compn> its future-thinking
[00:42:41] <Compn> for when firmwares can be updated easily and instantly to supporting any format
[00:42:45] <Kovensky> at the current pace, by the time the future arrives it'll be obsolete
[00:42:48] <Compn> of course, thats distant future but hey :P
[00:42:48] <Compn> bah
[00:43:41] <Compn> but yeah i agree with chicken egg thing
[00:43:57] <Compn> not encoder in most used library = no one can support it
[00:44:09] <Compn> no one can encode things = no one uses it
[00:44:18] <Compn> and no, i dont see this replacing jpeg , ever
[00:44:27] <Compn> like mp3, its here for a while
[00:45:45] <Compn> ffmpeg is stuck in the middle. forever supporting multiple one-company formats (mov, asf, real, webm, ogg)
[00:46:44] <Dark_Shikari> sure, but we only support them after someone uses them.
[00:46:51] <Dark_Shikari> we didn't support theora the day it came out
[00:47:07] <Compn> iirc mike had to write a spec for that one
[00:47:38] <Compn> also most of the devs hated ogg nonsense
[00:48:22] <Compn> just mike wrote a demuxer more quickly than theora decoder :P
[00:48:35] <Compn> you know
[00:48:38] <Compn> you make a good point
[00:48:43] <Compn> i'd like to see everyones wishes for ffmpeg
[00:48:51] <Compn> i bet no one agrees what ffmpeg should and shouldnt be
[00:49:04] <Dark_Shikari> I agree
[00:49:05] <bcoudurier> well ffmpeg mantra has always been: "support every format that exists"
[00:49:08] <Compn> i'm guessing you would have ffmpeg drop all encoders but x264 :P
[00:49:09] <Dark_Shikari> as kierank said, we need some sort of mission statement
[00:49:10] * Compn strawmans
[00:49:16] <Dark_Shikari> bcoudurier: for decoding, I agree.
[00:49:19] <Dark_Shikari> for encoding, I'm not sure.
[00:49:26] <Dark_Shikari> for example, I think writing a vp6 encoder would be very counterproductive.
[00:49:28] <bcoudurier> encoding add value
[00:49:34] <Compn> whats the reason for not having encoding
[00:49:36] <Dark_Shikari> encoding only adds value if it doesn't decrease the value of something else.
[00:49:44] <Compn> aside from the bs trying to shoehorn in new format
[00:49:47] <Dark_Shikari> for example, vp6 is dying in large part because there is no open source encoder.
[00:49:50] <Dark_Shikari> We _want_ VP6 to die.
[00:49:52] <Dark_Shikari> It's a piile of shit.
[00:49:55] <kierank> Dark_Shikari: the mission statement will literally require an eternity of bikeshedding
[00:49:57] <Dark_Shikari> We don't want to keep it alive.
[00:50:09] <bcoudurier> well maybe, but I wished we had a vc-1 encoder
[00:50:17] <Dark_Shikari> what would that be useful for?
[00:50:17] <bcoudurier> it drives people away from ffmpeg
[00:50:22] <bcoudurier> smooth streaming
[00:50:26] <Compn> vc-1 bluray ?
[00:50:27] <Dark_Shikari> wmv3 or vc-1?
[00:50:31] <bcoudurier> vc-1
[00:50:39] <Dark_Shikari> wait. which does it actually use?  or does it support wmv2?
[00:50:51] <Compn> bluray is mpeg2, h264 and vc-1
[00:50:52] <bcoudurier> only vc-1
[00:50:54] <bcoudurier> and h.264
[00:51:03] <bcoudurier> but h.264 is not optimized
[00:51:11] <bcoudurier> and not really released yet
[00:51:37] <Dark_Shikari> I thought that came out in silverlight 3?
[00:51:42] <bcoudurier> decoding yes
[00:51:56] <bcoudurier> and microshit still does a lot of propaganda on vc-1
[00:52:05] <Dark_Shikari> which is why we need to counter by using h264 instead.
[00:52:10] <Dark_Shikari> and adding smooth streaming muxing to ffserver
[00:53:14] <bcoudurier> http://blog.streamingmedia.com/the_business_of_online_vi/2010/09/microsoft-answers-your-questions-about-encoding-codecs-and-silverlight.html
[00:53:17] <bcoudurier> full of shit
[00:53:28] <Dark_Shikari> of course it is
[00:53:33] <Dark_Shikari> everything on streamingmedia.com is full of shit
[00:54:07] <bcoudurier> :)
[00:54:22] <kierank> we also need to get some of the "pro" 10-bit raw formats working because people are starting to use them as inputs for h.264 blu-ray encoding
[00:54:35] <bcoudurier> pro -> funding
[00:54:42] <kierank> i mean the trivial ones
[00:54:47] <kierank> like r10k
[00:54:52] <bcoudurier> the guys buy fucking equipment that cost $50k
[00:54:58] <Compn> there is support for a few of them kierank, v210, etc
[00:55:00] <bcoudurier> they can give $5k
[00:55:19] <kierank> bcoudurier: true
[00:55:26] <bcoudurier> v210 is supported
[00:55:32] <Dark_Shikari> we have avc-intra.  now write our mxf muxer!
[00:55:38] <Compn> write a news entry, 'i will support r10k for $5000' :P
[00:55:39] <Compn> ehe
[00:55:46] <bcoudurier> r10k is supported
[00:55:52] <bcoudurier> Dark_Shikari, same
[00:55:55] <bcoudurier> that's pro
[00:55:56] <kierank> r10k was an example
[00:56:04] <bcoudurier> do you how much cost a fucking P2 camera ? :)
[00:56:13] <Dark_Shikari> bcoudurier: you're not writing it yet ! ;)
[00:56:14] <kierank> just so happened that someone making an x264 blu-ray was using that as input and it worked
[00:56:27] * Compn made a bunch of 10bit samples
[00:56:35] <Compn> with non1 0bit input hah
[00:56:52] <bcoudurier> kierank, which simple one is missing ?
[00:57:03] <bcoudurier> it's not that complicated to create P2 files :)
[00:57:39] <bcoudurier> I try to basically support everything that goes into .mov
[00:57:47] <bcoudurier> and a _lot_ of people are now using FCP
[00:57:49] <bcoudurier> it's crazy
[00:57:59] <kierank> bcoudurier: a yuv equivalent of r10k which name i forget right now
[00:58:13] <bcoudurier> v210 ?
[00:58:31] <kierank> r10g I think
[00:58:47] <bcoudurier> v410 :)
[00:59:34] <Compn> kierank : check samples/v-codecs/
[00:59:35] <Compn> :)
[00:59:42] <Compn> bcoudurier : btw i found a new codec in mov
[00:59:48] * Compn digs around
[00:59:59] <Compn> DXV
[01:00:12] <bcoudurier> ah
[01:00:30] <Compn> http://www.resolume.com/avenue/dxv.php
[01:01:16] <Compn> i didnt put it in samples yet
[01:01:19] * Compn goes afk
[01:01:36] * Compn lols @ comparasion to indeo video
[01:02:11] <astrange> does the mov demuxer support subtitles/closed captions? (sbtl/clcp)
[01:03:39] <bcoudurier> timed text
[01:04:47] <astrange> qt10 wants sbtl media
[01:05:41] <bcoudurier> it accepts text in .mov
[01:05:49] <bcoudurier> but in m4v and mp4 yeah sbtl is better
[01:06:17] <bcoudurier> ah it seems the muxer supports it as well
[01:08:23] <kierank> Compn: how did you make those r10g samples?
[01:18:51] <ohsix> req: encoder  D V D  flic            Autodesk Animator Flic video
[01:19:12] <Dark_Shikari> lol
[01:19:29] <bcoudurier> Dark_Shikari, now it says VBV underflow
[01:19:32] <bcoudurier> but we are getting closer
[01:20:03] <bcoudurier> should i_nal_hrd be set to 2 for CBR ?
[01:21:00] <Dark_Shikari> see x264.h
[01:21:10] <Dark_Shikari> X264_NAL_HRD_CBR
[01:21:33] <bcoudurier> ok got it
[01:23:14] <Dark_Shikari> libavcodec/x86/dsputil_mmx.h: In function `transpose4x4':
[01:23:14] <Dark_Shikari> libavcodec/x86/dsputil_mmx.h:98: error: can't find a register in class `GENERAL_
[01:23:17] <Dark_Shikari> REGS' while reloading `asm'
[01:23:19] <Dark_Shikari> la la la someone just broke gcc 3.4
[01:23:35] <astrange> transpose4x4 hasn't changed in a while
[01:23:45] <astrange> do you have -fomit-frame-pointer off?
[01:23:48] <astrange> or PIC on
[01:24:27] <Dark_Shikari> disable-optimizations
[01:24:30] <Dark_Shikari> I needed to debug
[01:24:43] <Dark_Shikari> regular ffmpeg_g doesn't give me the right line
[01:24:48] <astrange> i --disable-asm for that too
[01:24:52] <Dark_Shikari> (it segfaults on a line of C that doesn't reference memory)
[01:25:03] <astrange> even on x86-64 the asm doesn't compile half the time
[01:27:24] <bcoudurier> Dark_Shikari, i cannot get x264 to output constant frame size
[01:29:10] <Dark_Shikari> bcoudurier: commandline?
[01:30:02] <bcoudurier> -vpre default -intra -bufsize  -b 50M -maxrate 50M -minrate 50M -s 1440x1080
[01:30:17] <bcoudurier> bufsize 2000000 like you mentioned in the commit
[01:30:25] <bcoudurier> it produces 250k frames
[01:30:35] <Dark_Shikari> I have no idea what -intra does.
[01:30:39] <Dark_Shikari> -minrate doesn't affect x264.
[01:30:48] <bcoudurier> but it should be 271360
[01:30:50] <Dark_Shikari> 250k frames are exactly what you want.
[01:30:54] <bcoudurier> nope
[01:31:01] <bcoudurier> 271360 is exactly what I want
[01:31:04] <Dark_Shikari> why?
[01:31:12] <Dark_Shikari> that's too large
[01:31:13] <bcoudurier> 271,360 bytes for 1440x1080 (25 I-frames/s for 50i and 25p).
[01:31:22] <bcoudurier> The coded frame size shall be:
[01:32:41] <Dark_Shikari> But they said 50 megabit.
[01:32:42] <Dark_Shikari> That isn't 50 megabit.
[01:34:28] <Dark_Shikari> that's quite a lot more than 50 megabit.
[01:36:56] <Compn> KotH :   70184392  70060240    124152 100% /home/ftp
[01:42:09] <Compn> bcoudurier : ok i put that dxv into samples/v-codecs/DXDI
[01:42:54] <Dark_Shikari> bcoudurier: I can't see how 271360 becomes 50 megabit.
[01:43:00] <Dark_Shikari> even if you consider 1024 vs 1000
[01:43:09] <Dark_Shikari> ((271 360 / 1 024) / 1 024) * 8 * 25 = 51.7578125
[01:50:33] <bcoudurier> humm maybe it's a special application then
[02:00:34] <Dark_Shikari> bcoudurier: if you need a fractional bufsize, I can change the api to allow that.
[02:01:48] <bcoudurier> I think quicktime might not care about the frame size
[02:46:35] <bcoudurier> ok so apple decoder requires a compliant bitstream it seems
[02:55:30] <Dark_Shikari> http://x264dev.multimedia.cx/?p=541
[02:56:35] <bcoudurier> Dark_Shikari, can you please repaste your link to the avcintra 50 sample ?
[02:58:08] <Dark_Shikari> http://www.mediafire.com/download.php?hookw5pxqcsmfb5
[03:00:44] <bcoudurier> thanks
[03:36:16] <Dark_Shikari> bcoudurier: so do we know yet what size it's actually supposed to be?
[03:36:35] <bcoudurier> nope, but I'm not focusing on that currently
[03:36:48] <bcoudurier> quicktime decodes it garbled
[03:58:06] <j0sh> Dark_Shikari: nice comparison
[04:43:52] <bcoudurier> ok, any good tool to fully decode sps/pps ?
[04:44:55] <Dark_Shikari> ffmpeg
[04:45:46] <Dark_Shikari> streameye gives a listing as well
[05:19:22] <ohsix> how do you tell ffplay to actually use vdpau or vaapi
[05:20:31] <thresh> you provide it with needed headers
[05:20:38] <thresh> ah ffplay sorry
[05:20:47] <thresh> ENOTENOUGHCOFFEE
[05:25:27] <peloverde> ffplay can't use vdpau directly IIRC
[05:31:31] <ohsix> so the --with-vaapi is just pulled in from the whole configuration?
[05:33:12] <ohsix> trying the 2010q3 intel drivers and getting an assertion failure in the va driver trying to set up the urbs for playback
[05:51:22] <ubitux> it seems renaming assert.h to avassert.h solves the linkage issue
[05:52:07] <ubitux> but i don't know if it's a correct solution
[06:08:36] <KotH> Compn: meh...
[06:08:40] <KotH> moikka moi
[07:26:10] <Tjoppen> morrn
[07:26:17] <kshishkov> god morgon
[07:26:25] <Tjoppen> well, actually 10:00 fika soon
[07:27:11] <kshishkov> det är morgon till klockan tolv, tror jag
[07:28:00] <andoma> ja
[07:31:35] <pJok> god morgon :)
[07:32:19] <Tjoppen> WebP?
[07:35:20] <superdump> god morgon
[07:35:38] <thresh> why do they need a new image format?
[07:36:30] <superdump> jag har kaffe nu. fika alltid!
[07:36:30] <kshishkov> thresh: that's irrelevant. They've introduced it because they could.
[07:36:39] <superdump> well, jpeg is very old
[07:37:12] <KotH> wtf? vp8 in riff?
[07:37:13] <Tjoppen> heh. I compared the images on jason's blog as blindly as I could. I was right about the codec on all of them :)
[07:37:20] <superdump> though i guess the file sizes needed now are mostly irrelevant
[07:37:21] <KotH> what do they take?
[07:37:23] <av500> superdump: it could break down any die?
[07:37:26] <av500> superdump: it could break down and die?
[07:37:28] <kshishkov> superdump: och jag dricka inte kaffe (och det finns inte Trocadero i Tyskland)
[07:37:47] <Dark_Shikari> Tjoppen: it's not exactly hard
[07:37:55] <Tjoppen> true
[07:38:09] <thresh> superdump: what exactly is wrong with PNG for instance?
[07:38:09] <kshishkov> superdump: BTW, it's a good date today - http://sl.se/sv/Om-SL/Nyheter/Tunnelbanan-fyller-60-ar/
[07:38:11] <superdump> Did you know? WebP is pronounced "weppy". /(wĕpˈē)/
[07:38:13] <superdump> lol
[07:38:20] <Tjoppen> jpeg kinda stands out, and differentiating between x264 and vpx itsn't exactly hard :)
[07:38:35] <superdump> thresh: well for higher resolution real images its compression is not so good
[07:38:43] <Tjoppen> superdump: that's almost as retarded as "ping"
[07:38:48] <thresh> does that webp file format support metadata?
[07:39:14] <ohsix> "riff"
[07:39:22] <ohsix> ie. arbitrary chunks with a simple header
[07:39:34] <Tjoppen> is there a psy-optimizing jpeg encoder?
[07:39:34] <superdump> hmm
[07:39:37] <kshishkov> M$ compatible too!
[07:39:38] <Tjoppen> if not -> xjpeg? :)
[07:39:50] <Dark_Shikari> jpeg is hard to psy optimize
[07:39:56] <Dark_Shikari> the only thing you can optimize is coeff rounding
[07:40:01] <Dark_Shikari> (and CQM choice)
[07:40:08] <kshishkov> Dark_Shikari: tell that to IJG guy
[07:40:08] <Dark_Shikari> there are papers on it, but almost all follow CSF blindly
[07:40:14] <Dark_Shikari> which makes me assume they are idiots
[07:40:19] <andoma> Dark_Shikari: I love it that you use pictures from Stockholm in your tests :)
[07:40:24] <av500> thresh: [21:47:21] <skal> http://pastebin.com/FbUvG77M
[07:40:29] <Dark_Shikari> andoma: parkjoy is my favorite test clip!
[07:40:32] <Dark_Shikari> other than touhou at least ;)
[07:40:33] <superdump> :)
[07:40:45] <superdump> i didn't know parkjoy was shot in stockholm
[07:40:48] <superdump> whereabouts?
[07:40:53] <andoma> Dark_Shikari: yeah, SVT used to have that on repeat when they beta tested their HD transmissions initally here
[07:40:57] <thresh> av500: thx
[07:40:59] <andoma> superdump: mostly djurgården
[07:41:04] <superdump> -r
[07:41:07] <superdump> i see
[07:41:12] <andoma> i'll pick it out on google maps
[07:41:14] <Dark_Shikari> andoma: lol, really?
[07:41:19] <Dark_Shikari> they had _that_ clip on repeat?
[07:41:25] <Dark_Shikari> They know how to test encoders :)
[07:41:42] <superdump> oh, not -r
[07:41:45] <superdump> makes sense now
[07:41:47] <superdump> :)
[07:42:15] <thresh> is there any specification on that metadata? i.e. codepage, structures etc?
[07:43:00] <ohsix> insofar that theres one chunk thats unique and some have to be near the beginning, no?
[07:44:08] <thresh> hum
[07:44:18] <thresh> so not possible to inject EXIF info etc
[07:44:22] <thresh> or?
[07:44:22] <andoma> Dark_Shikari: it's from around this place i think: http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=djurg%C3%A5rden+stockholm&sll=56.607885,17.138672&sspn=40.475203,55.019531&ie=UTF8&hq=&hnear=Djurg%C3%A5rden&ll=59.328625,18.135724&spn=0.004482,0.006716&t=h&z=17&layer=c&cbll=59.328625,18.135724&cbp=12,0,,0,5&photoid=po-1607419
[07:44:27] <andoma> oops, long url
[07:44:41] <Dark_Shikari> wonder if they have streetview?
[07:44:46] <andoma> that's streetview
[07:44:49] <ohsix> you can put whatever you want into it
[07:44:55] <Dark_Shikari> lol, they do
[07:44:55] <Dark_Shikari> nice
[07:45:10] <saintdev> on the sidewalk, even lol
[07:45:14] <thresh> ohsix: well but where? in "comments" chunk ?
[07:45:17] <ohsix> its up to whatevers loading a riff container to decide what to do with the atoms in the file
[07:45:26] <Dark_Shikari> hah, it does indeed look the same
[07:45:33] <andoma> Dark_Shikari: yup :)
[07:45:40] <andoma> it's pretty close to where SVT is located in stockholm
[07:45:57] <Dark_Shikari> amazing, google even has streetview in stockholm, on a sidewalk
[07:46:07] <kshishkov> andoma: thanks, I'll visit it next time. Never been past Rosendal so far :(
[07:46:12] <saintdev> Dark_Shikari: http://bit.ly/97juUZ
[07:46:23] <ohsix> thresh: they say to ignore unknown chunks, like most riff stuff; other than that, chunk format: http://en.wikipedia.org/wiki/Resource_Interchange_File_Format
[07:46:36] * KotH wonders whether they drove their car trough that sidewalk
[07:46:49] <saintdev> KotH: the're still pictures
[07:47:00] <saintdev> they're not 360 degree
[07:47:03] <KotH> meh... lame
[07:47:05] <thresh> ohsix: hmmm what if that RIFF has say EXIF and XMP title/descriptions
[07:47:20] <kshishkov> KotH: in Sweden street view images are taken with a camera on bicycle
[07:47:38] <KotH> lol
[07:47:38] <kshishkov> KotH: saw one in Uppsala with my own eyes
[07:47:44] <KotH> moin cartman
[07:47:46] <ohsix> thresh: what if? its up to the reader to care
[07:47:54] <cartman> lo KotH
[07:47:59] <thresh> :/
[07:48:04] <cartman> Dark_Shikari: you are so full of rant Mr. x264 developer
[07:48:18] <Dark_Shikari> rant?  that's not a rant.
[07:48:18] <KotH> cartman: EY KOCA TOPCU! SU DAGLARA YAN GELE!
[07:48:22] <KotH> :-)
[07:48:26] <cartman> KotH: :D
[07:51:48] <thresh> ohsix: so that means no proper metadata support at all in webp
[07:52:44] <kshishkov> thresh, nothing prevents you from putting metadata fro AVI into WebP
[07:53:00] <kshishkov> not than anyone cares
[07:53:40] <thresh> my point exactly.. if you're making a new image file format, why wouldnt you care for proper standardized metadata?
[07:53:55] <ohsix> thresh: nothing defined, but nothing forbids it being there
[07:54:07] * kshishkov doesn't care for metadata at all, he has elenril for that
[07:54:28] <ohsix> its probably one of the first things that someone will do with it if theres any traction at all
[07:54:39] <kshishkov> in theory, M$ RIFF parser should understand standard RIFF metadata tags
[07:55:07] <ohsix> i dunno if there is such a thing
[07:55:28] <ohsix> and the riff stuff in windows is in mm* which is like; from windows 2.1 and nobody uses
[07:55:41] <thresh> ohsix: so that would be an 'extension' to a file format, so it would not be mandatory, so no one will properly support this
[07:55:57] <ohsix> if it was getting any use it'd have a com wrapper; but they use istorage and junk for that now
[07:56:14] * elenril shoots kshishkov for highlighting him in vain
[07:56:18] <av500> thresh: because this is not to replace jpgs in digicam
[07:56:24] <ohsix> thresh: if it has info in it people wants then they'll use it
[07:56:26] <av500> this is to lock in browsers to web servers
[08:00:13] <thresh> so yet another semi-useless container
[08:00:23] <kshishkov> av500: well, it should be supported by Arch*s image viewer
[08:00:43] <cartman> Pandaboard is alive!
[08:01:17] <ohsix> the container is riff, lots of people use it :]
[08:02:00] <thresh> well ok image file format :)
[08:02:46] <av500> kshishkov: of course
[08:04:40] <kshishkov> av500: and prepare for WebA - VP8-encoded audio
[08:04:53] <kshishkov> it should be a real hit for all portable players
[08:04:54] <Tjoppen> is there a 64-bit riff variant? the mov way could work I guess, although a bit ugly
[08:05:09] <kshishkov> Tjoppen: no
[08:05:23] <merbzt> Tjoppen: there is a spec proposal
[08:05:42] <Dark_Shikari> kshishkov: they already announced that
[08:05:58] <Dark_Shikari> notmakingthisup.jpg
[08:06:17] <kshishkov> Dark_Shikari: I'm surprised. I'm very surprised. </flat mode off>
[08:06:38] <Tjoppen> merbzt: ah
[08:06:59] <Tjoppen> now that I think about it, the "wide" tag isn't that bad of an idea if you want backward compatibility
[08:07:03] <kshishkov> it's rather outdated format for very outdated system
[08:07:04] <ohsix> what would you get from 64bit riff, bigger atoms?
[08:07:15] <Tjoppen> that is, if > 32-bit, you set the size of the "real" atom to 0
[08:07:28] <Tjoppen> certain players will take that as "from here to EOF"
[08:07:28] <ohsix> nm, the length is in there
[08:07:32] <kshishkov> ohsix: first atom there is RIFF itself, storing overall file size
[08:07:47] <ohsix> ya
[08:08:14] <merbzt> http://en.wikipedia.org/wiki/RF64
[08:08:15] <ohsix> is it really useful to have large riff files without some sort of index or having all the tags in a defined area
[08:08:16] <Tjoppen> yes. I'm a bit sceptip of the way mov (typically) store all data in one large atom
[08:08:39] <Tjoppen> at least avi provides some amount of framing
[08:09:57] <av500> kshishkov: I wait for webXML
[08:10:21] <kshishkov> av500: to build WebWebM with it?
[08:10:25] <Tjoppen> it's cool that mov can point to data in other files pretty much regardless of the container used
[08:11:45] <Dark_Shikari> cool until you run a video website that constantly gets user uploads of linked files
[08:11:48] <Dark_Shikari> with no actual video data
[08:11:50] <Dark_Shikari> who then complain when the transcode fails
[08:14:07] <kshishkov> Dark_Shikari: like those 44-byte RIFF files shown for Audio-CD tracks on Windows :P
[08:14:08] <av500> if it was cool, it would automatically go out and fetch that stuff from the intertubes, whatever it takes
[08:14:08] <Tjoppen> pebcak
[08:14:22] <Tjoppen> av500: you can but http uri:s in there
[08:14:25] <Tjoppen> *put
[08:14:53] <av500> Tjoppen: I know I can
[08:15:25] <Tjoppen> mxf is also quite interesting. it handwaves the issue of demuxing, meaning you can use any container for the external essence - you just have to implement them
[08:15:31] <av500> but what if that requires a password? I expext a web service at appl,com that will fetch me the content!!1!1
[08:15:36] <Tjoppen> so mkv works with mxf, but not with mov
[08:15:50] <av500> then it is "cool"
[08:15:50] <ohsix> chunks for 2 part authentication can be added
[08:16:02] <av500> you are all missing the point :)
[08:16:13] <av500> 1) create cool file with pwd url
[08:16:18] <av500> 2) change passwd
[08:16:21] <av500> 3) lose
[08:16:25] <Tjoppen> mxf also supports "text locators". basically "human operator - fetch tape in shelf 5 and put in tape reader 2"
[08:16:41] <Tjoppen> a mechanical turk if you will
[08:17:08] <Tjoppen> av500: you'd config such auth info elsewhere in the app though
[08:17:44] <av500> Tjoppen: how? I just found an usb stick with said file in the park, now I want to play it :)
[08:18:43] <Tjoppen> have it so the  code can detect it needs a password, and require such input (via command line or popup)
[08:19:32] <Tjoppen> or magic
[08:21:47] <lu_zero> webp ...
[08:22:07] <av500> lu_zero: go back to bed
[08:22:42] <ohsix> mkv can do file refs too; which is really annoying if you have a grip of them you'd rather rename
[08:23:42] <elenril> mkv doesn't refer to other files by name
[08:24:08] <ohsix> well whatever it does; it breaks
[08:24:20] <elenril> blame your demuxer =p
[08:24:34] <ohsix> why
[08:25:00] <ohsix> the one i'm thinking off was like; a handful of mkv's to play another set of them in different orders, renaming any of them would break it
[08:25:41] <elenril> matroska uses segment uids for links between files
[08:26:15] <elenril> it isn't specified how to find these segments
[08:26:40] <kshishkov> it's obvious for WebM though
[08:26:41] <elenril> haali's and uau's demuxers scan all mkvs in current dir
[08:27:46] <lu_zero> av500: you are going to need it I guess
[08:28:05] * lu_zero wonders how snow and h264 might fare doing this
[08:31:57] <bcoudurier> night guys
[08:32:04] <kshishkov> lu_zero: not possible for Snow - MNG extension is already occupied
[08:32:17] <Dark_Shikari> lu_zero: doing what
[08:33:10] <lu_zero> Dark_Shikari: use them in a single frame container to replace jpeg
[08:34:01] <saintdev> lu_zero: http://x264dev.multimedia.cx/?p=541
[08:34:12] <Dark_Shikari> snow iirc is similar to (but a bit better than) jpeg-2k
[08:34:16] <Dark_Shikari> in terms of compression
[08:41:56] <lu_zero> nice post =)
[08:45:26] * av500 does not understand why Dark_Shikari does not like smooth running people ...
[08:45:35] <Dark_Shikari> smooth running people?
[08:45:45] <av500> running in a park
[08:45:49] <av500> in oslo
[08:46:38] <av500> wepP made them sooo smooth
[08:46:45] <Dark_Shikari> lol
[08:48:37] <av500> Dark_Shikari: so PSNR is the wrong metric i gather
[08:55:38] <KotH> ^^'
[08:57:20] <kshishkov> av500: I hope you just fail at geography. Oslo compared to Stockholm is like Berlin compared to Darmstadt (not in term of size)
[08:58:31] <av500> kshishkov: it was faster to type
[09:00:28] <kshishkov> av500: so you type "webm" instead of "matroska"?
[09:00:34] <av500> mkv
[09:00:36] <kshishkov> or "avi"
[09:00:56] <av500> rm
[09:01:24] <lu_zero> rm <- nomen omen...
[09:01:54] <superdump> hang on a minute, if basically all digital cameras that people use output jpeg, converting from jpeg (lossy) to webp (lossy) isn't going to do any good
[09:02:56] <kshishkov> superdump: that was obvious from the very beginning
[09:03:22] <kshishkov> av500: that container name hints on what to do with it indeed
[09:03:49] <Dark_Shikari> web-pee
[09:03:50] <mru> superdump: sssssh
[09:04:00] <av500> kshishkov: ok, then ts or ps
[09:04:24] * mru likes .a
[09:04:31] <lu_zero> superdump: they know and then show you shiny graphics about that...
[09:04:48] <av500> superdump: like for webM, hardware manufacturers are standing in line to make new, webP capable hardware asap....
[09:05:04] <mru> when are we getting that elf demuxer anyway?
[09:05:40] <kshishkov> and muxer!
[09:05:54] <av500> mru: once we solve the execution timestamp reordering in out-of-order cpus
[09:06:43] <av500> how do we assign pts and dts to the instructions...
[09:07:01] <kshishkov> by their offset
[09:07:23] <mru> and relocations?
[09:07:38] <kshishkov> it's static in file
[09:08:01] <kshishkov> execution time may vary greatly (especially with P-IV)
[09:08:28] <av500> we must be able to remux from e.g. P4 to K6
[09:08:55] <lu_zero> that's reencode!
[09:09:25] <av500> -xcodec copy!
[09:11:14] <Dark_Shikari> ffcpu
[09:11:16] <kshishkov> ./ffmpeg -i ffmpeg -xcodec copy -xfilter dropsse2 ffmpeg.exe
[09:12:33] <av500> kshishkov: since ff and qemu come from the same source, a merge can be done, no?
[09:13:22] <av500> and there is tinyc as well
[09:17:07] <Tjoppen> is repeat_pict the proper field to get the "duration" of an AVFrame? for instance when doing VFR
[09:21:46] <lu_zero> av500: qemu isn't doing something much different, but mostly acts as player if you come to think in this way
[09:22:16] <av500> it might get into svn much before the modplayer :)
[09:22:43] <lu_zero> av500: modplayer is trying to do both at the same time =P
[09:22:58] <lu_zero> (emulate an architecture AND play)
[10:19:53] <Kovensky> <+elenril> it isn't specified how to find these segments <-- IIRC there's a header that has a filename hint but nobody uses it (it would only be used for avoiding the directory lookup if the file existed and was of the requested uid anyway)
[10:24:43] <elenril> only for hard linking, not ordered chapters
[10:24:54] <elenril> nobody uses hard linking anyway
[10:28:30] <lu_zero> saste: poing
[10:28:54] <lu_zero> the last batch of changes to ffplay broke the non-avfilter path...
[10:29:10] <Kovensky> sure is lots of things breaking lately :>
[11:09:15] <CIA-63> ffmpeg: thardin * r25280 /trunk/libavcodec/ (allcodecs.c avcodec.h pcm.c): Add pcm_lxf, a decoder for the 20-bit planar PCM format used in LXF
[11:09:16] <CIA-63> ffmpeg: thardin * r25281 /trunk/ (6 files in 3 dirs): Add demuxer for LXF (Leitch/Harris' VR native stream format)
[11:09:17] <CIA-63> ffmpeg: thardin * r25282 /trunk/MAINTAINERS: Add myself as maintainer of lxfdec.c
[11:10:12] <Tjoppen> now, if only I had a beer to celebrate
[11:10:46] <kshishkov> use Portello instead
[11:11:37] <Tjoppen> me and a friend found a good non-alcoholice beer by BrewDog: Nanny State
[11:12:07] <Tjoppen> so far we've found perhaps three that are OK
[11:36:52] <saste> lu_zero: what's broken in ffplay?
[11:37:35] <mru> it is broken
[11:38:05] <mru> ask av500, he knows *it*
[11:44:56] * kshishkov is frightened by the first hit on "emms" search
[11:46:21] <jannau> emacs multimedia system?
[11:46:22] <lu_zero> saste: the frame isn't scaled correctly so you end up with a green surface with a small timestamp on the corner
[11:46:29] <lu_zero> jannau: ugh?
[11:46:30] <kshishkov> jannau: yes
[11:46:34] <lu_zero> all written in lisp?
[11:47:18] <jannau> lu_zero: no "The fact that EMMS is based on external players makes it powerful, because it supports all formats that those players support, with no effort from your side."
[11:48:03] <jannau> but otherwise of course: "And last but no least : Written in Emacs lisp :)"
[11:48:55] <lu_zero> brrr....
[11:49:12] <lu_zero> scary in many ways
[11:49:30] <mru> why?
[11:49:44] <mru> they didn't write a vorbis decoder in emacs-lisp
[11:50:09] <lu_zero> I was thinking about theora decoder
[11:50:19] <kshishkov> that'd make RMS happy if his Yulong has any audio output
[11:51:59] <av500> kshishkov: it should have md5 output at least....
[11:52:24] <kshishkov> av500: mru will be happy to listen to that
[11:53:22] <saste> lu_zero: funny... it's using the default w/h values set in the swscale context
[12:01:21] <CIA-63> ffmpeg: michael * r25283 /trunk/libavutil/rational.h: Fix av_cmp_q() with negative denominators.
[12:10:35] <lu_zero> uhm
[12:12:58] <kshishkov> lu_zero: very informative
[12:20:49] <lu_zero> kshishkov: what?
[12:34:27] <saste> lu_zero: the ffplay "bug" was due to a conflict in my libswscale repo... from what I can see it works just fine
[12:37:49] <KotH> cartman: btw: is there any baris manco collection available in .tr?
[12:37:55] <KotH> cartman: i'm still missing quite a few CDs
[12:45:21] <cartman> KotH: you shall tell me names, I shall check it out
[12:46:22] <KotH> ok.. i'll prepare a list of the cds i'm missing :)
[12:51:37] <kshishkov> cartman: be grateful Turkey is not known for anime
[12:51:54] <KotH> lol
[12:51:55] <superdump> hmm, i feel like i've forgotten all the statistics i ever knew
[12:52:04] <cartman> kshishkov: I have friends with TBs of anime archive :P
[12:52:14] <KotH> kshishkov: finding odd animes is a lot easier than finding anything in turkey
[12:52:19] <kshishkov> cartman: yes, I know KotH
[12:52:20] <lu_zero> saste: maybe we share the same conflict then ^^;
[12:52:24] <lu_zero> let me check
[12:52:26] <cartman> kshishkov: lol :D
[12:52:44] <kshishkov> KotH: nah, you can easy find Russians and trouble in Turkey
[12:53:17] <kshishkov> superdump: and so did I and haven't regretted it so far
[12:53:44] <superdump> if i have some metric scores that should indicate something in some cases and not in other cases and i want to plot the frequency distributions of the discrete data sets to analyse them a bit, is there any good way of doing that?
[12:53:58] <superdump> or some better way of comparing them
[12:54:04] <av500> superdump: statistics is easy:
[12:54:12] <av500> 1) decide what you want to prove
[12:54:12] <superdump> i mean, i could just look at box and whisker plots
[12:54:18] <av500> 2) tweak it until it proves it
[12:54:47] <kshishkov> superdump: gnuplot can do that stuff IIRC
[12:54:53] <superdump> but i'd rather have some kind of frequency distribution to look at
[12:55:03] <superdump> kshishkov: yeah, but how? :)
[12:55:10] <kshishkov> RTFM
[12:55:11] * superdump looks at Dark_Shikari
[12:55:19] <superdump> i'd be here for years i'm sure
[12:56:08] <KotH> superdump: if you can wait a year, i should understand most of statistics then :)
[12:56:20] <superdump> :p
[12:56:23] <kshishkov> or you can do it by hand
[12:56:34] <superdump> me too
[12:56:38] <kshishkov> frequency distribution = array of counters
[12:56:41] <cartman> anyone from Munich here?
[12:56:52] <KotH> i dont think so
[12:56:57] <cartman> :/
[12:57:00] <KotH> why?
[12:57:01] <superdump> kshishkov: well, i can plot histograms, but binning destroys some of the information
[12:57:06] <KotH> cartman: i've friends there
[12:57:20] <cartman> KotH: ah just need a time estimation from a hotel to airport
[12:57:24] <cartman> going to a conference
[12:57:27] <kshishkov> superdump: use finer resolution for bins then
[12:57:33] <KotH> cartman: calc 1h
[12:57:38] <cartman> KotH: what :D
[12:57:49] <KotH> cartman: calculate with 1h
[12:57:51] <kshishkov> cartman: it's a safe assumption
[12:58:01] <cartman> KotH: from city center to airport
[12:58:04] <cartman> one hour not bad
[12:58:14] <kshishkov> it took less for me
[12:58:19] <KotH> cartman: it's bad
[12:58:24] <KotH> cartman: at least for europe :)
[12:58:28] <cartman> KotH: not if you live in Istanbul
[12:58:33] <cartman> I used to have 5 hours of commute
[12:58:37] <KotH> cartman: learn: not every city is as chaotic as west-turkey
[12:58:52] * cartman takes note
[12:59:02] * KotH was used to have a 5min commute when he was in japan
[12:59:09] <kshishkov> cartman: http://www.airportbus-muenchen.de/cms/en/times_of_departure/munich/index.html
[12:59:09] <KotH> 5min walking ;)
[12:59:44] <cartman> kshishkov: cool, my hotel is Casa Cleo
[12:59:49] <KotH> cartman: when are you in münchen?
[12:59:53] <cartman> and the conf. is in Dolce Munich
[13:00:14] <cartman> KotH: October, 9 to October, 12
[13:00:19] <KotH> damn.. wrong date
[13:00:23] <cartman> then I am going to Rome
[13:00:32] <cartman> my sister will have an important knee surgery
[13:00:39] <KotH> passing trough .ch?
[13:00:46] <KotH> or flying?
[13:00:47] <cartman> nah all by train :(
[13:00:50] <cartman> at night :(
[13:01:06] <av500> orient express?
[13:01:09] <KotH> train isnt too bad... until you enter italy
[13:01:13] <cartman> heheh
[13:01:19] <KotH> cartman: make sure you book a cnl
[13:01:24] <cartman> cnl is ?
[13:01:29] <kshishkov> city night line
[13:01:33] <kshishkov> night train
[13:01:34] <thresh> the repellent against italians
[13:01:43] <cartman> kshishkov: dunnow sister does all the work :D
[13:01:52] <BBB___> is av_image_copy() called in ffmpeg.c? or in avfilter?
[13:01:56] <kshishkov> thresh: they also go to Kiev and Moscow, so you may be right
[13:01:58] <KotH> cartman: cnl is about the only night train i'm able to sleep in :)
[13:02:04] <thresh> i will go to Spain in a couple of weeks
[13:02:06] <cartman> KotH: Ok :D
[13:02:11] <cartman> thresh: Spain is nice
[13:02:18] <cartman> people are really nice over there
[13:02:18] <thresh> especially Canary islands :D
[13:02:18] <wbs> BBB___: ok with me committing the rtp reordering stuff? (was ok according to lu_zero)
[13:02:24] <KotH> cartman: also note, that you have to book the train _now_
[13:02:36] <BBB___> wbs: didn't I ok most of it last time already?
[13:02:39] <BBB___> wbs: I'll have a quick look
[13:02:40] <thresh> well people are really nice everywhere in EU compared to evil eastern countries
[13:02:49] <KotH> cartman: if you wait another few days, you wont have even a seat
[13:02:54] <kshishkov> KotH: I could sleep fine only in NatTÃ¥g, CNL seems a bit narrow
[13:03:09] <KotH> kshishkov: narrow? not too short?
[13:03:16] <wbs> BBB___: yeah - it's mostly the same, except for avoiding memcpy of the whole packet when enquing, and avoiding memmove by using a linked list for the queue
[13:03:21] <cartman> KotH: already booked I think
[13:03:29] <av500> thresh: russians have now started buying up spain too?
[13:03:40] <kshishkov> KotH: carriages are long enough but beds are limited by carriage width, not length
[13:03:55] <BBB___> wbs: why is recvbuf_size in the struct? do you intend to change it?
[13:04:07] <KotH> kshishkov: ah.. yes
[13:04:13] <kshishkov> av500: no, it's bought by England long time ago. But Canary Isles are traditional Russian resort
[13:04:13] <KotH> kshishkov: i thought you were refering to the beds
[13:04:18] <thresh> av500: sure, Spaniards even want to drop down the visa barrier
[13:04:26] <wbs> BBB___: not necessarily, but to make it explicit how large it is, since you can't use sizeof() on it
[13:04:28] <thresh> which would be mega awesome
[13:04:33] <av500> cant have the tursk take all the russian business...
[13:04:37] <thresh> finally, a decent country and no visas
[13:04:38] <av500> sk->ks
[13:04:44] <BBB___> wbs: hmk, I suppose a define would be fine alos
[13:05:03] <BBB___> wbs: I agree with luca that you should change the prototype of rdt also, I intend to eventually make that a function pointer
[13:05:14] <BBB___> (it doesn't have to do anything with it yet, and it's a minor change)
[13:05:17] <thresh> turks i've met are just too lazy to do proper business
[13:05:18] <wbs> ok
[13:05:20] <thresh> no offence cartman
[13:05:21] <kshishkov> av500: well, that will be awesome - Turks at least tend to work
[13:05:26] <thresh> orly
[13:05:37] <cartman> orly is in France
[13:05:41] <cartman> :P
[13:05:45] <kshishkov> thresh: well, how many Russian builders do you know?
[13:06:07] <thresh> kshishkov: as Ukraine counts as Russia, about 6
[13:06:17] <kshishkov> thresh: no, it doesn't
[13:06:27] <thresh> now now, you're a Swede
[13:07:07] * kshishkov has never heard about Moldova people complaining about all those cheap Russian workers
[13:07:41] * cartman goes back to fixing WinCE firmware
[13:09:30] <BBB___> wbs: which patch has the code so that rtsp.c reallocs a new recvbuffer if rtpdec.c takes ownership of the old one? and where is it handled that if rtp_parse_packet() returns 1 because we have more (previously queued, unordered) packets in the queue, that calling that function with NULL will result in taking up the next packet from the queue ASAP?
[13:09:42] <BBB___> it seems that the queue handling is only triggered if buf != NULL
[13:09:49] <BBB___> which might be unoptimal
[13:10:32] <wbs> BBB___: patch 0001 has the reallocation of a new buffer if the previous one is set to null
[13:10:58] <BBB___> oh right it's in fetch
[13:11:00] <BBB___> ok, that's good
[13:11:19] <wbs> and in patch 0004, in (!buf) we check that if the previous depacketizer returned 0, we dequeue one from the queue instead
[13:12:35] <BBB___> does all of that work after seeking?
[13:12:41] <BBB___> it probably does becuase then buf != NULL anyway
[13:12:49] <BBB___> ok, I guess it's fine then
[13:12:56] <BBB___> if something breaks I can always blame you :-p
[13:13:15] <wbs> yeah, and if blamed, I usually try to fix whatever I've messed up ;P
[13:14:23] <wbs> but yes, I guess we should reset the packet queue on seeks
[13:14:58] <wbs> I'll fix something for that, switch the recvbuf_size to a define, and unify the rtp/rdt interfaces
[13:15:10] <BBB___> recvbuf_size isn't a big issue
[13:15:28] <BBB___> but while you're at it, ;)
[13:15:36] <wbs> exactly :-)
[13:15:47] <BBB___> did you know our h264 decoder spends 3.4% of it's time in memcpy?
[13:16:08] <BBB___> I don't think it's the decoder, I think it's really avfilter or so
[13:18:06] <mru> arm say they've fixed one of my compiler bugs
[13:18:21] <BBB___> suncc still hasn't confirmed my bug
[13:18:36] * mru is not holding his breath for that one
[13:19:45] <thresh> kshishkov: oh wait there is no Ukraine now !
[13:23:45] <BBB___> mru: I get the feeling oracle will destroy everything that is sun+open
[13:23:52] <BBB___> and sun already wasn't very open
[13:24:09] <av500> and who cares?
[13:24:12] <mru> they were open in the google way
[13:24:24] <thresh> I wish they destroy mysql faster
[13:24:32] <av500> ffmpeg will not run on big database cluster, how bad...
[13:25:10] * mru makes evil plans to write a codec as sql queries
[13:26:22] <ubitux> can we have a patch to fix the assert issue?
[13:26:40] <ubitux> it seems a rename from assert.h to avassert.h (for example) solve the issue
[13:26:47] <ubitux> (with the 2-3 path fix in includes)
[13:26:49] <mru> what exactly is the issue?
[13:26:55] <cartman> must.resist.killing.mru
[13:27:08] <ubitux> mathematics.c:(.text+0x72): undefined reference to `assert'
[13:27:51] <mru> what system?
[13:28:12] <ubitux> linux
[13:28:17] <spaam> mplayer fail to compile with that error msg..
[13:28:19] <av500> GNU/linux?
[13:28:23] <mru> hmm
[13:28:29] <mru> do they -Ilibavutil?
[13:28:31] <ubitux> i reported the issue yesterday
[13:28:50] <mru> I was expecting something like this
[13:28:57] <mru> just not so soon
[13:29:28] <ubitux> (you said michael fucked up again)
[13:29:51] <mru> he did
[13:30:04] <mru> and violated about 5 developer rules in the process
[13:34:04] <KotH> i think you should all listen more baris manco
[13:34:13] <KotH> it would help you to be more relaxed
[13:35:01] <kshishkov> KotH: and Tarkan for av500
[13:35:39] * KotH isnt much of a fan of tarkan
[13:36:12] <kshishkov> KotH: that's the reason
[13:36:53] <av500> kshishkov: so why me?
[13:37:53] <kshishkov> av500: you seem to be fond of Turkish people
[13:38:13] <av500> because I talk to cartman?
[13:38:13] <kshishkov> and it's too cruel to do to iive
[13:39:38] <kshishkov> maybe
[13:43:02] <KotH> kshishkov: you know that iive lives at the border to the "turkish zone" :)
[13:43:24] <KotH> so he should get plenty of turkish songs already
[13:50:08] <cartman> assert thing is indeed borked in mplayer
[13:50:56] <cartman> av500 should listen Tarkan indeed
[13:52:10] <av500> sikidim sikidim
[13:53:48] <cartman> LOL
[13:53:58] <cartman> av500: thats the spirit :D
[13:54:28] <cartman> KotH: av500 has Turkish sense of humour, don't you agree?
[13:54:44] <av500> sense of food too...
[13:54:51] <KotH> cartman: definitly
[13:55:14] <cartman> he might be an undercover serbian looking cemaat agent
[13:55:19] <KotH> cartman: you know, he grew up under turkish influence after all :)
[13:55:36] <av500> KotH: true, I was bon in frankfurt :)
[13:55:39] <av500> born
[13:55:39] <cartman> :>
[13:55:51] <kshishkov> av500: could be worse
[13:56:10] <CIA-63> ffmpeg: mru * r25284 /trunk/ (5 files in 2 dirs):
[13:56:10] <CIA-63> ffmpeg: Rename libavutil/assert.h to avassert.h
[13:56:10] <CIA-63> ffmpeg: This avoids conflicts with the system assert.h.
[13:56:10] <CIA-63> ffmpeg: mru * r25285 /trunk/libavutil/avassert.h: avassert: prettify macro
[13:56:10] <CIA-63> ffmpeg: mru * r25286 /trunk/libavutil/avassert.h: avassert: add missing #include <stdlib.h>
[13:57:46] * KotH blames mru and ubitux for fixing mplayer
[14:00:15] <kshishkov> KotH: well, break it quick!
[14:01:13] <KotH> that's mru's and diego's job
[14:02:46] <ubitux> thanks :)
[14:02:49] <kshishkov> write FFply G2 instead then
[14:02:54] <kshishkov> *FFplay G2
[14:03:09] <KotH> kshishkov: and let it rot after making it play one fileformat?
[14:04:39] <kshishkov> KotH: that's MPlayer
[14:05:25] <KotH> nah.. mplayer is alive and kicking
[14:05:52] <cartman> mru: thanx for the fix
[14:05:54] <kshishkov> kicking?
[14:06:03] * elenril kicks kshishkov 
[14:07:34] <cartman> michael is snooping on irc logs
[14:07:38] <cartman> stop logging this channel :P
[14:08:33] <kshishkov> elenril: ever heard joke about Soviet General Secretary who returned to his duties without gaining consciousness?
[14:09:51] * elenril didn't
[14:09:55] <cartman> kshishkov: ooooooooh I went to my hometown the other day and got my grandfather's old watch
[14:10:12] <cartman> its manufactured in SSCB ! Soviets!
[14:10:51] <kshishkov> well, they weren't that bad
[14:11:27] <av500> Dark_Shikari: http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/
[14:14:35] <cartman> kshishkov: its a very very good watch :)
[14:15:21] <cartman> av500: the missing benchmark is coming from me
[14:15:29] <cartman> WebP pr0n shoot out
[15:22:20] <DonDiego> say, is the aac encoder usable now?
[15:22:39] <DonDiego> as in, i don't have to disable it from mplayer's configure any longer..
[15:23:28] <kshishkov> I don't think that Alex fixed stereo mode
[15:23:52] <DonDiego> 5.1 or mono or whatever works?
[15:24:14] <kshishkov> ask him when he's present
[15:24:31] * kshishkov is too ashamed to run ffaacenc
[15:25:36] <jannau> afaik only mono is ok-ish
[15:25:44] <mru> it's slow
[15:25:46] <DonDiego> ok
[15:25:58] <jannau> and it's still marked as experimental
[15:26:02] * cartman pets kshishkov 
[15:26:21] <av500> DonDiego: so for --slow-mono-experimental its ok...
[15:27:13] <kshishkov> av500: no, that's all about how Diego sees MPlayer users
[15:52:39] <killermne1> hi
[15:52:43] <killermne1> is anyone around to help
[15:53:15] <av500> try
[15:53:47] <killermne1> im having issues on ffmpeg on my shared hosting
[15:53:53] <killermne1> was wondering if someone could help
[15:53:55] <av500> wrong channel
[15:53:59] <killermne1> ok
[15:54:00] <killermne1> bro
[15:54:01] <killermne1> sorry
[15:54:01] <av500> #ffmpeg
[16:07:39] <CIA-63> ffmpeg: stefano * r25287 /trunk/libavcore/parseutils.c: Fix weird indent.
[16:08:48] <CIA-63> ffmpeg: stefano * r25287 /trunk/libavcore/parseutils.c: Fix weird indent.
[16:09:53] <KotH> cartman: you know what's sad? i've been listening to some songs all my life, but still do not understand their meaning ^^'
[16:10:23] * av500 thinks KotH should not listen to sparkling water
[16:10:46] * KotH doesnt think that sparkling water is entertaining
[16:10:52] <KotH> though it might stench my thirst
[16:53:01] <DonDiego> siretart: http://packages.debian.org/source/stable/ffmpeg-debian
[16:53:09] <DonDiego> siretart: please fix the ffmpeg url on that page..
[17:12:37] <killermne1> hi
[17:12:40] <killermne1> nyine here
[17:12:44] <killermne1> anyone alive
[17:12:48] <killermne1> hello johnny 5
[17:14:41] * KotH kills killermne1 
[17:14:50] <killermne1> awww
[17:14:51] * av500 kills johnny5 as well
[17:15:08] <killermne1> anyone know how to save and exit out of VI
[17:15:13] <killermne1> text edit
[17:16:35] <av500> operator!
[17:16:53] <KotH> ^^'
[17:16:55] <killermne1> operator!
[17:17:03] <KotH> killermne1: do you know how to use google?
[17:17:13] <killermne1> i have been obviously lol
[17:17:17] <KotH> killermne1: if not, i suggest to learn that first before asking any more questions
[17:17:20] <killermne1> i wouldnt ask unless neccessary
[17:17:22] <av500> http://goo.gl/61H2
[17:17:43] <killermne1> i have bro can u help point me in the rifght direction
[17:17:48] <killermne1> pleas ei beg u on my knees
[17:17:51] <killermne1> pleading for help
[17:18:11] <KotH> killermne1: oh..kay... tell me first how old you are, where you live and what your education level is
[17:18:28] <jenk> ask in #freenode
[17:18:39] <killermne1> um 29 i have  a computer science degree from wnetworth im a video editor and web engineer
[17:18:50] <KotH> ok, you lose
[17:18:58] <killermne1> but thats not helping me find the command guide
[17:19:03] <killermne1> for vi text edit in ssh
[17:19:06] <KotH> if you're that old, and have that degree, you should know how to google that kind of stuff
[17:19:13] <killermne1> i have googled it bro
[17:19:16] <killermne1> like 5000 times
[17:19:25] <killermne1> want me to paste the non helping results
[17:19:31] <av500> dont
[17:20:03] <KotH> killermne1: http://tinyurl.com/2w7tcon
[17:20:06] <kierank> killermne1: ask on #vi
[17:20:14] <av500> KotH: can you make him carve a wooden C64?
[17:20:17] <killermne1> thers a vi irc
[17:20:18] <killermne1> sweet
[17:20:27] <killermne1> i think im gonna install nano
[17:20:29] <killermne1> vi blows ass
[17:20:36] <jenk> lol
[17:20:48] * av500 recommends joe
[17:20:53] <KotH> stupidity prevails ^^'
[17:20:57] <jenk> ed is superior
[17:20:59] <av500> it has wordstar key bindings...
[17:21:15] * KotH wonders whether av500 ever worked with wordstar
[17:21:49] <av500> KotH: no, but iirs turbo pascal 3 had the same :)
[17:21:53] <jenk> #libav-users is blowin' up
[17:21:56] <av500> jannau: thx
[17:21:56] <jenk> massive chan
[17:22:21] <KotH> av500: juup, TP/BP used wordstar commands
[17:23:23] <jannau> av500: I think I was too late, he seems to pester other channels now
[17:34:44] <av500> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/a305bf9e399e360c#
[17:35:09] <av500> Dark_Shikari: ^^^^
[17:35:31] <av500> somebody wake BBB and kick his ass into xvp8
[17:37:41] <DonDiego> na
[17:37:50] <DonDiego> let him speed up h.264 decoding first
[17:37:54] <DonDiego> much more important
[17:42:36] <CIA-63> ffmpeg: mstorsjo * r25288 /trunk/libavformat/ (rtsp.c rtsp.h): rtsp: Use a dynamically allocated receive buffer
[17:44:19] <CIA-63> ffmpeg: mstorsjo * r25289 /trunk/libavformat/ (rtpdec.h rtsp.c rdt.c rdt.h rtpdec.c):
[17:44:19] <CIA-63> ffmpeg: rtsp/rtpdec: Allow rtp_parse_packet to take ownership of the packet buffer
[17:44:19] <CIA-63> ffmpeg: Do the same change for ff_rdt_parse_packet, too, to keep the interfaces
[17:44:19] <CIA-63> ffmpeg: similar.
[17:45:09] <CIA-63> ffmpeg: mstorsjo * r25290 /trunk/libavformat/rtsp.c: rtsp: Reorganize if statements in rtsp_read_play
[17:45:51] <CIA-63> ffmpeg: mstorsjo * r25291 /trunk/libavformat/rtsp.c: Reindent/rewrap
[17:45:51] <CIA-63> ffmpeg: reimar * r25292 /trunk/libavformat/id3v2.c: Fix indentation of ff_id3v2_read
[17:47:00] <CIA-63> ffmpeg: mstorsjo * r25293 /trunk/libavformat/rtpdec.c: rtpdec: Split out the part of rtp_parse_packet that does the parsing of new packets
[17:51:12] <CIA-63> ffmpeg: mstorsjo * r25294 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec.c):
[17:51:12] <CIA-63> ffmpeg: rtpdec: Reorder received RTP packets according to the seq number
[17:51:12] <CIA-63> ffmpeg: Reordering is enabled only when receiving over UDP, and packets are stored
[17:51:12] <CIA-63> ffmpeg: in the reordering queue only up to AVFormatContext->max_delay microseconds.
[17:51:23] <kierank> lol none of the theora or webm ovc streams work
[17:51:37] <Dark_Shikari> lol
[17:53:23] <CIA-63> ffmpeg: mstorsjo * r25295 /trunk/libavformat/rtsp.c: rtsp: Return a queued packet if it has been in the queue for longer than max_delay
[17:54:50] <av500> kierank: I see a mic
[17:55:28] <kierank> av500: then you see more than i do
[17:56:01] <kierank> oh wow the yes men are going to be there
[17:56:02] <av500> auditorium
[17:57:01] * Dark_Shikari is afk to downtown LA
[17:57:02] <wbs> \o/ over 300 commits
[17:57:33] <av500> kierank: it is strange, my browser know nothing about webm...
[17:59:42] <kierank> hmm so i get no audio in chrome but working video in opera
[18:00:00] <kierank> its like 1999 all over again
[18:00:20] <av500> kierank: the stream is mime webm, bot ogg+theora here
[18:00:31] <av500> <video width="384" height="256" autoplay controls type="video/webm" src="http://195.10.10.220:80/ova/live1.ogg?GKID=8843d64ccd8511df8aea00163e914f68">
[18:01:15] <wbs> a live ogg stream over http in web browsers?
[18:01:17] <kierank> meh as long as i can watch jb_OVC tomorrow i don't care
[18:01:44] <wbs> last time I tested something similar, it didn't work at all in chrome, and worked almost in firefox if I let it buffer a bit before starting
[18:01:54] <wbs> the same for webm, too
[18:02:01] <wbs> worked fine in opera though
[18:02:07] <av500> ok, ffplay plays the webm stream :)
[18:02:33] <av500> with sound
[18:02:51] <wbs> av500: no surprise there :-)
[18:02:57] <av500> yeah
[18:05:36] <kierank> ruggles: why does aften have 256/512 window switching turned off by default?
[18:28:57] <killermne1> hi anyone around
[18:29:26] <kierank> no
[18:29:30] <av500> jannau: !
[18:33:28] <merbanan> kierank: I think the switching causes artifacts
[18:33:45] <CIA-63> ffmpeg: stefano * r25296 /trunk/libavfilter/avfilter.h: Fix reference to un-existing function.
[18:36:19] <kierank> merbanan: ah right
[18:39:57] <merbanan> 512 is quite short window so preecho isn't so noticeable
[18:41:18] <merbanan> or length
[19:12:40] <kierank> bcoudurier: do you know of any decent sdi capture cards
[19:30:56] <lu_zero> kierank: I'm playing with a Blackmagic design one right now
[19:31:03] <lu_zero> seems working decently
[19:31:12] <lu_zero> but the interface sucks badly
[19:31:20] <lu_zero> (C++)
[19:35:29] <kierank> yeah blackmagics are all c++ :/
[19:37:01] <cartman> I would say the same for C :>
[19:42:41] <cartman> [VD_FFMPEG] DRI failure.
[19:42:44] <cartman> never sounds good :>
[19:52:44] <lu_zero> cartman: that interface is annoying
[19:52:48] <bcoudurier> kierank, yeah
[19:53:00] <lu_zero> kierank: bright side -> I'm writing an avdevice for that
[19:53:04] <cartman> lu_zero: could be, yes
[19:53:07] <bcoudurier> on linux, the aja, blackmagic
[19:53:19] <bcoudurier> aja has very low price IIRC
[19:53:31] <bcoudurier> back in the days I sent a RFP to all the compagnies
[19:53:42] <bcoudurier> it was 2 years ago though
[19:54:15] <bcoudurier> skymicro had something interesting and they are a much smaller company
[19:54:26] <bcoudurier> although they include a fpga
[19:54:34] <bcoudurier> so it was a bit more expensive
[19:54:55] <lu_zero> RFP?
[19:55:17] <lu_zero> the acronym doesn't right anything =P
[19:55:37] <bcoudurier> request for proposal
[19:55:55] <lu_zero> aja doesn't have a v4l interface as well, does it?
[19:56:19] <bcoudurier> not sure, but they have an sdk
[19:56:26] <bcoudurier> that's enough
[19:56:39] <bcoudurier> I looked at bluefish too
[20:01:39] <bcoudurier> I even looked at the nvidia quadro cards
[20:01:49] <bcoudurier> but they were very expensive for what we wanted to do
[20:02:05] <kierank> yeah nvidia quadro cards are expensive
[20:02:14] <lu_zero> ati doesn't provide anything useful?
[20:02:46] <bcoudurier> i had meeting at NAB with the guys
[20:02:56] <bcoudurier> you shoud go to IBC
[20:03:00] <bcoudurier> and have a look
[20:03:11] <bcoudurier> ah shit it's already passed right ?
[20:03:15] <kierank> yep
[20:18:25] <Compn> killermne1 : :wq!
[20:18:53] * Compn goes afk before KotH explodes
[21:16:58] <bcoudurier> any gpg expert around ?
[21:20:59] <jannau> KotH: ping
[21:21:18] <KotH> pong
[21:30:42] <CIA-63> ffmpeg: aurel * r25297 /trunk/ (ffmpeg.c libavformat/cutils.c): ffmpeg: add a grow_array() helper function
[21:35:52] <CIA-63> ffmpeg: aurel * r25298 /trunk/ffmpeg.c: ffmpeg: dynamically allocate streamid_map
[21:37:07] <CIA-63> ffmpeg: aurel * r25299 /trunk/ffmpeg.c: ffmpeg: dynamically allocate input_files_ts_scale
[21:42:27] <CIA-63> ffmpeg: aurel * r25300 /trunk/ffmpeg.c: ffmpeg: dynamically allocate input_codecs
[21:52:03] <CIA-63> ffmpeg: aurel * r25301 /trunk/ffmpeg.c: ffmpeg: dynamically allocate output_codecs
[21:52:56] <CIA-63> ffmpeg: aurel * r25302 /trunk/ffmpeg.c: ffmpeg: dynamically allocate stream_maps
[21:55:15] <CIA-63> ffmpeg: aurel * r25303 /trunk/ffmpeg.c: ffmpeg: dynamically allocate bitstream_filters
[21:57:02] <CIA-63> ffmpeg: aurel * r25304 /trunk/ffmpeg.c: ffmpeg: replace MAX_STREAMS by an arbitrary sanity check
[22:13:50] <astrange> http://permalink.gmane.org/gmane.comp.gcc.patches/218529 that should replace some asm in bitstream.h
[22:37:36] <lu_zero> astrange: I got a strange sample of mpegts with aac ill formatted
[22:38:44] <lu_zero> it seems similar to a bug that had been fixed already
[22:41:26] * lu_zero tries to slice the sample since it is too big
[22:42:27] <jannau> lu_zero: or maybe just latm
[22:42:42] <lu_zero> jannau: it decodes fine till a point
[22:46:16] <jannau> iirc there is a sample on samples.mphq which switches midstream to latm
[22:47:20] <jannau> it was from japanese tv station
[22:47:32] <lu_zero> so that might also be the case
[22:50:09] <lu_zero> the message from ffmpeg is channel element 0.0 is not allocated
[22:51:07] <jannau> lu_zero: when does it happen? i don't want to load the full sample
[22:52:11] <lu_zero> 60-90mb are enough
[22:53:03] <jannau> link was too fast. already got 750M
[22:55:23] <lu_zero> ^^;
[22:55:56] <jannau> I'll look toomorrow at it and try to fix it if it's indeed latm
[22:56:21] <astrange> i don't know ts or aac
[22:56:29] <astrange> probably you want aconverse, but if it's latm the issue is known
[22:56:37] * lu_zero is too tired =_=
[22:56:49] <lu_zero> jannau: thank you =)
[22:57:19] <lu_zero> I got this strange report and I was wondering
[23:34:41] <spaam> vote time :)
[23:36:29] <kierank> spaam: http://www.youtube.com/watch?v=f-G4_y_2K_E
[23:40:41] <spaam> kierank: ok
[23:41:25] <kierank> i don't think even david dimbleby could survive our election
[23:44:06] <spaam> who did you vote for ? ;)
[23:44:41] <spaam> mru ? :)
[23:45:04] <kierank> i can't vote
[23:45:20] <spaam> to young ?