[01:19:52] <Dark_Shikari> we just had the first bug report on win64 due to an application not saving the callee-save xmm registers [01:20:07] <Dark_Shikari> a data value that *was* 0 got changed to "not 0" by an external lib [01:20:14] <Dark_Shikari> Probably Avisynth or ffmpeg via Avisynth. [01:20:43] <Dark_Shikari> Given how much of a bitch this was to track down, I would like: [01:21:01] <Dark_Shikari> Either 1) Drop ffmpeg win64 support until it actually works. The fact that it even configures to build is wrong. [01:21:06] <Dark_Shikari> or 2) fix the bloody thing [01:21:24] <mru> you know what 2 entails [01:21:56] <Dark_Shikari> it means adding a few xmm clobbers [01:22:07] <Dark_Shikari> we can do #define WIN64_CLOBBERS [01:22:13] <Dark_Shikari> and define it to nothing if it isn't win64 [01:22:21] <Dark_Shikari> and define it to the xmm clobbers if it is [01:22:25] <mru> does it hurt to always mark them? [01:22:26] <Dark_Shikari> or whatever. [01:22:30] <Dark_Shikari> .... probably [01:22:38] <Dark_Shikari> The vast majority of asm doesn't use any more than the standard 8 xmm regs though [01:22:48] <Dark_Shikari> thus a max of two to mark [01:22:58] <mru> I mean does it hurt to mark as clobbered the regs that actually are clobbered? [01:23:10] <Dark_Shikari> I doubt it, it just forces gcc to save them [01:23:20] <Dark_Shikari> which obviously hurts speed a bit, but that's required by the abi [01:23:26] <mru> will gcc save them even if it wasn't using them? [01:23:37] <mru> on linux [01:23:40] <Yuvi> it shouldn't on non-win64 abis [01:23:48] <Yuvi> (not actually tested) [01:23:48] <Dark_Shikari> oh, true, you're saying we could _always_ set them on clobber [01:23:50] <mru> shouldn't != doesn't [01:24:00] <Dark_Shikari> yeah, that could work. [01:24:13] <mru> if the code does clobber them, it should say so [01:24:19] <Dark_Shikari> either way, imo we should drop it right now from configure [01:24:20] <mru> anything else is a dangerous gamble [01:24:24] <Dark_Shikari> it would give people an incentive to fix it [01:24:35] <Dark_Shikari> rather than currently where we pretend that it works when it doesn't [01:27:55] <mru> how hard is it to find the places that need fixing? [01:29:11] <Dark_Shikari> every block of sse asm in ffmpeg [01:29:13] <Dark_Shikari> grep "xmm" [01:30:54] <Dark_Shikari> well, I got ramiro to drop 64-bit builds [01:32:08] <mru> 1275 lines containing %%xmm [01:32:58] <Dark_Shikari> Have fun :) [01:41:16] <bcoudurier> is there any way to get more precision that ms in matroska ? [01:42:44] <bcoudurier> I'm not sure I understand the code [01:43:32] <Yuvi> bcoudurier: matroska has a fixed timebase of x/1e9 [01:44:05] <Yuvi> so you could set it to something else, but I don't see much point since it's very unlikely to be accurate anyway [01:46:36] <bcoudurier> so how come our demuxer output ms timestamps ? [01:47:05] <Yuvi> oh, basically all mkv files in existence use 1/1000 as the timebase [01:47:20] <Yuvi> thought you were asking about creating them [01:47:27] <Yuvi> and yes, only one timebase per file [01:51:30] <bcoudurier> that's is crappy [01:51:41] <bcoudurier> using ms is very bad for audio [01:52:18] <bcoudurier> anyway, the more I understand mkv the less I understand why people use it [01:52:36] <Yuvi> mkvmerge [01:52:40] <Yuvi> that's pretty much it [01:52:55] <mru> it existed at the right time [01:53:00] <Yuvi> that too [01:53:17] <bcoudurier> we really missed an opportunity [01:53:19] <mru> avi was dead, and there wasn't much else [01:53:30] <bcoudurier> too bad I wasn't knowing shit about video at that time [01:53:37] <mru> for a while people were messing with ogm [01:53:42] <mru> thankfully they gave up on that [01:54:13] <bcoudurier> what's the biggest shortcoming of mkv in terms of usage/features [01:54:29] <mru> it's too fucking complicated [01:54:37] <mru> there are three ways of doing everything [01:55:47] <bcoudurier> well the user doesn't know about that, there are good tools [01:56:17] <Yuvi> in terms of implementations, probably that most demuxers can't seek without an index [02:01:57] <bcoudurier> humm audacity stalls for like 30 secs when loading a 40 min wav file [02:02:06] <bcoudurier> good job guys [02:03:30] <peloverde> audacity is bit of a mess [02:09:35] <Dark_Shikari> bcoudurier: the reason is simple: good tools, good support for the formats people wanted to use [02:09:44] <Dark_Shikari> at the right time. [02:10:33] <bcoudurier> ah, peloverde, how are you ? could you please tell me what channel layout aac use by default ? [02:11:04] <Yuvi> hm, apparently {} means something weird by default in inline asm [02:11:15] <mru> hmm? [02:11:21] <Yuvi> http://llvm.org/bugs/show_bug.cgi?id=6780 [02:12:11] <Yuvi> xadd{l} and {%0,%1|%1,%0} [02:12:29] <peloverde> The decoder exports channels in SMPTE order I think [02:13:47] <mru> Yuvi: I've never seen such syntax before [02:13:47] <peloverde> Internally it is C L R SL SR LFE [02:15:47] <Yuvi> undocumented gcc fun! [02:32:57] <bcoudurier> that would be MPEG [02:33:19] <bcoudurier> SMPTE is L R C LFE Ls Rs [02:46:06] <peloverde> That's why I said exports vs internally [02:52:15] <bcoudurier> oh right, sorry I'm tired [03:05:16] <Yuvi> mru: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43862 <- llvm gets them all except smulwb/smlawb [06:37:02] <wbs> superdump: what's an AMR-NB decoder supposed to output when given DTX/SID frames, or when given "no data" frames? [06:37:23] <wbs> superdump: I managed to produce such samples recently, and noticed that the lavc decoder doesn't support them [06:37:42] <wbs> opencore seems to output more or less plain zero when given such frames [06:38:22] <wbs> with a few samples slightly off (most samples being 0, some samples being -8) [06:38:24] <superdump> i'm not sure off the top of my head what a DTX frame is [06:38:30] <superdump> but a SID frame is silence iirc [06:38:44] <superdump> it'll be in the specs somewhere [06:38:52] <wbs> I think DTX == SID, just different naming [06:39:14] <superdump> http://www.3gpp.org/ftp/Specs/html-info/26-series.htm [06:39:19] <superdump> amr-nb specs are there [06:39:31] <superdump> http://www.3gpp.org/ftp/Specs/html-info/26090.htm [06:39:37] <superdump> should be detailed in that document i think [06:39:44] <wbs> ok, I'll have a look [06:39:53] <superdump> patches welcome :) [06:40:19] <wbs> if it's plain silence, it's interesting that there's both the SID frames that have a few bytes data, and the "no data" frames that have no data at all [06:41:04] <superdump> it may be that it's easier to restart the stream from SID than from nothing [06:42:39] <wbs> hmm, maybe [07:05:42] <wbs> wonderful standard, there's only four different kinds of comfort noise frames ;P [07:33:54] <CIA-7> ffmpeg: michael * r22951 /trunk/libavutil/log.c: [07:33:54] <CIA-7> ffmpeg: Reenable ANSI colors, use method from VLC as suggested by ramiro. [07:33:54] <CIA-7> ffmpeg: Please tell us asap if this breaks for your platform & terminal. [08:12:42] <CIA-7> ffmpeg: michael * r22952 /trunk/libavutil/log.c: Merge the 2 ANSI ESC codes. [10:43:48] <bilboed-pi> KotH, was wondering, is there a history of changes done to the samples repository ? [10:43:54] <bilboed-pi> KotH, like when files were added/removed [10:44:43] <mru> afraid not [10:46:27] <av500> put them in svn [10:46:42] <bilboed-pi> ITYM git [10:46:46] <bilboed-pi> :) [10:46:48] <av500> or put allsamples.txt in svn [10:46:59] <bilboed-pi> oh well... no biggie [10:47:07] <av500> run it once a day, if there is a diff, commit [10:47:14] <bilboed-pi> just need to figure out if there's a "don't delete locally" flag for rsync [10:49:48] <av500> grah, ffmpeg still refuses to mux mkv into anything [10:52:42] <Dark_Shikari> mru: poke [10:52:47] <Dark_Shikari> I have a company that wants ffmpeg running faster on iphone [10:52:51] <Dark_Shikari> and has money [10:52:55] <mru> gimme [10:53:09] <mru> doing what on iphone btw? [10:53:14] <mru> decode? encode? [10:53:22] <Dark_Shikari> decode h264 [10:53:32] <mru> there's not much more I can do there [10:53:37] <mru> a few % [10:54:10] <Dark_Shikari> give me that configure command with standard neon options or whatever [10:54:15] <Dark_Shikari> apparently they forgot asm on their 3GS bulid (neon) [10:54:23] <Dark_Shikari> I can't be sure, but given their numbers it is nigh-certain [10:54:47] <mru> search the ml [10:54:53] <mru> I don't remember the apple magic [10:54:59] <Dark_Shikari> I don't mean the apple magic [10:55:01] <Dark_Shikari> just give me your baseline on [10:55:03] <Dark_Shikari> *one [10:55:07] <Dark_Shikari> and I can make them responsible for the apple magic [10:55:13] <Dark_Shikari> too bad yuvi just left [10:55:13] <mru> it mgiht be different for apple [10:55:42] <av500> --tree-fruit? [11:00:28] <mru> Dark_Shikari: fate should have good configure commands [11:01:43] <KotH> bilboed-pi: rsync doesn't delete any local files unless you tell it to do so [11:01:51] <KotH> bilboed-pi: it might overwrite files though [11:02:09] <bilboed-pi> KotH, thx [11:06:36] <Dark_Shikari> mru: Samsung is fucking with us [11:06:41] <Dark_Shikari> one of the proposals in their latest round of JVT stuff [11:06:42] <Dark_Shikari> Color Component correlation based prediction (CCCP) [11:06:54] <mru> lol [11:07:23] <mru> didn't know the koreans has such sense of humour [11:07:25] <mru> it's not like them [11:08:02] <Dark_Shikari> BBC and Samsung joint proposal [11:08:05] <Dark_Shikari> brits and koreans [11:08:13] <Dark_Shikari> Also, that is my favorite feature in their proposal [11:08:17] <Dark_Shikari> it predicts chroma based on luma [11:08:31] <mru> ah, I'd expect something like that from the brits [11:08:57] <mru> do you have a name of the bbc rep? [11:10:26] <Dark_Shikari> Ken McCann [11:15:44] <mru> don't know him [11:16:05] <av500> http://www.zetacast.com/Zeta_About_Us.htm [11:17:47] <mru> zeta, isn't that that greek letter that's impossible to write? [11:18:29] <av500> ζ [11:18:46] <mru> yeah, that one [11:19:03] <Dark_Shikari> http://ftp3.itu.ch/av-arch/jctvc-site/2010_04_A_Dresden/ [11:19:09] <Dark_Shikari> all the A100+ ones are full spec rewrite proposals [11:19:15] <Dark_Shikari> A124 in particular is the most interesting [11:19:21] <Dark_Shikari> it achieves 40%+ compression improvement over h264 [11:19:29] <av500> at what price? [11:19:34] <Dark_Shikari> Though hopefully someone will smack them upside the head for the 12-tap interpolation filter [11:19:37] <Dark_Shikari> which I think is wholly unnecessary [11:19:38] <mru> 5 billion patents [11:19:46] <Dark_Shikari> it's the BBC / samsung proposal [11:19:48] <mru> 12-tap... omg [11:19:59] * mru wants wider simd... [11:20:14] <av500> Thomas Davies (BBC) [11:20:40] <Dark_Shikari> it has new transforms up to like 64x64 [11:20:48] <Dark_Shikari> that combine wavelet/dct to allow it to be done in 16-bit precision [11:20:54] <av500> but it still loses to VP9... [11:20:55] <Dark_Shikari> rotational transforms [11:20:56] <mru> is this h265 work? [11:20:58] <Dark_Shikari> yes [11:21:29] <mru> I heard they're going for larger block sizes [11:21:31] <mru> makes sense [11:21:49] <mru> and I bet MVs can be more than 16 pixels :-) [11:23:17] <av500> 1/12 pel accuracy [11:23:46] <Dark_Shikari> implementing all this in hardware is going to be funny [11:24:10] <mru> I'm sure they're thinking of that [11:24:14] <mru> they usually do [11:24:34] <Dark_Shikari> Some of the proposals seem to be more hardware-minded than others. [11:24:41] <Dark_Shikari> Mediatek's is, incredibly unsurprisingly. [11:24:42] <mru> h264 is full of stuff that just fits in 16-bit arithmetic [11:26:19] <av500> Average decoding time about 2.4 times that of JM17.0 [11:26:44] <av500> Dark_Shikari: I am sure they are all thinking about hw implementations [11:27:22] <Dark_Shikari> of course, they're comparing _without SIMD_ [11:27:30] <Dark_Shikari> which is a serious problem especially when consdiering hard-to-simd things [11:27:38] <Dark_Shikari> And we don't know how much they optimized their decoder. [11:27:42] <Dark_Shikari> That's the big thing I worry about [11:27:59] <Dark_Shikari> since this _is_ a competition, there's huge incentive to optimize your decoder to make it appear to be lower complexity [11:28:34] <av500> Dark_Shikari: but seriously, who will decode H265 HD in SW? [11:28:44] <twnqx> my laptop will! [11:28:48] <Dark_Shikari> av500: everyone [11:29:03] <Dark_Shikari> For the 3 years it takes to design and tape out efficient HW [11:29:05] <av500> my PC -> GPU -> HW [11:29:11] <av500> my phone -> HW [11:29:11] <Dark_Shikari> Your GPU doesn't support H.265. [11:29:15] <av500> my TV -> HW [11:29:15] <Dark_Shikari> Your phone doesn't support H.265. [11:29:19] <Dark_Shikari> Your TV doesn't support H.265. [11:29:24] <av500> of course [11:29:50] <av500> but that does not matter for the great unwashed [11:30:02] <Dark_Shikari> er... their stuff doesn't support it either. [11:30:04] * KotH puts av500 into bathtub [11:30:19] <av500> KotH: is it not sunday yet! [11:31:36] <av500> Dark_Shikari: true, my TV does not support H265, but it did not suport H264 as a SW backport either [11:31:48] <av500> it did when it got a HW decoder [11:31:54] <av500> aka a new tv [11:32:10] <Dark_Shikari> yes... which will take a long time [11:32:20] <Dark_Shikari> not only do people have to upgrade their TVs, but they have to actually make the hardware [11:32:25] <av500> sure [11:32:25] <Dark_Shikari> and making the hardware takes much longer than making software [11:32:31] <av500> same for bluray/h264 pickup [11:32:41] <Dark_Shikari> and since when do TVs decode video? [11:32:44] <Dark_Shikari> they use STBs for tat [11:32:49] <Dark_Shikari> *that [11:32:50] <av500> same thing [11:32:57] <Dark_Shikari> Not really, there's a big difference [11:33:01] <Dark_Shikari> STBs get replaced when Comcast wants to. [11:33:07] <Dark_Shikari> TVs get replaced when the consumer wants to. [11:33:13] <av500> not here [11:33:30] <av500> but anyway [11:33:35] <av500> thats not the point I think [11:33:48] <av500> for STB its even easier to roll out new HW... [11:34:09] <mru> directv in the US have something like 20M STBs in the field that can't even decode h264 [11:34:25] <mru> they're not replacing them until they fail [11:34:41] <av500> mru: right, so they do not care for a super effiecient H264 SW decoder [11:34:55] <av500> coz it would have to decode HD on SD hardware [11:35:10] <av500> its not about 10% [11:35:16] <mru> this things have puny 100MHz CPUs [11:35:19] <mru> if you're lucky [11:35:30] <mru> 54MHz used to be common [11:35:32] <mru> 2*27 [11:35:37] <av500> I know [11:35:48] <av500> so the bump in codec caps is by adding new HW [11:35:53] <Dark_Shikari> av500: also, complexity matters for hardware as well... [11:35:59] <av500> not by a SW update [11:36:03] <Dark_Shikari> high complexity -> you can't make a DSP implementation for many years [11:36:08] <Dark_Shikari> No DSP implementation -> you need an ASIC implementation [11:36:09] <av500> Dark_Shikari: yes, but as you pointed out, the numbers are simdless [11:36:18] <mru> the newer STBs are all programmable [11:36:18] <Dark_Shikari> you need an ASIC implementation -> higher dev times [11:36:25] <av500> so they do not relate to HW [11:36:26] <Dark_Shikari> av500: yes, which means it's _worse_ than the numbers show [11:36:31] <mru> DSP + programmable accelerators [11:36:45] <av500> mru: I know the tech details [11:36:55] <Dark_Shikari> the main problem I see is just too much _shit_ [11:37:08] <Dark_Shikari> hundreds of intra modes, dozens of different transforms [11:37:10] <Dark_Shikari> this is stupid. [11:37:11] <mru> it's still early stages [11:37:17] <Dark_Shikari> Yeah, I know, they will pare it down [11:37:18] <mru> everybody is tossing ideas in the pot [11:37:27] <Dark_Shikari> I'm just saying that some of the current proposals are a bit... insane [11:37:30] <mru> patented ideas of course [11:37:55] <av500> Dark_Shikari: i dont understand why dont they just standardize a VM, then you download the decoder in the bitstream :) [11:38:02] <mru> they'll end up with a spec where all the members get a few patents included [11:38:58] <av500> once the "tools" are turing complete, anything goes [11:43:18] <mru> btw, ffmpeg is accepted for linuxtag [11:43:26] <av500> \\\ooo/// [11:43:48] <av500> which means I need to find a way to get the beast to berlin..... :( [11:44:37] <KotH> so is mplayer and ogp [11:44:58] <mru> how's the BBB render doing? [11:45:16] <av500> http://www.jannau.net/bbb_videowall/ [11:45:18] <av500> look good [11:45:18] <mru> I "fixed" my c2q [11:45:27] <mru> but it crashed compiling a kernel [11:45:32] <mru> something's unstable [11:45:43] <KotH> doesnt look too bad imho [11:46:03] <av500> frak this linuxtag is 3 working days [11:46:11] <mru> always is [11:46:36] <KotH> it used to be 4 [11:46:37] <mru> we could sneak in a little message from our sponsors, if that makes your boss happy [11:46:38] <av500> i dont think I can stay the whole time [11:46:46] <mru> KotH: 3 working days + saturday [11:46:54] <KotH> ah.. [11:46:57] * KotH doesnt read [11:47:02] * KotH cant type [11:47:12] <KotH> it's somehow not my day today [11:47:15] * KotH blames spaam [11:47:24] <av500> ok, drink night is thursday [11:48:26] <mru> if we ask around we can probably find someone who can bring the beast to berlin [11:48:45] <av500> mru: yeah, if I go to droidcon in may, i can prolly bring it to janneg [11:51:04] <av500> or you will have to pick it up here :) [11:51:53] <janneg> rendering is a little bit unpredictable. KotH's machine is working on a single take since the 3rd with 8-9 hours per frame [11:52:13] <mru> av500: we have people in that area [11:52:19] <av500> i know [11:52:48] <KotH> janneg: wtf? [11:52:53] <Dark_Shikari> btw, I have an image of the first fully compliant open source-compressed blu-ray disk [11:52:58] <Dark_Shikari> I wonder if you can distribute copies of that there =p [11:53:00] <janneg> OTOH we have enough material and could just switch to the HD scenes [11:53:16] <mru> Dark_Shikari: where can I grab a copy? [11:53:20] <av500> url? [11:53:23] <mru> how large is it? [11:53:23] <Dark_Shikari> It isn't finalized yet, it's a beta copy [11:53:24] <Dark_Shikari> but it's basically done [11:53:27] <Dark_Shikari> it's ~2GB [11:53:34] <Dark_Shikari> And yes it's DVD5 compliant [11:53:41] <Dark_Shikari> i.e. its maximum bitrate matches DVD transfer rates [11:53:44] <Dark_Shikari> so you can burn it to a cheap DVD-R [11:53:53] <mru> good [11:53:55] <Dark_Shikari> contains Elephant's Dream, Big Buck Bunny, and Tallship [11:54:03] <Dark_Shikari> Tallship being a camera HD source contributed by Microsoft [11:54:06] <Dark_Shikari> under an absurdly liberal license [11:54:08] <mru> I do have a bluray burner, but discs are pricey [11:54:18] <Dark_Shikari> we included that so that the disk didn't only include CGI content [11:54:26] <mru> url? [11:54:41] <Dark_Shikari> it's still only on an FTP that the guy requested me not to post because he doesn't have tons of bandwidth =p [11:54:48] <Dark_Shikari> when we release the official one there will be at the least a torrent [11:55:16] <av500> Dark_Shikari: but there is this one: http://www.blender3d.org/e-shop/product_info_n.php?products_id=106 [11:55:42] <av500> its BBB and ED [11:55:48] <Dark_Shikari> Yea, and it's not made with x264 [11:55:51] <av500> ah right [11:55:52] <Dark_Shikari> Probably some proprietary encoder [11:56:09] <Dark_Shikari> to michael: [11:56:10] <Dark_Shikari> 19:53 < Kapsel_> btw, seems like the ffmpeg build I found, is trying to use some kind of ascii colors for the output. is there any way to disable this? it doesnt quite work, at least not in my prompt. [11:56:12] <janneg> KotH: I've no idea what's the problem. There was another scene which took even longer 10-11 hours on my quadcore [11:56:17] <Dark_Shikari> (windows user) [11:56:30] <Dark_Shikari> mru: http://mirror05.x264.nl/Dark/bluray/ [11:56:42] <Dark_Shikari> Raw audio files (uncompressed or flac) and raw h264 can be found there [11:56:48] <Dark_Shikari> Not a proper blu-ray image obviously [11:57:03] <mru> I have plenty of h264 files [11:57:22] <mru> btw, ffmpeg refuses to transcode your ironman.mkv [11:57:32] <mru> something about invalid timestamps [11:57:39] <av500> it refuses to transcode any mkv here [11:57:42] <Dark_Shikari> gotta love ffmpeg's matroska demuxer disaster [11:57:54] <mru> piping it as rawvideo works of course [11:58:04] <av500> -vcodec copy [11:58:19] <av500> so, transmux [11:58:26] <Yuvi> demuxer's usually fine, it's the timestamp everywhere else that's screwed up [11:58:31] <mru> this one fails with -vcodec anything [11:58:34] <Yuvi> timestamp handling [11:58:45] <mru> it's because mkv stores only pts [11:58:48] <av500> Could not write header for output file #0 (incorrect codec parameters ?) [11:58:56] <mru> and lavf invents wrong dts for frames [11:59:07] <mru> no, it does ~500 frames correctly [11:59:11] <mru> then it fails [11:59:20] <mru> or starts duplicating frames [12:00:04] <av500> [mp4 @ 0x80913b0]track 1: codec frame size is not set [12:00:38] <av500> ah, once i set -an, it fails with the usuaal timestamp error [12:01:54] <Yuvi> mru: works for me (maybe off by one frame thanks to -vsync 1?) with -vcodec mpeg4 [12:02:07] <mru> I don't want -vsync 1 [12:02:09] <mru> it's wrong [12:02:13] <mru> it duplicates frames [12:02:16] <Yuvi> true [12:02:38] <mru> it shouldn't do that [12:02:56] <Yuvi> yeah, fails with -vsync 0 [12:03:42] <pengvado> <Dark_Shikari> there's huge incentive to optimize your decoder to make it appear to be lower complexity [12:03:46] <pengvado> there would be nothing wrong with that if they weren't comparing to JM [12:05:06] <Dark_Shikari> pengvado: exactly [12:05:18] <Dark_Shikari> my point in its entirety ;) [12:07:18] <av500> Dark_Shikari: why does ffplay refuse to play tallship.h264? [12:07:45] <av500> it plays a few frames then stops [12:07:53] <mru> I see that a lot with ffplay [12:08:00] <mru> probably something with timestamps [12:08:02] <Yuvi> frame dropping code probably [12:08:46] <Yuvi> at least, I didn't see that before it [12:09:07] <wbs> av500: try -noframedrop [12:09:34] <av500> thx [12:10:32] <av500> oops, ffplay seeks in .h264 files [12:11:48] <Yuvi> mru: I think the issue is that ffmpeg chooses a timebase of 1/24 since that's what's written in the codec, and two timestamps from the mkv are rounded to the same value [12:12:05] <Dark_Shikari> but that isn't what's written in the codec [12:12:12] <Dark_Shikari> tallship uses 60fps [12:12:18] <Yuvi> ironman [12:12:25] <Dark_Shikari> oh [12:12:29] <mru> every time someone complains about timestamps, michael prints another number in the info dump [12:12:46] <mru> ironman has like 5 different timebases reported [12:13:17] <Dark_Shikari> just use container and be done with it [12:13:38] <mru> if codec and container differ, how do you know which is correct? [12:13:49] <mru> with avi codec is correct more often than container [12:14:58] <Yuvi> container is probably more correct except if the codec has a (mangled) ntsc timebase [12:15:08] <mru> why? [12:16:23] <Yuvi> isn't the container what all the players use for timestamps? [12:17:31] <Yuvi> for avi in particular the only disagreement I've seen is with mangled ntsc [12:19:59] <mru> with avi I've seen every butchering possible [12:20:06] <mru> and a few impossible ones [13:16:05] <CIA-7> ffmpeg: michael * r22953 /trunk/libavutil/log.c: Trying _WIN32 for win32 detection. [13:41:35] <twnqx> so if apple would really buy arm [13:41:42] <twnqx> would that change any of the exiting licensing? [13:41:47] <twnqx> existing* [13:42:06] <mru> why would apple buy arm? [13:42:10] <mru> seriously [13:42:31] <Dark_Shikari> they have fucktons of money [13:42:33] <Dark_Shikari> like, holy shit [13:42:40] <Dark_Shikari> also, vertical integration [13:42:41] <mru> sure, but why should they spend it on arm? [13:42:48] <mru> it doesn't make sense [13:42:52] <Dark_Shikari> vertical integration [13:42:57] <RTFM_FTW> uh no [13:42:59] <RTFM_FTW> no no no [13:43:00] <mru> that phrase means nothing at all [13:44:05] <Dark_Shikari> apple is historically a very vertically integrated company [13:44:14] <Dark_Shikari> mru: http://en.wikipedia.org/wiki/Vertical_integration [13:44:15] <mru> the only reason they could have for buying it is to restrict access to other companies [13:44:25] <mru> but then the costs would shoot up [13:44:33] <Dark_Shikari> for example, Carnegie Steel was a historically vertically integrated company [13:44:35] <RTFM_FTW> they don't need ARM... they already have the necessary IP licenses and the ability to fab their ASICs where they see fit [13:44:35] <mru> they'd have to foot the entire r&d bill themselves [13:44:36] <twnqx> estimates say 6 billion [13:44:37] <Dark_Shikari> or Standard Oil [13:44:44] <twnqx> with apple having 30 in cash [13:44:50] <Dark_Shikari> and 13.5b in quarterly income [13:44:54] <Dark_Shikari> er, profit [13:45:00] <Dark_Shikari> *net income [13:45:34] <mru> besides, does apple have any interest at all in making microcontrollers for industrial applications? [13:45:35] <kierank> like brewery's owning pubs [13:45:44] <mru> that's where most of arm's revenue comes from [13:46:09] <av500> mru: that would be spun off immideately [13:46:31] <twnqx> on the other hand, if it's profitable.. [13:46:45] <mru> but it's arm7 and arm9 sales that fund the cortex development [13:46:46] <mru> in part [13:46:57] <av500> twnqx: customer would not buy from apple [13:47:01] <BBB> I doubt that the gov would allow them to merge [13:47:15] <BBB> wouldn't DoJ or some gov instance here immediately block it? [13:47:40] <av500> ministry of funny walks would [13:47:42] <kierank> eu maybe [13:47:58] <Dark_Shikari> BBB: but apple can't be a monopoly [13:47:59] <mru> I don't imagine nokia liking such a deal much [13:48:11] <mru> or sony-ericsson, or htc, or etc, etc [13:48:12] <BBB> Dark_Shikari: monopoly is not the reason mergers are blocked [13:48:16] <Dark_Shikari> everyone knows that everything apple does is correct ;) [13:48:30] <BBB> DoJ blocks mergers if they create unfair advantages or unfair competition [13:48:33] <BBB> that's != monopoly [13:48:35] <Dark_Shikari> I know [13:48:41] <Dark_Shikari> And yeah, a LOT of companies would object to that. [13:48:41] <mru> arm has a more or less monopoly on mobile processors [13:48:49] <BBB> arm being owned by one of its clients is VERY unfair to its direct competitors [13:49:00] <BBB> DoJ knows that [13:49:04] <mru> putting that in the hands of one phone manufacturer would be a very bad thing [13:49:08] <BBB> right [13:49:15] <mru> arm are that rare, well-behaved monopolist [13:49:17] <BBB> it's just a rumour anyway [13:49:47] <mru> the arm boss was quoted saying such a deal would be pointless [13:53:23] <Dark_Shikari> http://www.marketwatch.com/story/apple-passes-microsoft-on-sp-500-market-cap... [13:56:54] <BBB> Dark_Shikari: why you up so early? :) [13:57:01] <BBB> isn't it like 7am for you? [13:57:29] <Dark_Shikari> I woke up like 3 hours ago [13:57:48] * BBB falls asleep :-o [14:08:49] <scaphilo> anyone knows a little bit more about mpeg4part2 qscale and dquant? im not sure if i understand that correctly. [14:09:09] <Dark_Shikari> what about it [14:09:19] <mru> it's an ugly spec [14:09:48] <scaphilo> am i right that in macroblocks there are only differential values. Not like in mpeg2 where you store the absolut value of qscale? [14:10:05] <Dark_Shikari> er, I'm pretty sure mpeg-2 stores dquants too [14:10:20] <scaphilo> oh really? ups [14:11:38] <scaphilo> ill have to check that, but dquant of current macroblock is the difference between the last macroblock's qscale and the current one? [14:12:11] <Dark_Shikari> yes [14:14:17] <scaphilo> thx [14:14:19] <mru> is there an mpeg4 spec with all the crap cut out? [14:14:33] <scaphilo> you mean this 3d things ;-) [14:14:41] <mru> and the rest of it [14:15:30] <scaphilo> i dont know, i was looking for something like that as well [14:15:34] <Dark_Shikari> it's not that hard [14:15:38] <Dark_Shikari> you're doing mpeg2 transcoding [14:15:52] <Dark_Shikari> so the dquant restrictions don't apply [14:15:57] <Dark_Shikari> there's no dquant in 4mv blocks but you aren't using 4mv blocks [14:16:10] <Dark_Shikari> there's dquant restrictions in bframes but bframes don't have to be transcoded exactly as they aren't referenced [14:17:14] <scaphilo> ah yes mpeg2 to mpeg4part2 openloop. It works with option qscale 1 and without bframes :-) [14:19:05] <scaphilo> hey about this bframes would you just refer to one of the pframes? and leave the other one? [14:19:16] <Dark_Shikari> no, I'd just convert bframes into bframes [14:19:18] <Dark_Shikari> no problem there [14:21:08] <scaphilo> i currently never tested with bframes because ffmpeg doesnt seem to use bframes in mpeg2 encoder. when i dont set bf=whatever [14:21:27] <Dark_Shikari> then set bf=whatever ;) [14:21:52] <scaphilo> well im a bit afraid of it ;-) first i fix that thing with qscale [14:45:48] <kierank> are there any there any good debuggers on linux? I'm fed up of gdb constantly locking up [14:46:43] <kierank> s/any there/ [14:47:12] <scaphilo> me but im not a debugger specialist [14:47:19] <Dark_Shikari> valgrind? ;) [14:48:10] <kierank> valgrind doesn't like mmap loaded binaries [14:48:35] <wbs> kierank: file a feature request, then :-) [14:50:26] <Dark_Shikari> ida under a vm? [14:51:14] <mru> kierank: loading with mmap directly, not dlopen? [14:51:36] <kierank> it's using merzbt's binary loader code for atrac3 [14:51:58] <kierank> it's a windows binary dump [14:52:27] <mru> that might get tricky [14:52:53] <kierank> gdb works ok but it locks up after a while [14:52:56] <BBB> kierank: I did that under gdb, worked fine for me [14:53:08] <mru> convert it to elf and use dlopen [14:53:09] <BBB> are you using some pre-alpha gdb version? [14:53:46] <kierank> I tried 7.0 in ubuntu and 7.1 I built myself and they both locked up. I guess it might be something the loaded code does [14:54:06] <BBB> try objconv as mru suggested [14:54:40] <mru> or if that doesn't work, teach the loader to dump it out as elf [14:54:48] <mru> you could use libbfd :-) [14:55:06] <mru> but wear safety goggles, or you'll probably tear your eyes out [14:55:39] <BBB> I tihnk it's time I learn configure magic [14:55:51] <BBB> how do I make wmavoice "require" fft/rdft? [14:57:02] <mru> wmavoice_select="rdft" [14:57:10] <mru> or fft or whatever it needs [14:57:37] <BBB> wmavoice_decoder_select? [14:57:45] <mru> yes [14:57:48] <mru> of course, my bad [14:58:37] <mru> looks like it needs rdft and dct [14:58:49] <av500> BBB: objconv? [14:59:00] <mru> objcopy [14:59:09] <av500> ah, this one I know [14:59:25] <av500> I know it was obj_dumb_down [14:59:28] <BBB> mru: patch on ML [14:59:32] <BBB> thanks for the hint [15:00:23] <BBB> should I keep it alphabetically ordered? [15:00:45] <av500> mru: may I assume you want to work on flash again? :) [15:00:57] <mru> BBB: I'm not too fussed about that [15:01:17] <mru> av500: :-) [15:02:25] <BBB> http://www.agner.org/optimize/ objconv, av500 [15:02:32] <BBB> hm, that was disordered [15:03:19] <av500> BBB: I wish I had that a few ys back [15:04:20] <BBB> it worked pretty darn well when I tried it [15:04:49] <av500> I once had to convert M$ COFF to TI COFF [15:05:04] <av500> and I had a halfway patched objdump that spoke TI coff [15:05:09] <mru> coff formats share little more than the name [15:05:26] <av500> but, objcopy can only dumb down, not copy between equal formats [15:05:41] <av500> so it dropped all relocs.... [15:05:50] <mru> in theory it can copy [15:05:55] <av500> in theora [15:05:58] <mru> but something usually prevents it from working [15:06:06] <av500> but in practice, it drops reloc in the "in" stage [15:06:08] <mru> it's like remuxing with ffmpeg [15:06:15] <mru> relocs = timestamps [15:06:19] <av500> unless you use them to actually performs relocatiobn [15:06:29] <av500> at the "out" stage, they are gone [15:06:35] <av500> yup [15:06:43] <mru> elf to elf works fine [15:06:50] <av500> I have a nice objcopy rottin somewhere that can do that ... [15:06:59] <mru> reminds me of that elf demuxer we need to write... [15:07:04] <av500> yes [15:07:20] <av500> and can somebody tell probe to not detect alf as mp3? [15:07:23] <av500> elf [15:08:07] <av500> as in ffplay ffplay [15:09:47] <mru> btw, the archos5 has really good standby time [15:09:58] <av500> thx [15:10:02] <mru> it's been sitting on my desk for a couple of weeks without being charged [15:10:20] <mru> battery is still at 75% or so [15:10:25] <av500> so, you compliment me on a useless product :) [15:11:07] <kierank> av500: stop complaining. you need more fanboys [15:11:43] <av500> right [15:17:43] <mru> av500: but now it hung while shutting down to install an update [15:18:10] <av500> gee [15:18:33] <mru> and why does each update reinstall a fuckton of useless apps? [15:18:42] <av500> ask MKT [15:19:00] <av500> not in my hands [15:19:02] <mru> removing all those apps every time it updates is annoying [15:19:52] <mru> I can tolerate a few bundled apps with a new device [15:20:03] <av500> i know [15:20:06] <mru> but the update should check if they've been removed and not reinstall them [15:20:23] <av500> thats not so easy i was told [15:20:53] <mru> oh really [15:21:03] <mru> I'm sure building the device wasn't so easy either [15:21:05] <mru> but you did that [15:21:18] <av500> imagine what fun we had when mkt told us in last minute that the list of bundled app is "of course" per country specific [15:21:28] <av500> like 1week before launch [15:21:39] <mru> oh, so that's why it installs all those us-only apps? [15:21:59] <av500> mru: please dont ask me things like that [15:22:25] <av500> but, come on "high paying jobs" is the app for you, no? :) [15:22:31] <j-b> 'morning [15:22:38] <av500> 'jour [15:23:11] <BBB> hi j-b [15:28:11] <av500> ffmpeg in linuxtag could be mentioned on ffmpeg.org as news? [15:28:24] <BBB> when is linuxtag? [15:28:28] <av500> 9-12 6 [15:28:51] <av500> and ffmpeg.org has no rss feed? [15:30:10] <j-b> do you have a booth there? [15:30:28] <av500> yup [15:30:44] <av500> berlin = wall, you know [15:30:50] <BBB> wasn't there going to be a talk? [15:30:56] <BBB> I see no ffmpeg on the program anywhere [15:31:14] <mru> said who? [15:31:29] <av500> "why theora sucks" [15:32:45] <lu_zero> yawn [15:32:54] <lu_zero> when is linuxtag? [15:32:54] <av500> so, no talk [15:32:59] <av500> 9-12 6 [15:33:02] <kierank> Is it true that in germany you have beer with your lunch at work av500? [15:33:22] <lu_zero> kierank: is that strange? [15:33:24] <mru> do you have a problem with that? [15:33:29] <mru> beer is good [15:33:29] <kierank> no [15:33:34] <av500> kierank: depends [15:33:45] <av500> but mostly no [15:33:53] <av500> in bavaria, but then not the young ppl [15:34:09] <av500> but some do, yes [15:34:25] <av500> which reminds me of the crate of beer behind me [15:34:34] <lu_zero> uhmm [15:34:56] <lu_zero> how many people will come from the south? [15:35:52] <av500> lol http://twitter.com/joshdev/status/12706303667 [15:36:21] <kierank> reply from the ffmpeg account [15:36:29] <kierank> "we sure are" [15:36:38] <av500> who owns that [15:37:07] * kierank votes KotH [15:40:50] <janneg> there is talk from fluendo http://www.linuxtag.org/2010/en/program/free-conference/wednesday/details.ht... [15:40:50] <av500> mru: they tell me you can say no to the wizzard [15:41:38] <mru> I'll have to look more carefully next time [15:41:47] <mru> at least this time it didn't try to do a factory reset [15:42:05] <mru> like the last 4 or 5 times it decided it was the first time running android 1.6 [15:42:08] <janneg> "FOSS applications for multimedia aren’t many and don’t offer the same quality and variety that could be found in other OS, such as Mac OSX or Windows" [15:42:30] <Dark_Shikari> lol [15:43:13] <av500> lol [15:43:28] <av500> mru: yeah, that one is a bug [15:43:36] <av500> that should be fixed with latest release [15:43:44] <mru> yeah, it didn't do it this time [15:44:00] <mru> it did insist on calibrating the touchscreen and accelerometer though [15:44:11] <av500> yes, that is more for noobs [15:47:16] <av500> mru: it has a proper browser now: http://www.openaos.org/tmp/2010-04-23-154245.jpg [15:48:01] <mru> how is that more proper? [15:50:37] <janneg> and FFmpeg is of course misspelled and they imply that it breaks laws [15:51:04] <Dark_Shikari> because they're fluendo [15:51:11] <av500> janneg: abmahnung! [15:51:53] <janneg> we could just troll the talk [15:52:04] <av500> ack [15:54:39] <av500> ffmpeg vs commercial codecs is totally orthogonal to the patent situation [15:55:40] <Dark_Shikari> av500: their products are worse, therefore they must rely on FUD [15:57:41] <BBB> someone should explain them that you can (according to LGPLv2.1) buy a patent license for ffmpeg, resell it for money as long as the patent license itself allows free software to be bundled with it [15:58:01] <Dark_Shikari> BBB: they _know_ this [15:58:04] <Dark_Shikari> they aren't stupid [15:58:10] <BBB> then why don't they resell ffmpeg? [15:58:13] <Dark_Shikari> they're just a company trying to peddle shitty products via FUD [15:58:16] <Dark_Shikari> because ffmpeg isn't their product! [15:58:17] <BBB> $$profit$$ [15:58:50] <BBB> so? [15:58:56] <BBB> you don't need to own a product to resell it [15:59:00] <BBB> as long as you have a license to resell [15:59:05] <BBB> = LGPLv2.1 [15:59:11] <BBB> \o/ [15:59:15] <BBB> $$profit$$ [15:59:32] <Dark_Shikari> And? [15:59:33] <Dark_Shikari> NIH. [15:59:36] <BBB> oh right [15:59:39] <BBB> yes, that's true [15:59:43] <av500> BBB: I doubt any of our codec licenses mandates anything about open vs closed src [15:59:50] <Dark_Shikari> I have the h264 one, it definitely doesn't [16:00:00] <BBB> av500: I know it doesn't, because most people with such licenses use ffmpeg [16:00:01] <BBB> :) [16:00:06] <BBB> just fluendo doesn't [16:00:15] <BBB> makes you wonder why... [16:00:45] <av500> BBB: because anybody can look up the patent licence price and substract it from fluendo price [16:01:14] <mru> and then look up ffmpeg price [16:01:26] <av500> mru: the emotional? [16:01:44] <mru> there's risk of flaming of course [16:02:19] <av500> btw, german supreme court upholds M$ FAT patents.. [16:02:37] <kierank> needs more currency symbols [16:02:40] <mru> how can fat patents still be valid? [16:02:55] <av500> 1994-10-05 [16:03:04] <mru> isn't fat from like 1982? [16:03:15] <av500> fat32 [16:03:16] <av500> LFN [16:03:37] <janneg> not only uphold but overturned a ruling from the bundespatentgericht saying that the patent is invalid [16:03:43] <av500> right [16:03:55] <mru> bent judges are nothing new [16:04:20] <kierank> I would mention a particular libel judge in london [16:04:37] <kierank> but that might be a bit ironic [16:04:43] <mru> like they said in the italian job, everyone in the world is bent [16:14:59] <BBB> that's why we need a foundation, so we can re-bribe them to the rigt side [16:15:05] * BBB runs [16:18:08] <av500> we can order a hit on them you mean [16:18:10] <av500> can [16:18:12] <av500> can't [16:21:08] <spaam> KotH: dont blame me for that [16:29:01] <CIA-7> ffmpeg: mru * r22954 /trunk/ (libavcodec/audioconvert.c configure libavutil/libm.h): Workaround for missing llrintf() [16:29:27] <mru> that should bring back the DOS build [16:30:49] <janneg> yeah! :) [16:31:07] <mru> and also a secret platform I'm working on [16:32:37] <av500> beer! [16:34:50] <BBB> mru: that looks wrong [16:34:53] <janneg> where is the multibyte char in alldevices IIC fails over? [16:35:12] <BBB> mru: it's intentionally 32-bit, if float-to-32bit overflows, it should truncate [16:35:26] <BBB> so this would ideally be implemented in a different way [16:36:00] <mru> I don't see how it's wrong [16:36:13] <mru> llrintf converts a float to long long [16:36:17] <BBB> llrintf(x) { x/=256.; y=rintf(x); return clipped_y << 8; } [16:36:19] <mru> so does the replacement [16:36:32] <BBB> it fails if it overflows [16:36:36] <BBB> which is the whole point of the function [16:36:37] <mru> no [16:36:43] <mru> if what overflows? [16:36:47] <mru> rint returns double [16:37:05] <mru> it's not going to overflow long long [16:37:11] <BBB> wait, I might say something stupid [16:37:14] <BBB> aha [16:37:16] <BBB> ok, sorry [16:37:19] <BBB> I misunderstood [16:37:27] <BBB> I thought you used the one returning long or int [16:37:37] <mru> that's lrint [16:37:41] <BBB> got it [16:37:41] <mru> there isn't on returning int [16:37:45] <mru> one [16:38:01] * BBB curses at the multitude of *rint*() functions [16:38:17] <mru> oh, I'm with you on that one [16:39:16] <mru> but thanks for checking anyway [16:42:49] <CIA-7> ffmpeg: rbultje * r22955 /trunk/configure: Make WMAVoice decoder depend on DCT/RDFT [16:44:25] <BBB> is that Makefile patch ok also? [16:45:10] <mru> I suppose [16:45:37] <mru> those common bits should really be given their own symbol [16:45:47] <mru> but we can do that later [16:45:53] <BBB> what do you mean? prefix? [16:45:55] <mru> adding the missing one doesn't break anything [16:46:05] <mru> no, a CONFIG_ symbol [16:46:10] <mru> like FFT [16:46:28] <CIA-7> ffmpeg: rbultje * r22956 /trunk/libavcodec/Makefile: Add acelp_filters.o as QCELP decoder object file. [16:46:35] <BBB> oh, aha [16:46:40] <BBB> yes, I guess [17:20:06] <hyc> hey cool, VP6 acceleration. mru, thought you didn't have any motivation to do that yet [17:20:27] <mru> maybe something motivated me [17:20:44] <kierank> lol [17:21:10] <mru> 10% more speed for an hour's work ain't bad [17:25:50] <BBB> maybe is another word for money? [17:27:05] <kierank> or beer [17:28:02] <jai> or girls [17:29:53] <mru> girls are the last thing I expect to motivate me on this [17:30:07] <mru> but yeah, they're pretty good motivators [17:30:18] <hyc> lol [17:30:38] * BBB looks for random stuff to do next [17:31:04] <mru> you could find aurelien and have him ack the patch [17:31:04] <jai> *cough* multichannel resampling *cough* [17:32:15] <kierank> *cough* find these elusive bugs I've beeing trying to locate in the dolby code [17:32:36] <BBB> well if you're already doing these two things, why would I do them? [17:32:47] <BBB> that totally defeats the purpose of you being my minions :-p [17:32:54] <jai> lol [17:33:21] <jai> BBB: maybe write some html for ffmtech.org [17:33:30] <jai> i assure you no one is doing that :) [17:33:33] <BBB> I guess... [17:33:36] <BBB> :) [17:33:59] <kierank> i'd update the lighttpd on that server [17:34:08] <mru> do whatever helps us dominate more [17:34:40] <mru> kierank: blame debian for the version [17:34:40] <kierank> it's quite old and there were definitely some vulnerabilities in it recently [17:34:50] <mru> it's got patches [17:35:01] <kierank> that's ok then [17:36:34] <jai> use nginx, later we can scale in the cloud too ;) [17:36:56] <kierank> ffmpeg as a service [17:36:58] <kierank> FaaS [19:08:14] <astrange> hmm gcc's loop optimizer likes to promote all iteration variables to intptr_t and waste some stack space [19:13:54] <mru> wouldn't be more efficient if we reported every time gcc did something right? [19:23:39] <Dark_Shikari> lol [19:26:18] <astrange> well it [19:26:24] <astrange> 's pretty reasonable on this file except for that [19:26:45] <astrange> oddly llvm is absolutely terrible. i'm too lazy to file regressions for that since they keep adding new ones [19:30:18] <kierank> I have something good to say about gnu. gdb reverse execution is actually quite useful [19:33:39] <nfl> merbanan, ping [19:39:55] <merbanan> pong [19:40:34] <nfl> hi, why would testing the g723.1 code be hard? [19:41:10] <nfl> thats what you said in my patch review [19:41:26] <merbanan> do we have any reference files to test with ? [19:41:31] <merbanan> and reference output ? [19:41:50] <merbanan> or did I say that about the rtp code ? [19:42:07] <nfl> couldn't we use the reference encoder for that? [19:42:14] <nfl> nope, not the rtp code [19:42:35] <merbanan> then it is easy to test [19:42:49] <nfl> ok [19:42:49] <merbanan> just use the refencoder [19:44:35] <nfl> if you have time, could you tell me if I've got CODEC_CAP_SUBFRAMES set up correctly in my patch? [20:17:20] <merbanan> nfl: do you have svn access ? [20:18:29] <nfl> merbanan, for checkout? [20:19:01] <merbanan> for checkin [20:19:07] <nfl> merbanan, nope [20:19:25] <merbanan> send an email to diego and request one for the soc repo [20:19:48] <merbanan> nfl: what date did you send the patch ? [20:19:58] <merbanan> the one you want me to look at [20:20:04] <nfl> merbanan, today i guess [20:20:16] <nfl> bit confused abt the timezones :) [20:20:32] <nfl> the latest one in the soc ml [20:20:50] <merbanan> there we go, it was badly sorted [20:21:12] <nfl> you should use gmail ;) [20:22:03] <merbanan> why did you use CODEC_CAP_SUBFRAMES ? [20:22:32] <nfl> to handle rtp packets that may contain multiple frames [20:22:49] <nfl> as suggested by BBB instead of a parser [20:23:13] <merbanan> why doesn't the demuxer split the packets correctly ? [20:23:31] <nfl> there is no demuxer [20:23:38] <BBB> (the demuxer doesn't always know how to do that) [20:23:53] <merbanan> BBB: the rtp thingy I guess ? [20:23:59] <BBB> yeah [20:24:02] <BBB> "thingy" :) [20:24:33] <merbanan> yeah ;) [20:24:58] <nfl> ah sorry, the rtp demuxer [20:28:47] <merbanan> nfl: the G723_1_Context and G723_1_Frame can be merged [20:29:23] <nfl> merbanan, ok [20:30:26] <merbanan> nfl: temp = get_bits(&gb, 13); <-- name temp better [20:31:33] <merbanan> nfl: when you get soc repo access, commit it, no need for more review, the code will be looked at more after you add more code [20:32:03] <merbanan> nfl: create some ref sample, implement a demuxer for that format so you can run the bitstream through the decoder [20:32:13] <merbanan> ref samples [20:32:49] <BBB> don't we have some on mphq? [20:32:59] <merbanan> nope [20:34:43] <merbanan> nfl: after that continue with synthesis [20:34:46] * BBB passed the 300-patch mark in ffmpeg o/ [20:34:53] <merbanan> nfl: any questions ? :) [20:35:21] <nfl> no sir :) [20:36:06] <merbanan> goodie, should keep you bizzy for a while, can you email me the spec you have also ? [20:36:32] <nfl> ok [20:44:58] <nfl> merbanan, have sent it [20:45:26] <nfl> btw the stuff you asked me to do will take me a while, i'm spat in the middle of exams. hope this is ok [20:46:35] <merbanan> sure, work on your exams [20:47:36] <merbanan> nfl: send your schedule for the summer also [20:47:58] <merbanan> after you did your exams that is [20:48:17] <nfl> ok [20:48:46] <nfl> btw are you from sweden? [20:49:04] <merbanan> YES! the kingdom of Sweden [20:49:27] <nfl> :) [20:49:29] <nfl> just wanted to brag to friends [20:49:37] <merbanan> hahaha, you do that [20:51:54] <merbanan> nfl: you resided somewhere in India ? [20:52:57] <merbanan> nfl: when you brag, you can say that I am from The GREAT kingdom of Sweden, famous for the pirate bay and blue eyed blonde girls [20:55:25] <nfl> crap [20:55:35] <nfl> merbanan, did you get the spec yet? [20:56:17] <merbanan> nope, but I got a mail that said that they where attached [20:56:53] <BBB> hehe :) [20:57:42] <nfl> hey don't blame me. its always my crappy connection [20:58:52] <merbanan> nfl: well I don't need them now, just send them sometime next week [20:59:38] <nfl> attempting again... [21:08:31] <nfl> merbanan, here: http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.723.1-200605-I!!SOFT-ZST-E&type=items [21:10:06] <merbanan> jolly good [21:11:04] <merbanan> look at that, ref samples [21:11:24] <nfl> yup [21:13:19] <BBB> that server is slow... [21:13:39] <BBB> maybe place them on mphq... [21:15:18] <merbanan> nice, reordering tables [21:15:35] <merbanan> there is some work for someone to do :) [21:15:42] <kierank> BBB: itu server is always slow as hell [21:16:32] <nfl> bring it on :) [21:17:40] <merbanan> to bad the spec isn't self contained [21:18:26] <nfl> what do you mean? [21:19:56] <merbanan> you need to look at the ref code also [21:20:38] <merbanan> to write a decoder [21:20:48] <merbanan> can't only look at the pdf spc [21:22:44] <nfl> ok [21:28:33] <CIA-7> ffmpeg: michael * r22957 /trunk/libavutil/log.c: [21:28:34] <CIA-7> ffmpeg: 4th try at getting ansi colors working with a default of color=yes_please. [21:28:34] <CIA-7> ffmpeg: Colors will only be used if the TERM env var is set and NO_COLOR is not set. [21:32:52] <Dark_Shikari> lol [21:33:22] <BBB> poor Michael [21:34:56] <bcoudurier> hi guys [21:35:51] <janneg> bcoudurier: hi [21:37:26] <janneg> bcoudurier: do you know if there's a reason why the ts demuxer emits pes packets only after the next is started? [21:40:30] <bcoudurier> that's not always the case [21:40:51] <bcoudurier> it's because the pes packet length can be 0 [21:44:19] <janneg> yes, if the pes size is unbound it's obviously necessary [21:46:49] <janneg> bcoudurier: http://pastebin.com/Tqc5uj5M fixes delayed DVB subtitles in mythtv [21:47:35] <janneg> ffplay doesn't show the same problem since it queues audio, video and subtitle packets [21:47:54] <_av500_> and you dont? [21:48:00] <janneg> no [21:48:06] <_av500_> at all? [21:48:19] <_av500_> gee [21:48:21] <janneg> only video packets [21:48:51] <bcoudurier> indeed, gee [21:50:07] <_av500_> janneg: but the "next" pes packet is like a few bytes later, no? [21:50:43] <janneg> even if we did it's still a problem since there could minutes/hours until the next subtitle packet starts [21:50:56] <janneg> _av500_: the next pes packet on the same pid [21:51:23] <_av500_> and they are interleaved? [21:52:43] <bcoudurier> I think the patch is ok [21:52:49] <bcoudurier> I don't like the condition though [21:54:32] <janneg> total_size is the pes_data_length from the header, i.e. counting only the bytes after it [21:54:45] <janneg> that's there the 6 is comming from [21:56:08] <janneg> it should probably become a define [21:56:13] <bcoudurier> no define [21:56:25] <bcoudurier> I don't want to search through 3 files to find what vaue it is [21:56:40] <bcoudurier> commenting near the value is enough [21:56:43] <janneg> otherwise I don't see how I could make it prettier [21:56:58] <_av500_> color is used a lot these days [21:57:42] <janneg> GCC accepts rtf now or only ooxml? [21:58:41] <janneg> or html? and it ignore <blink>bla</blink> randomly? [21:59:30] <drv> maybe it has a javascript interpreter too, and we can then write cross-compilation-unit scripting exploits [22:13:39] <janneg> bcoudurier: patch sent [22:17:47] <bcoudurier> I'm not sure the 6 is right [22:19:26] <bcoudurier> humm no, it is [22:19:40] <bcoudurier> logic is obfuscated here [22:22:34] <bcoudurier> humm the size should be exact here [22:27:28] <janneg> yes, forgot to change it [22:32:49] <FUautotools> ffs, I wish log.c would stay static for a while [22:57:11] <bcoudurier> FUautotools, use releases [23:20:33] <Dark_Shikari> mru: do you think it's possible to get an h264 stream decoding in realtime on an iphone 3G? I.e. pre-Cortex. [23:20:46] <Dark_Shikari> i.e. with decent asm + encoder-side limitations [23:20:49] <RTFM_FTW> - yes [23:20:55] <Dark_Shikari> up to and including no deblock, no cabac, and no subpel [23:20:59] <Dark_Shikari> and by h264 stream I mean full iphone screen res