[FFmpeg-devel-irc] IRC log for 2010-04-23

[irc at mansr.com]

[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-list-2010-04-22
[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.html?talkid=425
[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