Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2010

1 participants
2 discussions

IRC log for 2010-10-01
by irc＠mansr.com 02 Oct '10

02 Oct '10

[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-… [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… [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.ht… [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-versu… [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_threa… [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 ?

1 0

IRC log for 2010-09-30
by irc＠mansr.com 01 Oct '10

01 Oct '10

[01:13:32] <astrange> http://pastebin.com/irns0w3w some list subscriber has a broken mail server [02:57:29] <BBB> Dark_Shikari: is there a command like movhps for mm registers? [06:21:51] <Dark_Shikari> "codec specific options are supported now" [06:21:52] <Dark_Shikari> _WHAT_ [06:26:34] <KotH> a wonderfull good morning everyone around the ffmpeg world [06:26:48] <thresh> good morning to you too [06:27:13] <peloverde> Dark_Shikari: Don't you know, different rules apply to different people [06:28:11] <ohsix> eventual realization is what happens to stubborn people [06:36:11] <KotH> günaydin cartman [06:41:49] <cartman> gÃŒnaydÄ±n KotH , dÃŒn Dedem vefat etti, cenazesi iÃ§in Giresun'daydÄ±k :( [06:42:01] <KotH> :-( [06:42:07] <KotH> basiniz sag olsun [06:42:14] <cartman> KotH: dostlar saÄolsun [06:51:22] <astrange> the one cutscene i've seen of halo reach was half in subtitled hungarian [06:51:30] <Dark_Shikari> lol [06:51:34] <astrange> maybe writing video players leads to writing space stations [06:51:56] <astrange> /w/win 25 [06:52:04] <astrange> i'm getting really bad at switching windows... [06:56:31] <cartman> yeah [08:38:28] <cartman> x86/deinterlace.asm:79: error: macho: sorry, cannot apply 32 bit absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and "dq _foo" for pointers. [08:38:34] <cartman> possibly for BBB [08:55:33] <KotH> boys, what can i do if i have two variants of the same function which i want to profile, but gprof has a higher stdev among runs of the same version, than between the two versions? [08:56:30] <lu_zero> KotH: perf is an option? [08:56:38] <kshishkov> flip a coin to determine which one to leave [08:57:00] <kshishkov> or run them more times (probably from a test program) [08:58:01] <KotH> lu_zero: perf? [08:58:30] <KotH> kshishkov: the stdev is so high, that i'd have to run it several 1000 times... with each run taking about 5min [08:59:19] <kshishkov> KotH: flip a coin then - totally fair resolution [09:00:10] <cartman> yasm error is due to mplayer's configure not using DPIC for yasm [09:00:19] <KotH> kshishkov: uhmm.. the tool is inaccurate, not the difference small [09:00:29] <kshishkov> try oprofile then [09:01:05] <_av500_> +1 [09:01:26] <lu_zero> http://perf.wiki.kernel.org/index.php/Main_Page [09:01:27] <KotH> domo [09:02:02] <lu_zero> like oprofile but somehow simpler to use [09:05:17] <lu_zero> KotH: another option is valgrind calltrace [09:07:58] <KotH> hmm.. right [09:07:59] <KotH> thanks [09:21:52] <Tjoppen> it seems the code related to dts_delta_threshold in ffmpeg isn't behaving quite properly [09:22:56] <Tjoppen> I had further mpegts remuxing woes today. one of the longer test files has a discontinuity in it, which ends up messing with the dvbsub timestamps enough to case non-monotonicity [09:23:06] <Tjoppen> *cause [09:25:28] <Tjoppen> luckily fixable by setting the threshold higher, but ffmpeg should complain louder and/or the code should be fixed [09:27:04] <_av500_> mru: i tried to take the troll further, but so far nobody bites :) [09:27:08] <_av500_> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [09:30:35] <mru> morning [09:30:40] <kshishkov> _av500_: you should've compared it to HTML handling more openly [09:31:25] <_av500_> jaja [09:32:08] <mru> html renderers are _too_ lenient [09:32:26] <Tjoppen> .. what? better support considered a bug? [09:32:35] <mru> html follows the motto, be generous with what you give and grateful for what you receive [09:33:19] <kshishkov> i.e totally not like tax office [09:33:35] <_av500_> Tjoppen: yes. it seems that if one creates webm to be actually mkv, one has to enforce it not being mkv, otherwise ppl will say, hey, its mkv.. [09:34:37] <Tjoppen> I'm not sure I follow [09:38:25] <mru> webm not being mkv is a bit like ubuntu not being canonical [09:41:49] <Tjoppen> I know that. but I'm a little curious why someone would considered something that works to be a bug [09:42:11] <_av500_> in order to have a clean separation between webm and mkv [09:42:30] <_av500_> because if it was not clear, ppl could start just using mkv [09:42:41] <Tjoppen> oh, I see. bondage and dicipline [09:42:48] <_av500_> ocourse [09:43:03] <_av500_> bow to thy masters [09:43:24] <Tjoppen> like java and its insisting on lots of stupid things [09:43:51] <Tjoppen> or python and its significant indentation [09:44:04] <Tjoppen> lunchtime [10:47:08] <thresh> now that you mentioned ffmpeg-devel is a source for bikesheds, I see them everywhere [10:52:14] <CIA-63> ffmpeg: stefano * r25267 /trunk/libavformat/avio.c: [10:52:14] <CIA-63> ffmpeg: Make register_protocol() use the function av_register_protocol2() [10:52:14] <CIA-63> ffmpeg: rather than av_register_protocol(), which is deprecated. [10:52:14] <CIA-63> ffmpeg: Fix the GCC warning: [10:52:14] <CIA-63> ffmpeg: avio.c: In function ?register_protocol?: [10:52:15] <CIA-63> ffmpeg: avio.c:93: warning: ?av_register_protocol? is deprecated (declared at avio.c:86) [10:56:00] <CIA-63> ffmpeg: stefano * r25268 /trunk/libavformat/avio.h: Document url_filesize(). [12:14:22] <wbs> mru: if I'd like to test an audio encoder (g722), but I'd need mono input test data (ffmpeg-synthetic/asynth1.sw is stereo), what's the best solution? [12:14:45] <wbs> I could either add -ac 1 to the ffmpeg command line, passing all data through the resampler, testing both that and the encoder at the same time [12:15:06] <wbs> or add -ac 1 to the input part, pretending that asynth1.sw is mono [12:15:08] <mru> we've talked about creating multiple test inputs [12:15:48] <wbs> yeah, justin added some code to the audiogen for that, but there's no current test using it yet [12:27:34] <CIA-63> ffmpeg: cehoyos * r25269 /trunk/libavcodec/dvdata.c: [12:27:34] <CIA-63> ffmpeg: Fix a yuv420p sample that was incorrectly detected as yuv411p [12:27:34] <CIA-63> ffmpeg: (576i50 25Mbps 4:1:1 special case was wrong). [12:27:34] <CIA-63> ffmpeg: Fixes issue2211 [12:27:34] <CIA-63> ffmpeg: Patch by Niobos, niobos dest-unreach be [14:26:10] <merbzt> Tjoppen: where did you get the 27Mhz timebase from ? [14:26:26] <merbzt> shouldn't it be 90kHz ? [14:27:06] <mru> 27MHz is the fundamental time base of the universe [14:27:33] * cartman would guess 42MHz [14:27:37] <_av500_> 54! [14:28:02] <kshishkov> _av500_: stop saying your age [14:28:02] <mru> _av500_: in turbo mode [14:28:15] <kierank> 54mhz because of interlaced [14:28:26] <mru> kierank: no [14:28:54] <kierank> yes, the universe accepted that interlaced is a hack [14:30:20] <kierank> so the universe had to double the time base like in h.264 [14:33:10] <Compn> bcoudurier : btw , you removed 'duplicated' m2v2, but m2v1 was the original entry... now i'm not sure which is correct m2v2 or m2v1. i only see m2v1 results in apple forums [14:33:31] <Compn> http://discussions.apple.com/thread.jspa?messageID=7988417 [14:51:59] <Tjoppen> merbzt: PCR is 27 MHz [14:52:29] <Tjoppen> or maybe there's a better word for it. you basically multiply be 300 [14:52:32] <Tjoppen> *by [14:53:01] <Tjoppen> also happens to be PAL's pixel clock IIRC [14:53:18] <mru> that's no coincidence [14:56:04] <Tjoppen> indeed. probably has to do with the PAL fields being non-integer number of lines too [14:56:15] <Tjoppen> the need for such a high precision that is [14:58:33] <Tjoppen> mostly the problem is the drift, but complying to the standard regarding jitter is probably a good idea too [15:24:36] <mru> wtf happened? gsm test is passing on ppc/gcc-4.2 now [15:33:19] <jb_OVC> BBB: saturday afternoon [15:37:57] <CIA-63> ffmpeg: aurel * r25270 /trunk/libavcodec/ (resample.c avcodec.h utils.c): add FF_API_AUDIO_OLD define to disable the deprecated decode_audio API [15:56:07] <BBB> jb_OVC: are you there friday? [15:56:14] <BBB> bcoudurier: same question for you [15:57:10] <kierank> troll xiph for me [15:57:40] <_av500_> at ovc xiph trolls you [15:57:49] <lu_zero> BBB: all ready? [15:58:12] <BBB> for what? [15:58:13] <kierank> _av500_: xiph troll by definition of their existence [16:03:22] <BBB> lu_zero: ? [16:04:01] <BBB> who's dave rice btw? [16:04:09] <BBB> merbanan: and did you end up deciding to go or not? [16:06:54] <lu_zero> BBB: the snagon presentation [16:07:17] <lu_zero> just to make the xiph people at ease [16:07:19] <jb_OVC> BBB: yes, of course [16:07:19] <jb_OVC> e [16:07:45] <jb_OVC> kierank: trolling xiph is the reason of this conf, no? [16:13:55] <BBB> lu_zero: who's presenting then? [17:38:52] <lu_zero> kshishkov: ping [18:03:37] <bcoudurier> Compn, m2v1 is correct [18:13:22] <CIA-63> ffmpeg: bcoudurier * r25271 /trunk/libavformat/isom.c: Correct tag is m2v1 [19:20:18] <_av500_> kshishkov: berlin did not explode today [19:23:39] <mru> oh well, maybe next time [19:26:23] <_av500_> mru: http://www.ccs.neu.edu/home/bchafy/lood.html scroll down for some really old school video walling :) [19:27:00] <Compn> _av500_ : is anyone scared of the vague threads against germany, france and u.k.? [19:27:03] <Compn> threats* [19:29:23] <_av500_> they found a 500kg bomb in berlin today it seems [19:29:31] <_av500_> an olde one [19:29:36] <mru> yes, from ww2 [19:29:50] <mru> american, no less [19:30:05] <_av500_> not an ukranian make it seems [19:30:50] <thresh> not russian? shame [19:37:03] <astrange> http://news.cnet.com/8301-30685_3-20018146-264.html hey, it's vp8 I-frames [19:37:25] <mru> and of course h264 intra beats it [19:37:30] <mru> but they're not talking about that [19:37:32] <astrange> Dark_Shikari: you missed the opportunity to advertise --tune stillimage [19:37:55] <skal> arf [19:38:00] <mru> h264 lossless intra isn't too bad either [19:38:08] <skal> ffmpeg patch on its way [19:38:51] <Dark_Shikari> astrange: no [19:38:53] <Dark_Shikari> avc intra isn't a still image [19:39:10] <Dark_Shikari> oh. you mean as an image format? [19:39:12] <astrange> yes [19:39:14] <Dark_Shikari> I did advertise it, repeatedly [19:39:20] <astrange> did it get its own blog post? [19:39:21] <Dark_Shikari> nobody listened. "jpeg is good enough" [19:39:26] <Dark_Shikari> hmm. it probably should have [19:39:39] <Dark_Shikari> I don't really care [19:40:56] * _av500_ waits for webE, the "nw shrtr nglsh lngg tht mks wbsts s mch smllr" [19:41:20] <mru> webTXT [19:41:37] <_av500_> and finally webWEB [19:41:50] <_av500_> the all new closed garden aol, err google web [19:42:13] <astrange> http://www.chromium.org/spdy/spdy-whitepaper [19:42:53] <Compn> wow [19:43:05] <Compn> so google figured out wavelet image compression? [19:43:45] <Dark_Shikari> mru: h264 lossless intra kinda sucks [19:43:54] <Dark_Shikari> I mean it's not terrible, but compared to ffv1... [19:44:00] <_av500_> ...One convenient feature of WebP is that any hardware that supports WebM video encoding or decoding also supports WebP.... [19:44:11] <mru> Dark_Shikari: I meant compared to png [19:44:21] <mru> or lossless jpeg [19:44:35] <mru> _av500_: lol [19:44:42] <Dark_Shikari> png wins for things where zlib does better [19:44:49] <Dark_Shikari> i.e. repetitive patterns [19:44:58] <mru> yeah [19:45:01] <mru> but not photos [19:45:22] <Dark_Shikari> yeah, but who losslessly compresses photos? [19:45:49] <thresh> well huh [19:45:54] <thresh> everyone who shoots raw [19:47:21] <skal> http://pastebin.com/FbUvG77M [19:47:36] <skal> .. but foude, first [19:47:39] <Dark_Shikari> thresh: you want to compress before debayering first [19:48:12] <Dark_Shikari> skal: let's get support in IE, first, ok? [19:48:21] <Dark_Shikari> also, can you add h264 to that list? [19:48:25] <Dark_Shikari> if you don't, I will commit support for it [19:48:42] <bcoudurier> Dark_Shikari, I'm tryint to get AVCIntra 50 working in ffmpeg but having segv, it works with cli x264 though [19:48:47] <thresh> Dark_Shikari: isnt it the same as on digital video camera though? [19:48:49] <Dark_Shikari> bcoudurier: of course it segfaults [19:48:54] <Dark_Shikari> ffmpeg is giving x264 the wrong input [19:48:59] <Dark_Shikari> high-bit-depth x264 requires high-bit-depth input [19:49:01] <Dark_Shikari> i.e. 16-bit input [19:49:01] <bcoudurier> I changed that [19:49:03] <Dark_Shikari> i.e. twice the input frame size [19:49:06] <bcoudurier> I did the modifications [19:49:09] <Dark_Shikari> well, actually, 10-bit input [19:49:13] <Dark_Shikari> bcoudurier: pastebin? [19:49:16] <bcoudurier> I give yuv420p16 [19:49:21] <bcoudurier> and set HIGH_CSP [19:49:27] <Dark_Shikari> still wrong. it requires 10-bit input [19:49:31] <Dark_Shikari> the high 4 bits of each pixel must be zero [19:49:31] <skal> yeah, let's get IE support for html5 [19:49:43] <Dark_Shikari> skal: imo a new image format is much more useful than html5 [19:49:56] <Dark_Shikari> html5 is just a new way to put Flash effects into my browser in a way I can't block [19:50:12] <Compn> heh [19:50:22] * Compn wonders how much x264 is going to pay for 10bit swscale [19:50:41] <Dark_Shikari> er, why do we need it? [19:50:43] <Dark_Shikari> we already wrote our own [19:50:47] <Dark_Shikari> it's already committed [19:50:56] <Compn> ah [19:51:08] <bcoudurier> http://pastebin.com/7iRg4y0n [19:52:23] <CIA-63> ffmpeg: aurel * r25272 /trunk/libavcodec/ (avcodec.h utils.c): add FF_API_VIDEO_OLD define to disable the deprecated decode_video API [19:52:59] <_av500_> Dark_Shikari: yeah, ff html5_block extension :) [19:53:03] <bcoudurier> you need to pass exactly 10 bits stored in 16 ? [19:53:50] <bcoudurier> but with the cli it didn't segfault for the same input [19:54:24] <bcoudurier> does cli assume 16in16 and convert ? [19:54:54] <merbanan> BBB: not going [19:55:07] <BBB> :( [19:55:13] * _av500_ wonder if there will be MwebP? [19:55:27] <bcoudurier> anyway I wish > 8 bit for libswscale to be funded [19:55:34] <bcoudurier> only pros uses 10 bits [19:59:26] <Compn> make ffmpeg for pros, charge $10k/license and make some money on support ? [19:59:27] <Compn> ehe [20:02:04] <bcoudurier> Compn, kinda, though $10k per license might be a bit much :> [20:02:49] * Compn wonders what a blackmagic license goes for [20:02:51] <cartman> bcoudurier: whats this "10 bit" thing? [20:04:03] <Compn> ooh there is 12 bit too [20:06:45] <bcoudurier> d-cinema is 12 bits [20:07:25] <cartman> bcoudurier: what does the bit count represent? [20:07:39] <bcoudurier> bit depth [20:08:12] <cartman> I thought 24/32 bit depth was usual , at least for images [20:08:41] <bcoudurier> 12 bits is 121212, 36 [20:10:08] <cartman> uh oh :> [20:10:12] <Compn> cartman : its pretty confusing, checkup wikipedia [20:10:18] * Compn has no idea about all these bits [20:10:20] <cartman> Compn: title? :D [20:10:22] * Compn should stfu :D [20:10:28] <cartman> 888 is 24 then [20:13:42] <CIA-63> ffmpeg: aurel * r25273 /trunk/libavcodec/ (avcodec.h utils.c): add FF_API_SUBTITLE_OLD define to disable the deprecated decode_subtitle API [20:15:02] <twnqx> uau: is the git frontend right? no commits for the past two months? :S [20:15:16] <twnqx> ugh, misclicked [20:16:02] <_av500_> twnqx: yep, development is over :) [20:16:13] <twnqx> :( [20:16:45] <_av500_> it will be resumed once asm vs yasm is settled [20:20:50] <Dark_Shikari> bcoudurier: yes you need 10 in 16 [20:20:52] <wbs> didn't you get the memo? everything that can be invented already is invented.. so stop coding ;P [20:20:53] <Dark_Shikari> the CLI will convert for you [20:20:59] <Dark_Shikari> the CLI will support any bit depth from 8 to 16 if you tell it (for raw input) [20:21:01] <bcoudurier> ok [20:21:13] <bcoudurier> it assumes 16 by default right ? [20:21:40] <Dark_Shikari> no, probably 8 [20:22:00] <Dark_Shikari> --input-depth [20:23:41] <bcoudurier> weird, it did work though [20:24:11] <Dark_Shikari> http://www.mediafire.com/download.php?hookw5pxqcsmfb5 [20:24:15] <Dark_Shikari> here's a 10-bit encode in avc-intra [20:24:17] <bcoudurier> anyway I got the shit working in fcp [20:24:17] <Dark_Shikari> from x264 [20:24:21] <bcoudurier> using .mov [20:24:21] <Dark_Shikari> awesome [20:24:25] <Dark_Shikari> sweet [20:24:31] <Dark_Shikari> does it pass it through, i.e. not re-encode? [20:24:34] <bcoudurier> but cannot commit to ffmpeg since it doesn't work :P [20:24:38] <bcoudurier> it does pass trough [20:24:45] <Dark_Shikari> sweet, so our avc-intra does acutally work [20:25:01] <Dark_Shikari> pastebin your ffmpeg patch [20:25:01] <bcoudurier> ah no I didn't test using x264 encode [20:25:03] <Dark_Shikari> and I'll look at it [20:25:04] <bcoudurier> let me test [20:25:11] <Dark_Shikari> oh btw, here's the problem with ffmpeg [20:25:13] <bcoudurier> I did send it [20:25:18] <Dark_Shikari> ffmpeg cannot choose compatible CSPs on runtime [20:25:21] <bcoudurier> but p16 is actually 16 bits [20:25:28] <Dark_Shikari> iirc [20:25:34] <Dark_Shikari> bcoudurier: so copy x264's dithering code [20:25:43] <Dark_Shikari> your pix_fmts is wrong. x264 only supports one of the two [20:25:47] <CIA-63> ffmpeg: stefano * r25274 /trunk/libavfilter/vsrc_nullsrc.c: Return AVERROR(EINVAL) rather than -1 in case of invalid values. [20:25:48] <Dark_Shikari> it has to pick between them on _runtime_. [20:25:50] <Dark_Shikari> ffmpeg's API can't do this [20:25:56] <bcoudurier> I don't get it [20:26:19] <Dark_Shikari> a given compile of x264 can ONLY take 16-bit or 8-bit, not both. [20:26:22] <bcoudurier> yes [20:26:26] <Dark_Shikari> ffmpeg does not know what x264 supports until _RUNTIME_. [20:26:28] <bcoudurier> do you export that in the header ? [20:26:33] <bcoudurier> you should if it's compile time [20:26:40] <Dark_Shikari> No, we export it as extern x264_bit_depth; [20:26:44] <bcoudurier> then it's only a matter of #ifdef [20:26:48] <Dark_Shikari> I did not want to hack the installed headers [20:26:51] <bcoudurier> compile time stuff should be in .h [20:27:04] <Dark_Shikari> all the devs agreed that header hacking was bad [20:27:06] <Dark_Shikari> even ffmpeg doesn't do header hacking [20:27:13] <bcoudurier> what do you mean header hacking ? [20:27:17] <bcoudurier> x264.h [20:27:19] <Dark_Shikari> modifying .h files on compile time [20:27:27] <bcoudurier> what ? [20:27:36] <bcoudurier> we are creating them at compile time [20:27:38] <bcoudurier> like the version [20:27:42] <Dark_Shikari> that counts as modification [20:27:48] <bcoudurier> that's what we do [20:27:49] <Dark_Shikari> ffmpeg does not install config.h [20:27:54] <Dark_Shikari> that isn't an installed header [20:28:04] <Dark_Shikari> ffmpeg does not modify avcodec.h on compile time [20:28:27] <Dark_Shikari> anyways I don't want to add yet another way that ffmpeg and x264 can be incompatibly linked. [20:28:29] <bcoudurier> I don't agree with this [20:28:32] <Dark_Shikari> ffmpeg should be able to switch on runtime. [20:28:59] <bcoudurier> besides that's wrong [20:29:03] <bcoudurier> because avconfig.h is installed [20:29:11] <Dark_Shikari> ok, true, but you don't modify avcodec.h [20:29:13] <bcoudurier> and it contains AV_HAVE_BIGENDIAN 0 [20:29:15] <Dark_Shikari> you're proposing we add x264config.h [20:29:30] <Dark_Shikari> Now, anyways, how does avcodec define stride for 16-bit? [20:29:45] <Dark_Shikari> in x264, stride is the number of bytes required to reach the next row of the frame. [20:29:52] <Dark_Shikari> NOT the number of pixels [20:30:21] <bcoudurier> yes [20:30:24] <Dark_Shikari> hence the image being uint8_t * even in high bit depth [20:30:33] <bcoudurier> that's the case I think [20:30:40] <Dark_Shikari> next, are you sure x264 is getting 16-bit input? your pixfmt line allows both 16-bit and 8-bit. [20:30:45] <bcoudurier> but obvioulsy the high 4 bits are set [20:30:52] <Dark_Shikari> Add a 4-line for loop. [20:30:59] <Dark_Shikari> for( int y = 0; y < height; y++ ) [20:31:04] <Dark_Shikari> for( int x = 0; x < width; x++ ) [20:31:28] <Dark_Shikari> image->data[plane][x+y*stride] = image->data[x+y*stride] + 8 >> 4; [20:31:29] <Dark_Shikari> etc etc [20:31:47] <bcoudurier> yep let me try this [20:32:04] <bcoudurier> btw I also got open gop working in .mov [20:32:08] <bcoudurier> it's fun how quicktime works :> [20:32:13] <Dark_Shikari> heh [20:32:33] <CIA-63> ffmpeg: aurel * r25275 /trunk/libavcodec/ (avcodec.h flacenc.c options.c): add FF_API_USE_LPC define to disable the deprecated AVCodecContext.use_lpc field [20:32:37] <Dark_Shikari> btw your other changes are ok, commit those [20:32:39] <Dark_Shikari> e.g. opengop [20:32:52] <bcoudurier> there is an API change here [20:32:58] <bcoudurier> I need to consult others :> [20:33:13] <bcoudurier> and you need special stuff in mov muxer as well [20:33:20] <Dark_Shikari> ok, commit the keyframe thing then? [20:33:34] <Dark_Shikari> also someone is adding SEI recovery point support to VLC, we should add it to avcodec too [20:35:24] <CIA-63> ffmpeg: aurel * r25276 /trunk/libavcodec/ (opt.c opt.h avcodec.h): add FF_API_SET_STRING_OLD define to disable the deprecated av_set_string API [20:36:01] <bcoudurier> the keyframe is an API change [20:36:40] <skal> Dark: sesse? [20:36:46] <bcoudurier> ah well explicitely 1 is mentioned in avcodec.h doxy [20:36:51] <bcoudurier> so I guess 2 is just an extension ;) [20:36:53] <Dark_Shikari> what does keyframe=2 mean? [20:37:56] <skal> oh, Steinar it is [20:38:16] <cartman> ooooh WebP [20:38:29] <cartman> what a lame name [20:38:57] <_av500_> webSingleFrameVP8 [20:39:05] <Dark_Shikari> webpatentmine [20:39:07] <Dark_Shikari> webh264ripoff [20:39:13] <Dark_Shikari> webmatroska [20:39:14] <bcoudurier> means I frame but not IDR [20:39:23] <Dark_Shikari> bcoudurier: but that can mean different things depending on the context [20:39:33] <Dark_Shikari> What matters is recovery points [20:39:42] <Dark_Shikari> It is completely useless to tell the calling app about non-IDR I-frames [20:39:47] <Dark_Shikari> it is critical to tell the calling app about recovery points. [20:39:54] <bcoudurier> it is necessary for the muxer [20:39:57] <cartman> putting "web" into everything is just stupid [20:40:01] <Dark_Shikari> bcoudurier: why? [20:40:04] <bcoudurier> quicktime don't care about recovery poitns [20:40:09] <bcoudurier> but care about "partial key frames" [20:40:18] <Dark_Shikari> er... then it should detect that there is a recovery point [20:40:21] <Dark_Shikari> and mark it [20:40:22] <Dark_Shikari> in the mux [20:40:31] <bcoudurier> it doesn't mark recovery points [20:40:37] <Dark_Shikari> Did you read what I just said [20:40:39] <Dark_Shikari> wait, no, of course not. [20:40:44] <Dark_Shikari> I said, have the MUXER read recovery points [20:40:46] <Dark_Shikari> and MARK them in the mov file [20:40:52] <bcoudurier> I could do that [20:40:56] <Dark_Shikari> Here's why your method is completely wrong [20:41:01] <Dark_Shikari> Not all I-frames are recovery points. [20:41:01] <bcoudurier> but it's painful because I have to parse the bitstream [20:41:03] <CIA-63> ffmpeg: aurel * r25277 /trunk/libavcodec/ (avcodec.h options.c): add FF_API_INOFFICIAL define to disable the deprecated 'inofficial' flag [20:41:15] <Dark_Shikari> No you don't. You can just export them in the API. [20:41:36] <Dark_Shikari> and furthermore, not all recovery points are instant [20:41:42] <Dark_Shikari> some recovery points have recovery times not equal to zero [20:41:51] <Dark_Shikari> which, iirc, can be expressed in mov/mp4 [21:00:03] <jannau> Dark_Shikari: ffmpeg should set convergence_duration for SEI recovery points [21:00:47] <Dark_Shikari> it shouldn't output frames until the recovery is complete imo [21:00:55] <Dark_Shikari> when you seek [21:00:55] <Dark_Shikari> etc [21:02:32] <jannau> no, it's not. convergence_duration is always 0 [21:02:54] <jannau> except for TEXT subtitles in .mkv [21:05:00] <astrange> that's a bug in matroska demuxer [21:10:23] <jannau> and a bug in the h264 parser [21:39:54] <wbs> uhm, this is interesting... I found some random opensource project.. that bundles the undistributable amr-nb reference code [21:40:24] <wbs> and in a later commit, the author adds his own gpl copyright header, and a notice that " Permission to distribute, modify and use this file under the standard license [21:40:27] <wbs> 28 terms listed above has been obtained from the copyright holder." [21:41:11] <mru> I'd verify that before trusting it [21:41:17] <wbs> yeah [21:41:37] <wbs> the "permission has been granted" clause is exacty the same as in opencore, but there the license is apache [21:41:54] <wbs> so the question is, is this someone who has negotiated a proper deal, or just ignorant? :-) [21:42:21] <wbs> http://code.google.com/p/siphon/source/diff?spec=svn605&r=605&format=side&p… [21:42:30] <mru> who owns the copyright? [21:43:08] <wbs> I guess the 3gpp owns it [21:43:17] <mru> but who is that? [21:43:36] <mru> getting code like that relicensed usually takes a lot of legal wrangling [21:43:47] <wbs> yeah [21:43:56] <wbs> I can imagine google/android/packetvideo managing to do it, for opencore [21:44:14] <mru> yeah, but not some random guy [21:44:26] <wbs> but "Samuel <samuelv0304(a)gmail.com>" doing it, naming it "AMR codec for iPhone and iPod Touch", sounds a bit fishy [21:44:52] <mru> the standard reply would be "sorry, we don't know who owns the rights to that, and we won't spend our time tracking it down" [21:45:02] <wbs> yeah [21:45:17] <Dark_Shikari> fun fact [21:45:25] <wbs> I'm mostly annoyed by having spent a lot of time on that issue, doing the opencore-amr wrapper and all, trying to play by the book [21:45:30] <Dark_Shikari> mozilla turned down google on "webp" [21:45:50] <wbs> and then some joe random just blatantly ignores all common sense and slaps his own copyright on it and thinks it's all right [21:46:11] <mru> Dark_Shikari: but xiph don't have their own dreadful image format... [21:46:24] <kierank> mru: they'll make one in ogg, just wait and see [21:46:27] <mru> wbs: welcome to life [21:46:41] <Dark_Shikari> no, they think jpeg is fine [21:49:11] <Dark_Shikari> btw, this means we can reject skal' [21:49:14] <Dark_Shikari> *skal's patch. [21:49:49] <wbs> mru: yeah, I know. boo hoo and all that. I guess I should grow a beard and become more grumpy and cynical :-) [21:51:37] <mru> you can be cynical without being grumpy [21:51:53] <Dark_Shikari> tell that to yourself [21:51:54] <Dark_Shikari> ;) [21:52:01] <wbs> hah :-) [21:52:21] <mru> do you think I'm grumpy? [21:55:31] <BBB> I thought I was grumpy [21:56:11] <Dark_Shikari> no this is grumpy [21:56:12] <Dark_Shikari> http://i679.photobucket.com/albums/vv159/Fireinferno225/Grumpy.jpg [21:57:15] <kierank> mru isn't grumpy, he's just a troll [21:58:25] <CIA-63> ffmpeg: michael * r25278 /trunk/ (5 files in 2 dirs): [21:58:25] <CIA-63> ffmpeg: av_assert() system. [21:58:25] <CIA-63> ffmpeg: With this the developer can now choose if he wants an assert always enabled or at which [21:58:25] <CIA-63> ffmpeg: compile time assert level. This can thus replace the #define NDEBUG hacks [21:59:24] <mru> I tried to do that years ago [21:59:27] <mru> michael rejected it [21:59:41] <Dark_Shikari> big, all-encompassing changes are fine if michael does them. [21:59:47] <Dark_Shikari> if anyone else does them, they're bad. [22:01:27] <BBB> Dark_Shikari: will you port my pred16x16/8x8plane to x264 or should I do it? [22:01:37] <BBB> (I think it's nominally faster) [22:02:16] <Dark_Shikari> I don't support replacing any code that isn't faster. [22:02:28] <Dark_Shikari> That is, don't touch any of the function except the relevant parts that you think should be changed. [22:02:40] <Dark_Shikari> and then confirm via checkasm that it's faster [22:03:14] <BBB> hm, well, x264's 16x16plane is a c+asm combination mess so I could just as well not touch it I guess... [22:03:32] <Dark_Shikari> Er.... [22:03:34] <Dark_Shikari> just replace the asm function [22:03:45] <Dark_Shikari> you already read the asm anyways and copied it [22:03:52] <Dark_Shikari> your change is eliminating the C part [22:04:04] <BBB> the asm is different also [22:04:12] <BBB> (and might well be slower) [22:04:13] <Dark_Shikari> different != better [22:04:15] <BBB> right [22:04:21] <Dark_Shikari> I do not want you to make things slower [22:04:28] <Dark_Shikari> this means you must demonstrate yours is faster [22:04:41] <Dark_Shikari> the function consists of 4 parts: [22:04:44] <Dark_Shikari> 1) horizontal sum/math [22:04:46] <Dark_Shikari> 2) vertical sum/math [22:04:51] <Dark_Shikari> 3) plane calculation [22:04:53] <Dark_Shikari> 4) main loop [22:04:54] <BBB> fair enough, I'll see when I get to that, so first c->asm and then assure which of the asms are faster [22:05:02] <Dark_Shikari> all must be equal or faster in your function. [22:06:07] <BBB> I gotta admit you guys are super-methodical [22:06:10] <BBB> a little bit anal also [22:06:33] <Dark_Shikari> tl;dr I don't want slower code [22:06:40] <Dark_Shikari> You can start by porting yours to x264 and just plain timing it [22:06:51] <Dark_Shikari> I don't trust timings unless they're done in exactly the same way [22:07:10] <jannau> argh, /me suspects he knows why the h264 parser doesn't set convergence_duration [22:07:43] <Dark_Shikari> BBB: I'm much more anal about these things when you're replacing something already believed to be 'good' [22:07:44] <jannau> Dark_Shikari: is there a way to convert frame_num increments to time? [22:07:54] <Dark_Shikari> poc. not frame num. [22:08:07] <Dark_Shikari> but why? [22:08:39] <BBB> Dark_Shikari: got it, will do, don't expect it today though [22:13:13] <jannau> recovery_frame_cnt is in frame_num increments: "All decoded pictures in output order are indicated to be (approx) correct starting at the output order position of the reference picture having the frame_num equal to the frame_num of the VCL NAL units for the current access unit incremented by recovery_frame_cnt in modulo MaxFrameNum arithmetic." [22:14:50] <Dark_Shikari> oh. wow. this means I have recovery_frame_cnt wrong in x264 if b-frames are on. [22:15:04] <Dark_Shikari> let me fix that [22:15:25] <astrange> ye5 [22:15:51] <Dark_Shikari> hmm. it's not wrong, just overestimates. [22:16:29] <Dark_Shikari> ok, I don't care about that anyways [22:16:39] <Dark_Shikari> jannau: then h264 is incompatible with how ffmpeg (and x264) want it [22:16:39] <jannau> could be wrong if you do the modulo MaxFrameNum [22:16:59] <Dark_Shikari> the only way to handle it right is to do it in the decoder [22:17:07] <Dark_Shikari> and tell the caller when it's converged [22:53:19] <CIA-63> ffmpeg: michael * r25279 /trunk/libavutil/assert.h: typo [23:21:54] <mru> does that mean he added a typo? [23:44:10] <mru> am I the only one who thinks michael should follow the same rules as everybody else? [23:44:41] <Dark_Shikari> he's the BDFL, he apparently makes the rules [23:45:06] <mru> he also makes special rules for himself [23:45:46] <spaam> special people need special rules.. [23:45:59] <mru> frankly, I think it's time he was removed from this "leader" position [23:46:31] <ohsix> MUTINY! [23:46:37] <mru> call it what you want [23:46:45] <spaam> mru: so who will be the leader? you? [23:46:53] <mru> why do we need a leader? [23:47:07] <ohsix> lord of the flies [23:47:28] <mru> nothing would change, except that michael no longer has an excuse for being an arse and ignoring rules [23:48:03] <spaam> did you try to say that to him? [23:48:08] <mru> repeatedly [23:48:49] <ohsix> will there still be rules when there is no leader [23:49:07] <Dark_Shikari> woohooo [23:49:12] <Dark_Shikari> now google comes to force webp into ffmpeg [23:49:14] <mru> we will folow the rules we all make [23:49:17] <Dark_Shikari> despite it not actually existing yet [23:49:25] <Dark_Shikari> or supported by anyone besides google [23:50:42] <Dark_Shikari> I think we should add support for file formats when they are used, not when they are declared to exist. [23:50:52] <Dark_Shikari> (particularly encoding support) [23:51:24] <ohsix> so are you the chicken or the egg [23:51:39] <Dark_Shikari> there's no chicken/egg paradox. [23:51:45] <Dark_Shikari> if for example, firefox said "we're supporting webp all the way" [23:51:52] <Dark_Shikari> then you have the chicken. now we can make the egg. [23:51:57] <Dark_Shikari> But Mozilla rejected it. [23:52:00] <Dark_Shikari> So now you have a dead chicken. [23:52:04] <Dark_Shikari> And dead chickens can't lay eggs. [23:52:13] <mru> we can have a bbq [23:52:29] <Dark_Shikari> hmm, good point. dead chickens make for good sandwiches [23:54:10] <BBB> "webp"? [23:54:15] <BBB> what on earth are they smoking [23:54:19] <BBB> is jpeg encumbered? [23:54:25] <mru> no [23:54:27] <BBB> or did one of their engineers have too much crackpot? [23:54:30] <ohsix> jpeg is oldschool though [23:54:41] <BBB> if it's old, it must be bad!12 [23:54:42] <mru> jpeg isn't exactly the most efficient format [23:54:50] <Dark_Shikari> BBB: they are trying to push their shit on everyone else [23:54:55] <ohsix> this sort of thing isn't unprecedented, during the jpeg2k stuff everyone had their pet image format, even microsoft [23:55:04] <BBB> they all fail [23:55:06] <mru> jpeg-xr [23:55:06] <Dark_Shikari> ohsix: HD Photo was just an h264 ripoff though [23:55:09] <Dark_Shikari> with i16x16 blocks only [23:55:29] <Dark_Shikari> 09:55 < ubitux> revision 25278 has introduced some linkage error: ffmpeg/libavutil/libavutil.a(mathematics.o): In function `av_rescale_rnd' << undefined reference to `assert' [23:55:32] <Dark_Shikari> lol michael broke things again [23:55:47] <mru> as I said, he should follow the fucking rules [23:55:52] <Dark_Shikari> BBB: pretty much. this is getting really fucking obnoxious [23:55:56] <ubitux> maybe it's something in mplayer i don't know [23:56:00] <Dark_Shikari> I mean, first it was vp8 [23:56:01] <Dark_Shikari> then it was webm [23:56:02] <Dark_Shikari> now it's webp [23:56:07] <ubitux> but since there is some assert edit in ffmpeg [23:56:09] <BBB> vp8 is fine [23:56:13] <ubitux> ffmpeg still build correctly [23:56:14] <Dark_Shikari> they're trying to use their own custom proprietary formats to displace everything [23:56:21] <mru> ubitux: michael fuckedup [23:56:23] <mru> again [23:56:27] <ubitux> ok ok :p [23:56:27] <skal> Dark: proprietary? [23:56:38] * BBB will not update to latest svn for a while until assert.h is gone [23:56:38] <Dark_Shikari> skal: absolutely. it was developed without any community input or standardization process. [23:56:41] <Dark_Shikari> Therefore, it's proprietary [23:56:41] <ohsix> how stern was moz's rejection, if they've already got vpx there and someone prepares patches to add it to libpr0n are they just going to go with it? [23:56:42] <mru> I already pointed out his stupid mistake [23:56:45] <Dark_Shikari> proprietary is a development process [23:56:47] <Dark_Shikari> not a state of being [23:56:51] <skal> doesn't make it proprietary [23:56:54] <Dark_Shikari> Google has declared that "this is webp" [23:56:57] <Dark_Shikari> therefore, it's proprietary [23:57:11] <Dark_Shikari> controlled by one company == proprietary [23:58:05] <skal> launched by one company [23:58:07] <skal> not owned [23:58:10] <Dark_Shikari> no, controlled [23:58:14] <Sho_> Dark_Shikari: Mozilla rejected it? link? [23:58:23] <Dark_Shikari> How can you claim that google is not going to control this? [23:58:25] <Dark_Shikari> you control vp8 [23:58:26] <Dark_Shikari> you control webm [23:58:35] <Dark_Shikari> you haven't let anyone else have input into the standardization process [23:58:45] <Dark_Shikari> if webp will be different, you need proof [23:58:49] <mru> you mean bitstream guidance process [23:58:53] <Dark_Shikari> lol [23:59:09] <Dark_Shikari> Sho_: source is xiph.

1 0