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

[irc at mansr.com]

[00:03:46] <DonDiego> gnite
[00:44:18] <Dark_Shikari> is there an easy way to loop over random numbers in a shell script?
[00:44:24] <Dark_Shikari> e.g. for a in $(seq 1000)
[00:44:27] <Dark_Shikari> except randomely distributed?
[00:45:24] <Kovensky> $RANDOM?
[00:45:40] <Dark_Shikari> yeah, but I need it in a specific range
[00:46:40] <J_Darnley> scale it with some math?
[00:46:49] <Dark_Shikari> guess that works
[00:46:50] <Dark_Shikari> echo to bc
[00:47:26] <J_Darnley> does bc not have a random generator?
[00:47:47] <Dark_Shikari> no idea
[00:49:33] <J_Darnley> I can't find it in the man page with grep...
[00:50:04] <Dark_Shikari> well $RANDOM seems to be fine
[00:51:25] <Dark_Shikari> yay, I have a script to make about 16 gigabytes of randomely fragmented data
[00:55:49] <J_Darnley> "yay" is definitely the right word!
[01:13:03] <mru> Dark_Shikari: $RANDOM is bash only
[01:13:30] <Dark_Shikari> works for me.
[01:13:35] <mru> you could conjure an lcg in standard sh easily enough
[01:14:24] <Dark_Shikari> effort
[01:14:31] <Dark_Shikari> 550 megs of random fragmented data created
[01:15:03] <mru> what does that even mean?
[01:15:29] <Dark_Shikari> writing random files of random size into random folders
[01:15:35] <Dark_Shikari> once it's all done, I'll perform a linear read
[01:15:41] <Dark_Shikari> thus, from the perspective of the linear read, the files will be fragmented
[01:16:28] <mru> what's the purpose of this?
[01:17:03] <ohsix> theres a fuse filesystem that does that sort of thing (creating huge files, random files, random filenames)
[01:17:12] <Dark_Shikari> mru: benchmarking a stupid idea of mine
[01:17:21] <Dark_Shikari> a grep that performs prefetch using madvise
[01:17:36] <mru> ohsix: I suppose he wants to benchmark real filesystems
[01:17:48] <Dark_Shikari> yes
[01:18:06] <mru> doesn't linux have readahead anyway?
[01:18:13] <ohsix> heh, then you're just benchmarking the filesystem
[01:18:21] <Dark_Shikari> mru: how do you know what the program is going to access next?
[01:18:25] <Dark_Shikari> it has readahead within a file, sure
[01:18:33] <Dark_Shikari> but predicting the next access of a program is an area of decades of research
[01:18:42] <mru> across files it'll be hard, true
[01:18:44] <Dark_Shikari> including a great deal of stupid things like context-modelling filesystems
[01:18:53] <Dark_Shikari> (that idea actually worked pretty well)
[01:18:57] <mru> simple is almost always better
[01:19:11] <mru> like they finally ditched the silly anticipatory io scheduler in linux
[01:19:19] <mru> everybody was using cfq or deadline anyway
[01:20:27] <Dark_Shikari> well basically the idea of the prefetching is that the filesystem internally reorders disk reads
[01:20:30] <Dark_Shikari> i.e. on the millisecond-level
[01:20:35] <Dark_Shikari> in order to better schedule disk head moves, etc
[01:20:40] <Dark_Shikari> the disk does some of it as well
[01:20:50] <Dark_Shikari> so, if you prefetch a ton of stuff ahead of time, instead of using blocking reads, you'll get better speed.
[01:21:22] <Dark_Shikari> (actually I'm doing both: I'm keeping the blocking reads, with the assumption that they'll be faster if we're using prefetching)
[01:21:28] <mru> yeah, if you maintain a queue of stuff to read, the fs or block layer has a chance of reordering it optimally
[01:21:40] <Dark_Shikari> basically I'm spawning a shitton of threads, one for every file
[01:21:44] <Dark_Shikari> open, mmap, madvise
[01:21:47] <Dark_Shikari> wait a few milliseconds, close
[01:21:47] <mru> have you looked at aio?
[01:21:50] <Dark_Shikari> aio?
[01:21:53] <mru> async i/o
[01:21:57] <Dark_Shikari> how's that work?
[01:22:21] <mru> kind of like a read that returns immediately
[01:22:30] <mru> then the actual read happens in the background
[01:22:33] <Dark_Shikari> and then tells you later
[01:22:34] <Dark_Shikari> ?
[01:22:37] <mru> yeah
[01:22:40] <astrange> http://www.opengroup.org/onlinepubs/009695399/functions/aio_read.html
[01:22:55] <astrange> if you're starting new threads to fake async io definitely look at that
[01:23:10] <mru> also check all the various extended syscalls linux has
[01:23:17] <mru> it has quite a few things to improve io
[01:23:22] <astrange> ...or reimplement a c10k web server and do 10000 non-blocking read() calls + kqueue
[01:23:30] <Dark_Shikari> lol
[01:23:43] <mru> c10k?
[01:23:59] <Dark_Shikari> http://en.wikipedia.org/wiki/C10k_problem ?
[01:24:11] <mru> I've heard of the y10k problem
[01:24:27] <astrange> http://www.kegel.com/c10k.html
[01:26:37] <mru> that's 4 years old
[01:26:42] <mru> a lot has happened since
[01:27:20] <astrange> i'm watching nginx serve 20k connections right now using basically what it recommends for freebsd
[01:27:26] <astrange> but it doesn't quite apply to disk io
[01:35:56] <mru> bsd probably hasn't changed much in the last 4 years
[01:36:05] <mru> or 24 years for that matter
[01:50:25] <mru> “C++ is a language strongly optimized for liars and people who go by guesswork and ignorance.”
[05:25:33] <pJok> god morgon kshishkov :)
[05:26:55] <wbs> lu_zero/mru: yes, the patches were done with git show... should've used format-patch instead to ease application with am, yes
[05:48:02] <thresh> moroning
[05:48:39] <kshishkov> as you say
[06:03:56] <pJok> god morgon kshishkov :)
[06:04:20] <kshishkov> goda morgnar
[06:05:17] <av500> kshishkov: "guten morgen" :)
[06:05:52] <kshishkov> av500: that's in German
[06:06:26] <kshishkov> and it has nothing to do with either my homeland or country where I live
[06:19:40] <merbzt> god morgon
[06:20:54] <superdump> gomorron merbzt
[06:21:06] <wbs> morgon
[06:23:50] * kshishkov renames channel to #ffmpeg-devel-se
[06:30:38] <pJok> its getting there
[06:40:13] <peloverde> Anyone know what "aacaot" means in FLV, is it really the profile ID, the docs seem a little off: http://www.adobe.com/devnet/flash/articles/flvplayback_fplayer9u3_04.html
[06:41:54] <av500> http://en.wikipedia.org/wiki/MPEG-4_Part_3#MPEG-4_Audio_Object_Types maybe?
[06:42:09] <astrange> 0 is not a valid object type
[06:42:13] <astrange> and 1 doesn't exist in the wild
[06:42:14] <peloverde> indeed
[06:42:30] <peloverde> adobe's docs say "AAC audio object type; 0, 1 or 2 are supported"
[06:42:38] <av500> its adobe
[06:43:16] <peloverde> Also I know flash does support AOT_MAIN, even though no one uses it
[06:43:19] <av500> and anyway, what in FLV would depend on the object type?
[06:44:02] <peloverde> If it finds a predictor bit in the stream it needs to know what kind of predictor follows?
[06:45:27] <av500> so that is out of band info to be given to the decoder?
[06:45:48] <peloverde> indeed, it is sent out of band
[06:46:18] <peloverde> in mp4 it's in the extradata it's called the AudioSpecficConfig or m4ac
[06:46:37] <av500> I just checked my flv demuxer, it gets 2 bytes to be used for that
[06:46:47] <peloverde> In ADTS it's offset by 1, which is the usual source of mismatches in the wild
[06:49:20] <peloverde> makes sense, for normal channel counts and normal sample rates for common aac variants the full AudioSpecficConfig is two bytes
[06:50:04] <av500> and these 2 bytes are part of the flv file
[06:50:31] <peloverde> makes sense, I'm getting that format extradata passed to the decoder
[06:50:34] <av500> same code in lavf/flvdec
[06:50:35] <astrange> always 2 bytes? because it's 5 for sbr-in-lc
[06:50:57] <peloverde> astrange, forward configured SBR is a fancier variant
[06:51:02] <peloverde> for ALS it's soemthing like 6 bytes
[06:51:24] <peloverde> 9 bits just to get the object type
[06:51:33] <av500> astrange: sorry, misread, no it is not fixed size 2
[06:51:41] <av500> it is whatever flv provides
[06:51:44] <peloverde> 2 is the minimum size though
[06:52:48] <av500> so, looks to me like this aacaot can be ignored
[06:53:02] <av500> as AudioSpecficConfig is included anyway
[06:53:19] <peloverde> wow, this file was correct!
[06:53:32] <peloverde> aacaot was 1, the AOT in the AudioSpecficConfig was 1
[06:53:42] <peloverde> and predictor present is true!
[06:53:49] <peloverde> AAC main in the wild!
[06:54:02] <saintdev> main, OMG!
[06:54:06] <astrange> where's that file? it probably doesn't work in perian
[06:54:21] <astrange> although 10.6.3 fixed 96khz sbr just today
[06:54:28] <peloverde> I will upload a sample soonish
[06:55:04] <peloverde> Also it's hulu stream if people are curious
[06:55:16] <saintdev> hulu is using main?
[06:55:29] <peloverde> for some programs
[06:55:51] * saintdev wishes hulu still worked with 64-bit flash in linux :(
[06:55:58] <peloverde> I always assumed if someone were to use main in flash it would be for relaxed TNS not for the main profile predictor
[06:56:19] <peloverde> saintdev, if it did I would not have discovered this remarkable stream
[06:56:29] <saintdev> lol
[06:56:34] <ohsix> saintdev: it doesn't? are you using nspluginwrapper?
[06:56:54] <saintdev> ohsix: true 64-bit flash is broken, has been since around january
[06:57:04] <saintdev> ohsix: 32-bit with nspluginwrapper will work
[06:57:14] <ohsix> hrm i've been watching it on my laptop fine
[06:57:33] <saintdev> probably 32-bit with wrapper then
[06:58:19] <ohsix> nah its the real thing, is it only some streams or shows?
[06:58:25] <saintdev> all of them
[06:59:08] <saintdev> you will get a message that says "We're sorry but we're unable to stream videos to your system. This may be due to an Adobe software limitation on 64-bit Linux systems."
[06:59:14] <ohsix> hah wtf, shows a warning too; i was playing video on it fine a while ago
[06:59:35] <ohsix> is it because the ads weren't working or something? cuz those seemed broke
[06:59:40] <peloverde> I guess it's time to optimize AAC-Main, 45% in apply prediction is less than ideal
[07:00:26] <saintdev> ohsix: somebody suspected that's why, but it's been broken since january (they just put up the message about it being an adobe limitation this month)
[07:00:37] <saintdev> and ads have worked for me for quite a while
[07:00:39] <ohsix> ic
[07:01:13] <saintdev> you must have somehow been using 32-bit flash :/
[07:01:16] <ohsix> the ads were acting funky but i never bothered to look, cuz it would skip them when they malfunction :>
[07:01:27] <ohsix> nah; its just been longer than i thought
[07:01:35] <saintdev> hah
[07:02:11] <ohsix> i did watch it a bunch on this thing though; that sucks
[07:02:14] <saintdev> thankfully the non-hulu backed videos on fancast still work :D
[07:03:59] <peloverde> astrange, http://samples.mplayerhq.hu/A-codecs/AAC/hulu-aac-main.flv
[07:04:47] <saintdev> peloverde: so were you trying to figure out what was going wrong between hulu and flash?
[07:05:22] <peloverde> saintdev, I was sick of rebooting to watch hulu and decided to test out rtmpdump
[07:05:53] <peloverde> and I noticed the aacaot = 1 in the metadata which seemed funny
[07:06:01] <saintdev> haha
[07:07:09] <peloverde> It kind of makes me glad I bothered with AAC Main a few months ago, otherwise I'd have to use that other decoder
[07:07:40] <kshishkov> yes, it's more funny if *you* have to use faad2 for AAC decoding
[07:08:05] <peloverde> See, my motivation to work on ffaac is purely selfish
[07:08:16] <av500> itch -> scratch
[07:08:40] <kshishkov> well, I have some codecs I did neither for fame nor money
[07:09:56] <peloverde> Actually I saw that flash supported AOT_MAIN and foresaw something like this happening, or at least someone refusing to use ffaac because it didn't support all the features flash does
[07:10:56] <kshishkov> kick drv for not having Flash Screen Video 2 decoder so someone can blame FFmpeg for not supporting all flash codecs
[07:53:40] <CIA-1> ffmpeg: cehoyos * r22727 /trunk/libavcodec/vdpau.c:
[07:53:40] <CIA-1> ffmpeg: Fix VDPAU for H.264 streams with long reference frames.
[07:53:40] <CIA-1> ffmpeg: Patch by Stephen Warren.
[08:11:18] <CIA-1> ffmpeg: cehoyos * r22728 /trunk/libavcodec/ (h264.c vdpau.c vdpau_internal.h):
[08:11:18] <CIA-1> ffmpeg: Set VDPAU H264 picture parameter field_order_cnt and frame_num at the
[08:11:18] <CIA-1> ffmpeg: start of decoding a picture instead of at the end.
[08:11:18] <CIA-1> ffmpeg: Fixes mmco01.264
[08:11:18] <CIA-1> ffmpeg: Patch by Stephen Warren
[08:42:02] <thresh> hyc: any plans on making librtmp shared?
[08:43:58] <bilboed-pi> shared as in shared library usable by many projects ?
[08:44:09] <thresh> exactly
[08:44:15] <bilboed-pi> that would totally rock
[09:23:11] <merbzt> http://www.boingboing.net/2010/03/29/philip-pullman-on-ce.html
[09:28:56] <superdump> does anyone have 14496-15?
[09:29:44] <kshishkov> ISO store has for sure :P
[09:30:00] <superdump> :p
[09:32:30] <kshishkov> I once suggested that FFmtech should provide FFmepg devs with all standards
[09:32:33] <kshishkov> *FFmpeg
[09:37:56] <av500> kshishkov: thats a sh*tload of money to be paid
[09:38:59] <Dark_Shikari> especially with specs like blu-ray
[09:39:01] <Dark_Shikari> that cost $5k+
[09:39:07] <Dark_Shikari> of course, given the size of the spec that might be a distribution fee
[09:39:16] <KotH> well...
[09:39:27] <kshishkov> av500: that's why I also suggested that KotH is to pay for them
[09:39:34] <KotH> heh?
[09:39:36] <KotH> what?
[09:39:38] <KotH> why me?
[09:39:41] * KotH is poor
[09:39:45] <kshishkov> you'
[09:39:55] <kshishkov> re the only one with Swiss Francs
[09:41:19] <KotH> i'm still poor
[09:42:01] <kshishkov> so am I
[09:42:08] <kshishkov> still better you than me
[09:42:32] * kshishkov is poor and in Ukraine
[09:43:23] <av500> poorkraine
[09:43:46] <KotH> ok.. you winn
[09:46:04] <av500> superdump: online version: http://www.docin.com/p-26314574.html  :)
[09:48:53] <av500> KotH: surely you can spare 77HK$, no? http://cgi.ebay.com.hk/ws/eBayISAPI.dll?ViewItem&item=190383357607
[09:49:52] <superdump> are specs resellable? :)
[09:50:21] <av500> why not?
[09:51:15] <KotH> depends on the jurisdiction you live in
[09:51:24] <KotH> but... this actually sounds quite interesting
[09:53:13] <av500> of course it is not legal
[09:53:29] <KotH> actually, for me it doesnt matter whether it is legal or not
[09:53:35] <KotH> i'm not the one making the copies :)
[09:53:40] * KotH likes to live in .ch ;-)
[09:54:12] * thresh would like to live anywhere but former USSR
[09:54:36] * KotH wonders why people dont leave if they hate it where they live
[09:55:33] <iive> av500: it may be legal in china.
[09:55:54] <thresh> KotH: not really easy to find a job
[09:55:59] <thresh> i'm no programmer
[09:56:19] <KotH> what's the prob with that?
[09:56:41] <KotH> we've thousands of turkish and ex-yugoslavian here in .ch that barely know how to read and write
[09:56:51] <thresh> they probably don't need a visa
[09:56:55] <KotH> lol
[09:56:57] <KotH> yeah.. right
[09:58:45] <thresh> and i don't have an academic degree, too
[09:59:04] <thresh> so the best way for me to move out is to find a bride somewhere in .eu ;-)
[09:59:30] <av500> gee, now I registered at that chinese site, now they want money to download the pdf... I give up
[10:00:38] <KotH> nah.. just claim that you are a political refugee and all countries in the .eu will take you in.. if you come to .ch, the leftists here will even greet you at the airport and kiss your feet
[10:00:59] <KotH> av500: what site?
[10:01:02] <KotH> av500: what pdf?
[10:01:06] <av500> http://www.docin.com/p-26314574.html
[10:01:23] <av500> it has a download button, but you need to reg and upload money
[10:01:48] <KotH> upload virtual money
[10:01:55] <av500> maybe I get upload credit if I make a pdf out of ff source code
[10:03:03] <av500> ah, no, I cant: "....3. Prohibits the publication of terror, murder...."
[10:03:28] <nfl> superdump: hi i've completed the g723.1 frame parser but have a few doubts
[10:03:40] <superdump> ... that was quick
[10:03:48] <superdump> did you do it from the spec?
[10:03:49] <thresh> KotH: that has a downside of a chance being poisoned with polonium
[10:03:55] <superdump> if there is a spec available
[10:04:06] <nfl> spec + reference decoder
[10:04:22] <superdump> did you copy code from the reference decoder?
[10:04:47] <merbzt> the g723.1 spec sux
[10:04:59] <merbzt> one must look at the ref code :/
[10:05:28] <KotH> thresh: just dont let you get caught!
[10:05:55] <thresh> and don't drink tea with KGB agents, check
[10:07:00] <superdump> merbzt: oh, it's like that again eh?
[10:07:06] <merbzt> yupp ;)
[10:07:07] <superdump> merbzt: what is g.723.1 like?
[10:07:19] <merbzt> like one mode of amr
[10:07:25] <superdump> hmm
[10:07:26] <merbzt> or 2 I think
[10:07:35] <superdump> does it go by some other name?
[10:07:36] <merbzt> with somewhat less features
[10:07:40] <merbzt> no
[10:07:50] <merbzt> it is one voip codec
[10:07:55] <merbzt> a common one
[10:08:16] <merbzt> my voip box can use g723.1
[10:08:21] <merbzt> or g729
[10:08:29] <merbzt> or g711
[10:08:45] <superdump> why did they make so many so very similar but slightly different celp codecs?
[10:08:49] <superdump> it's STUPID!
[10:09:04] <superdump> they only needed 1 sane one
[10:09:05] <wbs> couldn't they use names using letters instead of just numbers? ;P
[10:09:15] <merbzt> no challenge in that
[10:09:21] <superdump> :)
[10:09:24] <merbzt> the funny part is that there is a g723 also
[10:09:40] <merbzt> totally different from g723.1 (adpcm vs celp IIRC)
[10:09:57] <merbzt> though g723 is deprecated or something
[10:09:57] <superdump> aaaargh
[10:10:04] <superdump> There are two bit rates at which G.723.1 can operate:
[10:10:07] <superdump> 6.3 kbit/s (using 24 byte frames) using a MPC-MLQ algorithm (MOS 3.9)
[10:10:09] <superdump> 5.3 kbit/s (using 20 byte frames) using an ACELP algorithm (MOS 3.62)
[10:10:17] <merbzt> yes, that was it
[10:19:43] <av500> superdump: got it
[10:25:42] <nfl> sorry abt that. ive got a really crappy connection
[10:26:15] <nfl> superdump: as i was saying, am i supposed to write an rtp depacketizer as well?
[10:33:12] <nfl> superdump: are you there?
[10:38:26] <merbzt> we are always here
[10:38:44] <merbzt> write a rtp depaketizer also if you feel like
[10:38:52] <merbzt> I doubt it will be to hard
[10:39:00] <nfl> ;)
[10:39:20] <nfl> merbzt: what i wanted to know was that if g.723.1 has a storage format?
[10:39:29] <twnqx> heh... from an company internal document on IPTV deployments
[10:39:33] <twnqx> Remember, in case you had forgotten, STAY WAY FROM MICROSOFT MEDIAROOM IPTV AS IT IS A CLOSED WORLD. HERE BE DRAGONS !!
[10:40:00] <nfl> merbzt: and if not, i will need a depacketizer right?
[10:40:22] <merbzt> nfl: I now there are some g723.1 sample files in wav
[10:40:35] <nfl> merbzt: ok
[10:40:39] <merbzt> but nothing more then that and from the ref suit
[10:42:44] <merbzt> http://tranquillity.ath.cx/files/G7231QN.wav
[10:42:47] <merbzt> like magic
[10:43:19] <nfl> merbzt: thank you
[10:43:31] <merbzt> I have no idea if that is a real working sample
[10:44:18] <nfl> btw how careful should i be when writing a frame parser based on the reference decoder?
[10:44:32] <nfl> there are only so many ways one can parse frames
[10:44:42] <merbzt> w8
[10:46:19] <merbzt> base it of this first http://tranquillity.ath.cx/files/G723dot1.c
[10:46:46] <merbzt> http://tranquillity.ath.cx/files/G723dot1.h
[10:46:52] <merbzt> forgot I had those files
[10:47:31] <merbzt> vivog723 might be g723.1
[10:49:01] <nfl> lemme get this straight, by a frame parser i am supposed to write code similar to that in g723dot1_get_bitstream_parameters() in ur code, rite?
[10:49:33] <merbzt> yes
[10:49:59] <nfl> i've already done that. but why is not your code committed?
[10:50:41] <merbzt> I is committed
[10:50:50] <merbzt> in my own repo :)
[10:51:23] <merbzt> yeah, I suck it should have been in the soc repo
[10:51:48] <nfl> so g.723.1 soc task is off :( ?
[10:53:26] <nfl> superdump: are you back?
[10:53:44] <nfl> +yet?
[10:53:59] <superdump> i'm having lunch at the moment
[10:54:11] <superdump> but you don't need to speak to me particularly, anyone here is ifne
[10:54:12] <nfl> ok i'll wait
[10:54:14] <superdump> fine*
[10:54:28] <superdump> i can catch up from merbzt later or so
[10:55:26] <nfl> merbzt: ?
[10:57:29] <DonDiego> superdump: Rathann was having some trouble with an aac sample yesterday
[10:59:05] <DonDiego> http://www1.mplayerhq.hu/~diego/
[10:59:12] <DonDiego> the [Frostii] files
[11:06:46] <merbzt> nfl: nono, the decoder is far from complete, and we need an encoder also
[11:07:06] <nfl> so do i just post my parser.c to the soc ml?
[11:07:14] <merbzt> you do that
[11:56:41] <superdump> hmm, diego's not here any more
[11:56:52] <superdump> sync -> timestamps -> container
[11:57:21] <superdump> unless it works with faad
[11:58:45] <mru> superdump: well, he said the sound was badly distorted
[11:58:50] <mru> forget sync
[11:59:01] <superdump> oh
[11:59:04] <superdump> ok
[11:59:41] <kshishkov> bad sync to ears then :)
[12:00:06] <mru> whatever problem he had, any sync issues were secondary
[12:00:19] <mru> it plays fine here
[12:00:40] <superdump> mru: it plays fine there with ffplay?
[12:00:46] <mru> yes
[12:00:48] <superdump> ok
[12:01:15] <kshishkov> mru: don't forget about his cutting edge AMD CPU. Might be a problem with SIMD func somewhere
[12:01:46] <mru> what cpu does he use?
[12:01:54] <superdump> k6-300?
[12:02:50] * kshishkov uses Loongson 2F too but it also has shitty DSP
[12:03:59] <Compn> ehe
[12:04:08] <Compn> i think i have a k6 collecting dust somewhere
[12:05:38] <pross-au> i have two
[12:06:05] <superdump> works for me as well
[12:06:16] <superdump> although the speech sort of overlaps itself
[12:07:42] <iive> k6 have mmx1 and the 300mhz may have 3dnow1 too.
[12:09:08] <pross-au> I have K6-II and III btw
[12:09:25] <pross-au> The III+ had extended 3dnow iirc
[12:10:23] <KotH> yes, it had
[12:15:17] * kshishkov still has PII-266 not buried
[12:18:21] <pross-au> Meh, there is an 8088 here
[12:18:26] <pross-au> EGA :D
[12:19:09] <nfl> ok, ive posted the code to the soc ml.
[12:20:33] <kshishkov> pross-au: IIRC it was only around dawn of Pentiums when rich people here could afford to buy a computer
[12:21:49] <KotH> kshishkov: i can beat that
[12:22:15] <KotH> kshishkov: i have a dual P-II 266 with 154MB ram!
[12:22:34] <kshishkov> mine is single but with 192MB (and 4GB HDD)
[12:24:32] <av500> mru: didnt we have that issue before with ffplay
[12:24:42] <av500> that is played ok for some people and not for others
[12:25:24] <av500> but that was related to 6ch...
[12:27:52] <av500> and this file is 6ch as well
[12:28:09] <kshishkov> maybe crappy libSDL version
[12:28:47] <kshishkov> for example Diego had FFplay crashing on MacOSX/PPC with SDL 1.3
[12:29:07] <mru> I'll gladly blame sdl for anything
[12:29:08] <av500> yep, same distorted sound here
[12:29:18] <nfl> superdump, merbzt pl take a look at my code
[12:29:21] <av500> as was the case last time for me as well
[12:29:36] <av500> still SDL accepting 6ch but playing it over 2
[12:29:43] <av500> (I assume)
[12:30:15] <av500> since we ask all decoder for 2ch downmix, why dont we limit SDL to 2ch as well?
[12:30:38] <kshishkov> someone may have 6ch working (theoretically)
[12:30:53] <av500> yes, but they will not get 6ch DTS or AC3
[12:31:04] <kshishkov> may be the same reason why nobody has fixed swapped colours output on MacOSX/PPC
[12:31:05] <av500> as those decoders are able to downmix, and we ask for 2ch
[12:31:09] <mru> ok, this is messed up... _now_ it's distorted here with ffplay
[12:31:51] * janneg blames the cern
[12:32:50] <kshishkov> janneg: in his case it may be Stonehenge restarted ;)
[12:33:14] <mru> ah, that's what it is
[12:33:24] <mru> stonehenge is an ancient particle accelerator
[12:33:28] <janneg> ah finaly, they fixed the echo in the webcast
[12:33:48] <iive> does somebody know good dvb parser? it's better if it is free (in any meaning).
[12:33:52] <av500> cern did that too?
[12:34:24] <mru> iive: parser how?
[12:34:32] <av500> psu?
[12:34:34] <av500> psi?
[12:34:48] <iive> to parse the tables and descriptors from the dvb standard.
[12:35:09] <mru> I don't think anyone has ever written a complete one
[12:35:13] <iive> and preset them in human understandable form.
[12:35:21] <janneg> iive: dvbsnoop
[12:35:57] <merbzt> iive: tvheadend has a parser also
[12:36:01] <iive> janneg: somehow it can't parse anything if i give him captured file.
[12:36:17] <merbzt> not so user friendly though
[12:36:23] <janneg> iive: are you using -tssubdecode?
[12:38:32] <iive> merbzt: i'll give it a try.
[12:41:13] <iive> janneg: i think i've tried all options, but when i get the dvbsnoop command line as part of the parsed bitstream, i get doubts....
[12:46:04] <janneg> iive dvbsnoop -s ts -tssubdecode -if FILE -n 300 0x0 produces a parsed PAT if there is one in the first 299 TS packets
[12:51:10] <iive> janneg: i'll try it again.
[12:53:09] <nfl> merbzt, superdump what do you think of the code?
[12:53:26] <superdump> i'm afraid i'm at work at the moment so i don't have time to look at it
[12:53:37] <nfl> ok
[12:53:45] <kshishkov> nfl, just wait until you get a reply by mail
[12:54:08] <iive> janneg: seems to work. thanks a lot.
[12:54:25] <kshishkov> and in the future please send code as attach, otherwise formatting may be screwed
[12:54:44] <nfl> ok
[13:34:47] <Ryen> Hi
[14:18:54] <nfl> merbzt: ffmpeg says the sample is Audio: pcm_s16le, 22050 Hz, 1 channels, s16, 352 kb/s. what changes do i need to make for it to be detected as g723.1 (if it _is_ g723.1)?
[14:26:30] <merbzt> hmm, ok then it was just a wav file with the decoded sound
[14:26:34] <merbzt> nm then
[14:28:34] <nfl> merbzt: so will i need an rtp depacketizer?
[14:28:41] <merbzt> yupp
[14:29:11] <nfl> but the prob is that i can't find the documentation for it anywhere
[14:29:46] <nfl> there are rfcs for payload formats for most of the g_ formats, but not for g723.1
[14:30:02] <merbzt> http://tools.ietf.org/html/rfc3551#section-4.5.3
[14:33:05] <nfl> i did see that document, but is it exactly a payload spec?
[14:33:24] <merbzt> yes it is :)
[14:33:41] <merbzt> one byte prefixed
[14:34:00] <nfl> fine then
[14:34:59] <merbzt> umm, can you check if the truespeechcode in ffmpeg matches g723.1 ?
[14:35:24] <kshishkov> unlikely
[14:36:04] <kshishkov> it's very old and quite simple - even I could RE it
[14:43:39] * nfl kicks himself btw
[14:44:04] <kshishkov> we don't mind, do continue
[14:46:20] <nfl> so is the depacketizer part of the qual task too? ;)
[14:46:32] <nfl> or am i qualified now?
[14:46:49] <merbzt> kshishkov: pendel :)
[14:47:05] <merbzt> nfl: depacketizer would be nice
[14:47:11] <kshishkov> merbzt: don't remind me of X60
[14:47:23] <merbzt> X60 ?
[14:47:39] <kshishkov> http://sv.wikipedia.org/wiki/X60
[14:48:00] <merbzt> kshishkov: http://attuworld.nl/wp-content/uploads/2010/03/0733_7da4.gif
[14:49:06] <kshishkov> it's hard to make a smiley out of that though
[14:49:14] <nfl> merbzt: you didnt exactly answer my question ;)
[14:49:30] <kshishkov> nfl: there's no such thing as overqualification
[14:49:30] <merbzt> we need to see the depacketizer
[14:49:44] <nfl> on it :)
[15:01:11] <superdump> BBB: what the fudge is going on with the postfilter stuff?
[15:01:39] <kshishkov> makes sounds tastier?
[15:01:42] <superdump> the test results you posted are somewhat confusing
[15:01:58] <BBB> huh?
[15:02:01] <BBB> what's confusing
[15:02:14] <BBB> I'm trying to test and see if this conforms to the spec
[15:02:21] <BBB> I implemented it from a PDF spec I found online
[15:02:28] <BBB> vitor wants me to confirm with the ref decoder
[15:02:31] <BBB> and that was a bit confusing
[15:02:41] <BBB> I think it does, at least it's very close
[15:02:45] <superdump> the numeric data is a bit confusing
[15:02:46] <merbzt> the ref doesn't post filter IIRC
[15:02:50] <BBB> merbzt: I made it
[15:02:54] <BBB> merbzt: it's a flag
[15:02:54] <merbzt> ok
[15:03:02] <BBB> that's why my first check was wrong
[15:03:10] <BBB> I didn't know it didn't postfilter at that point
[15:03:26] <BBB> superdump: how is it confusing?
[15:03:33] <BBB> superdump: I can explain, I have all data here ;)
[15:03:40] <superdump> one moment
[15:04:09] <kshishkov> BBB: damn lies, statistics and benchmarks?
[15:04:14] <BBB> yes
[15:04:18] <BBB> ;)
[15:05:10] <superdump> bash-3.2$ tests/tiny_psnr ~/Desktop/out-{us,ref-nopf}.wav 2 0 44
[15:05:11] <superdump> stddev:  447.74 PSNR: 43.31 bytes:  8820800/  8820800
[15:05:20] <superdump> bash-3.2$ tests/tiny_psnr ~/Desktop/out-{nopf,ref-pf}.wav 2 0 44
[15:05:22] <superdump> stddev:  405.09 PSNR: 44.18 bytes:  8820800/  8820800
[15:05:29] <superdump> what's the difference between these two comparisons?
[15:05:34] <superdump> oh
[15:05:43] <superdump> now i pasted them and they're side by side, it's clearer
[15:05:44] <superdump> hehe
[15:05:51] <superdump> i'm just misparsing the filenames
[15:05:53] <kshishkov> it's better with postfilter, sorry to improve your sound
[15:05:56] <superdump> you could have made that simpler...
[15:06:12] <BBB> superdump: I'm lazy :(
[15:06:38] <superdump> so 'us' is with ffmpeg with pf
[15:06:40] <BBB> if I could use html or excel I'd have made a nice cross-check--list
[15:06:42] <BBB> yes
[15:06:45] <superdump> and nopf is ffmpeg without pf
[15:06:48] <BBB> yes
[15:06:57] <BBB> ref-nopf/pf is reference without or with pf
[15:07:10] <kshishkov> BBB: can you look at msms01.vwp? Even my lazier eye have found a lot of known data (and FFT function in separate segment)
[15:07:32] <BBB> kshishkov: ?
[15:07:36] <superdump> weird that ffpf vs refnopf has the highest db
[15:08:00] <BBB> db?
[15:08:04] <superdump> psnr
[15:08:14] <BBB> stddev
[15:08:27] <superdump> lol
[15:08:29] <kshishkov> BBB: that's actual decoder for VoxWare MetaS..., one of the important codecs we don't have yet :(
[15:08:30] <superdump> ok
[15:08:33] <superdump> i'm going to be quiet now
[15:08:35] <superdump> apologies
[15:08:41] <BBB> no, I was confused ;)
[15:08:52] <superdump> that turns everything on its head ;)
[15:08:58] <BBB> so yes, highest difference is between us without pf versus ref with pf, or us with pf versus ref without pf
[15:09:07] <BBB> which you'd expect if my patch is anywhere near correct
[15:09:19] <BBB> and lowest difference is for the other tywo
[15:11:03] <superdump> BBB: right, though "a
[15:11:04] <superdump> quick look at the code (postfilt() in code/postfilt.c) confirms that
[15:11:11] <superdump> we're doing mostly the same thing" doesn't instill a lot of confidence :)
[15:11:15] <superdump> 'mostly'?
[15:11:20] <superdump> is that just the clipping difference?
[15:11:27] <BBB> don't think so
[15:11:41] <BBB> don't forget that current code versus reference without postfilter is highly different already
[15:13:26] <superdump> i'm not sure how good 46dB is in psnr terms for audio
[15:14:05] <BBB> for voice, it's quite good, according to kostya
[15:14:10] <BBB> but this isn't source versus decoder output
[15:14:12] <BBB> unfortunately
[15:14:16] <BBB> so it's hard to say what it means
[15:14:39] <BBB> all I can say is that difference of ref vs. us without postfilter ==~ difference of ref vs. us with postfilter
[15:14:44] <BBB> which is all I tried to proove
[15:14:44] <BBB> :)
[15:14:52] <kshishkov> BBB: don't trust claims about sound quality from original ffaacenc author ;)
[15:15:01] <BBB> lol
[15:25:40] <superdump> BBB: does it sound any better with the postfilter versus without?
[15:28:26] <superdump> well, i'm off anyway
[15:28:29] <superdump> have fun
[15:33:19] <BBB> hm, he left
[15:33:34] <BBB> well that's hard to say, input sounds quite good already without postfilter so I can't hear any clear differences, unfortunately
[15:33:40] <BBB> I'd need imperfect source for that
[15:34:53] <kshishkov> no, you need perfect source
[15:35:50] <kshishkov> like complex music with high notes so you can actually spot the difference instead of guessing which pile of crap is better - smoothed or not
[15:51:49] <CIA-1> ffmpeg: benoit * r22729 /trunk/ (15 files in 3 dirs): Replace @returns by @return.
[16:28:50] <CIA-1> ffmpeg: astrange * r22730 /trunk/configure:
[16:28:50] <CIA-1> ffmpeg: configure: restore -mdynamic-no-pic on darwin (missing since r20497)
[16:28:50] <CIA-1> ffmpeg: Darwin compilers default to PIC on, so -mdynamic-no-pic (which disables it
[16:28:50] <CIA-1> ffmpeg: again) needs to be added to cflags before enable pic is checked.
[16:28:50] <CIA-1> ffmpeg: Fixes compilation without --enable-shared at least the 10.6 system compiler
[16:28:51] <CIA-1> ffmpeg: for x86-32.
[16:28:52] <CIA-1> ffmpeg: Fixes speed regression on all darwin arches except x86-64.
[16:32:33] <astrange> "Fixes compilation without --enable-shared" <- not sure about this wording
[16:32:58] <astrange> it's fixed without --enable-shared, but probably still broken with --enable-shared, because that's still pic. didn't try it yet
[16:43:06] <Vitor1001> BBB: BTW, I forgot to tell: besides what I said in my last email to the list, patch ok.
[16:52:32] <BBB> Vitor1001: thanks, I'll add a comment, I wasn't quite sure how to share it since all actual factors are differeny
[16:52:44] <BBB> I figured this is why the actual individual filters are separate functions
[16:55:13] <Vitor1001> BBB: Probably it would be nice also to have a way to disable it in the command line...
[16:56:19] <BBB> that's a more generic thing that would be nice for all decoders
[16:56:30] <BBB> I've wanted to implement something like that for a while now
[16:57:18] <BBB> anyway, I got a lot of patches in my tree so it's time I merge some of 'em first
[16:57:26] <BBB> related
[16:57:30] <BBB> Vitor1001: how good are you with matlab?
[16:57:39] <Vitor1001> never used
[16:57:44] <BBB> oh
[16:57:45] <BBB> hm...
[16:57:50] <BBB> anyone here using matlab?
[16:57:51] <Vitor1001> I can do some tricks with mathematica...
[16:57:53] <jai> Vitor1001: btw, if someone is taking up libavfilter audio support, a volume filter would be nice :)
[16:57:57] * mru used to be half-decent with matlab
[16:58:09] <mru> haven't used it since ~2003 though
[16:58:24] <jai> BBB: poor students prefer octave ;)
[16:58:36] <mru> we had free matlab licences at uni
[16:58:41] <Vitor1001> jai: I won't have any time to work on lavfi this year :(
[16:58:45] <mru> for home use as well
[16:58:47] <BBB> a friend of mine is looking for a matlab expert for consulting
[16:58:54] <BBB> mru: shall I forward it to you?
[16:59:36] <jai> Vitor1001: oh :|
[17:00:30] <mru> BBB: no
[17:00:53] <mru> I haven't used matlab for 7 years, I wouldn't even know where to begin
[17:01:12] <mru> well, I assume the basic ideas remain the same
[17:01:29] <jai> yeah, its still a memory hog
[17:01:35] <mru> heh
[17:01:40] <BBB> ok, will find someone else then
[17:01:44] <BBB> peloverde: what abouy you ? ;)
[17:01:50] <mru> matlab5 was much less of a hog than v6
[17:01:55] <mru> what version are they at now?
[17:02:23] <jai> mru: 7.xx
[17:02:42] <jai> .10 actually
[17:02:56] <mru> I remember v6 came with a fuckload of java crap
[17:03:18] <peloverde> 6 and 7 both do
[17:03:55] <mru> which version did they add the jit compiler?
[17:04:04] * j0sh wrote a matlab wrapper for ffmpeg
[17:04:16] <j0sh> 'twas not pretty
[17:04:19] <jai> whoa
[17:04:21] <peloverde> BBB, Thanks for the offer but I don't really know most of the fancy toolboxes, etc
[17:04:35] * mru glued matlab and spice together with ugly scripts
[17:04:56] <mru> matlab had much better graphing capabilities than spice
[17:09:56] <kshishkov> we used to implement sorting algorithms in matlab
[17:10:10] <mru> that's silly
[17:10:17] <mru> matlab has builtin sorting functions
[17:10:19] <peloverde> matlab has some very nice filter design / analysis tools
[17:10:24] <kshishkov> not as silly as AI labs in Excel
[17:11:01] <kshishkov> army rule "to gain experience you need to roll flat objects and push round objects"
[17:11:20] * mru was never in the army
[17:13:12] <kshishkov> same here but you pick some things up, especially army way of thinking
[17:13:53] <kshishkov> IIRC on neighbouring department there were only two people from the whole staff who weren't officers
[17:14:15] <kshishkov> and that was "intellectual decision-making systems" speciality
[17:20:47] <kierank> everything has to be done quickly in spite of the fact that a little bit of time could be taken and it could be done right
[17:21:57] <kshishkov> especially the latter
[17:22:03] <kshishkov> right != properly
[17:22:19] <kierank> that too
[17:23:13] <mru> military decision-making is very special
[17:23:42] <mru> the troops on the ground, or in the planes, simply don't have enough information to make an informed decision on their own
[17:23:47] <kshishkov> actually it was civilian speciality there but yet...
[17:24:02] <mru> so decisions _must_ be made by someone higher up in command
[17:24:10] <mru> who has access to the bigger picture
[17:24:39] <mru> and once he makes a decision, those under him must follow orders, or there will be disaster
[17:25:06] <kshishkov> in theory yes but you don't know how creatively they tend to follow orders
[17:25:45] <mru> and of course the competence of the generals and whatnot might not be what it ought
[17:25:59] * kshishkov remembers what during local trainings they managed to launch rocket into house near Kiev and Russian plane
[17:26:50] <mru> unfortunately, in a combat situation there is no time for questioning orders
[17:27:12] <mru> even if they were to be found bad
[17:27:44] <mru> doing something is often better than doing nothing
[17:27:51] <mru> even when doing something else might have been even better
[17:28:16] <mru> but if you're dead by the time you've figured it out, that matters little
[17:28:51] <_av500_> u can come back as aghost saying - i told you so
[17:29:08] <kshishkov> okay, you get your promotion at the headquarters
[17:35:03] <BBB> mru: do you want to write interleaving DSP functions?
[17:36:53] <mru> I'd prefer if the existing ones could be used
[17:37:25] <mru> I spent a crazy amount of time on the neon one
[17:37:45] <mru> and it can't be done as efficiently if the range is altered
[17:38:23] <BBB> oh, we already have?
[17:38:25] * BBB looks
[17:38:31] <BBB> what should I grpe for?
[17:38:40] <mru> float_to_int16_interleave
[17:38:59] <BBB> float_to_float_interleave?
[17:39:28] <mru> easy to write but won't be as efficient
[17:39:38] <BBB> that's ok
[17:39:43] <mru> no, that's not ok
[17:39:47] <BBB> uhm...
[17:40:36] <mru> if a float decoder can be coerced into outputting -32k..32k that should be done
[17:40:38] <BBB> look, most audio decoders that we write now, output float
[17:40:47] <mru> AND THAT IS A HUGE MISTAKE
[17:40:52] <mru> not outputting floats per se
[17:41:00] <mru> but not allowing the range to be chosen
[17:41:07] <BBB> then do something about it
[17:41:20] <mru> oh fuck off with that attitude
[17:41:44] <BBB> what do you expect me to do about it if I don't even know this stuff?
[17:41:47] <mru> that I know _how_ something should be done, doesn't imply I have _time_ to do it
[17:41:47] <BBB> you never told me
[17:41:59] <BBB> I ask "what should my decoder output", people tell me "float"
[17:42:02] <BBB> I write a float decoder
[17:42:03] <mru> I've mentioned it in every discussion on the topic
[17:42:05] <BBB> (and we all did)
[17:42:12] <BBB> and now suddenly you want float with choosable ranges?
[17:42:25] <mru> I've been saying that since long before you joined ffmpeg
[17:42:44] <mru> and I'm getting weary of it
[17:43:05] <iive> write it in your blog and then just paste the url.
[17:43:08] <mru> the way many codecs are designed, you can apply a scaling FOR FREE
[17:43:25] <mru> simply by prescaling mdct coeffs or similar
[17:43:48] <mru> that saves you a multiplication later
[17:44:01] <mru> which should speed up the conversion to int16 by 20% or so
[17:44:08] <BBB> that is great
[17:44:14] <mru> depending on the complexity of the codec of course
[17:44:14] <BBB> but so output would still be (scaled) float
[17:44:19] <mru> yes
[17:44:21] <BBB> so could we use a float_to_float_interleave?
[17:44:25] <mru> no
[17:44:38] <mru> well, we'll need that too for completeness
[17:45:00] <mru> to do the right thing you need to look all the way to the end of the pipeline
[17:45:44] <mru> if you want to end up with interleaved int16, the most efficient way is to scale inside the codec and combine int conversion with interleaving
[17:45:47] <_av500_> russia?
[17:46:02] * mru looks a thresh
[17:46:07] <mru> *at
[17:46:40] <_av500_> russians are good at interleaving gas with no gas
[17:46:53] * kshishkov waves
[17:46:59] <iive> lol
[17:47:27] <thresh> you're not russian, dont try to kid us
[17:47:54] <iive> i'm next on the pipe after kostya.
[17:47:58] <mru> now if you want interleaved float samples, then a simple float interleave function will be needed
[17:48:09] <mru> and that will surely be needed at some point too
[17:48:11] <BBB> mru: ok, so you're saying (correct me if I'm wrong), decoders should allow selecting flt vs. int16, and then the caller should be intelligent enough to know which to choose, and then decoders should use dsp.float_interleave vs. dsp.float_to_int16_interleave() based on that?
[17:48:23] <BBB> is that "most optimal"?
[17:48:40] <kshishkov> we have downmixing
[17:48:50] <mru> that would be one way, but it would duplicate some code
[17:48:54] <kshishkov> why not adaptive sample output?
[17:48:58] <mru> better to choose the range instead
[17:49:05] <mru> and provide planar output
[17:49:16] <_av500_> why planar?
[17:49:17] <mru> and convert/interleave outside the decoder
[17:49:25] <_av500_> ok
[17:49:39] <kshishkov> easier to output too
[17:49:44] <mru> my neon convert/interleave is as fast as doing either of them alone
[17:49:47] <iive> btw, i thought that we already have implemented working scale of floats.
[17:49:48] <_av500_> makes things like resampling easier
[17:49:57] <BBB> iive: it's a hack, so no
[17:50:02] <BBB> (imo)
[17:50:07] <mru> it's a big, fat hack
[17:50:24] <mru> downmixing can often be done more efficiently before the imdct
[17:50:26] <mru> like in ac3
[17:50:53] <mru> we'll of course need post-decode downmixing functions too
[17:50:58] <peloverde> Doesn't that only work if the windowing across the channels is the same?
[17:50:59] <mru> for the codecs that can't downmix internally
[17:51:09] <_av500_> aac e.g.
[17:51:11] <mru> it works only if the codec was designed for it
[17:51:15] <kshishkov> ac3 has two transforms
[17:51:16] <mru> ac3 was designed for it
[17:51:23] <mru> and dts too iirc
[17:52:02] <jai> mlp too
[17:52:17] <kshishkov> pcm too
[17:52:32] <mru> so just like we have request_channels we need a request_format
[17:53:41] * BBB will go with Michael's suggestion of just adding a FIXME for now
[17:53:56] <mru> fixme for what?
[17:54:05] <BBB> optimized interleaving
[17:54:06] <mru> you know as well as I that fixmes never happen
[17:54:16] <kshishkov> indeed, a little fixme saves the real trouble of fixing ;)
[17:54:19] <BBB> I want my clipping patch applies
[17:54:25] <BBB> applied*
[17:54:35] <mru> I don't mind that
[17:54:44] <mru> it's just a fix for an obvious bug
[17:54:50] <BBB> I fixed all issues in the speech decoders related to overactive memcpy()ing
[17:54:53] <mru> quite separate from a proper redesign
[17:55:01] <BBB> the one remaining performance thing that can be improved is interleaving in wmaprodec/atrac1
[17:56:13] <BBB> btw what does aacdec and ac3dec output?
[17:56:22] <BBB> do they really output int16? and what do they use internally?
[17:56:31] <_av500_> aac is int16
[17:56:41] <_av500_> ac3 as well
[17:56:52] <peloverde> aac uses float internally
[17:57:11] <kshishkov> ac3 too
[17:57:36] * BBB wonders whether mru would take away his svn write access if he converted ac3/aac to output float
[17:57:37] <kshishkov> even many speech codecs use floats
[17:58:55] <mru> I might
[17:59:05] <mru> it would make them 3x slower
[17:59:23] <mru> or maybe only 2x
[17:59:35] <jai> wmapro outputs float right?
[17:59:37] <mru> yes
[17:59:44] <mru> and it spends >50% time in post-conversion
[17:59:49] <jai> :S
[18:00:11] <mru> and I can easily speed up the decoder core by 30-50%
[18:00:33] <mru> hence the 3x figure
[18:00:52] <mru> I've exhausted my tricks on aac
[18:01:00] <mru> need to tackle sbr
[18:01:11] <kshishkov> or Bink audio
[18:01:13] <mru> should be easy to double the speed of that on arm
[18:01:21] <mru> sbr, that is
[18:01:25] <mru> haven't looked at bink
[18:01:33] <mru> nor do I have a lot of motivation to do so
[18:02:24] <mru> what transforms does it use?
[18:02:47] <kshishkov> some DCT or RDFT
[18:02:51] <Dark_Shikari> What the fuckety fuck, some guy has a fork of x264 on github... where's he's converting it to use autotools
[18:02:55] <Dark_Shikari> WHYYYYYYYYYYYYYYYYYYYYYYY
[18:02:57] <Dark_Shikari> WHY
[18:03:01] <BBB> lol :)
[18:03:11] * mru loads shotgun
[18:03:13] <BBB> because we can!
[18:03:20] <kshishkov> where is fork for  MSVC?
[18:03:30] <jai> lol BBB
[18:03:52] <BBB> hmm... I always get confused in this chat client and end up closing the wrong channel
[18:03:52] <jai> BBB: heh
[18:03:57] <mru> Dark_Shikari: whose fork is that?
[18:04:07] <Dark_Shikari> "nevali"
[18:04:11] <Dark_Shikari> I have no idea, but seriously the fuck
[18:04:19] <mru> oh, fuck indeed
[18:04:30] <kshishkov> mru: you still have ffavs to ... TAKE CARE OF
[18:04:41] <mru> is it still around?
[18:04:53] <kshishkov> dunno
[18:04:57] <BBB> "    Mo McRoberts"
[18:05:26] <Dark_Shikari> http://github.com/nexgenta/x264
[18:05:42] <mru> well, let's make it hard for them, shall we?
[18:06:29] <kshishkov> still, where's x264 with intrinsics and MSVS support?
[18:06:39] <kshishkov> that would be more fun
[18:06:51] <mru> Dark_Shikari: you should borrow more from ffmpeg's configure
[18:07:08] <mru> yours is broken in some ways now
[18:07:10] <Dark_Shikari> kshishkov: we intentionally dropped the latter
[18:07:12] <mru> or at least not as capable
[18:07:13] <Dark_Shikari> mru: patches welcome
[18:09:51] <Dark_Shikari> (seriously)
[18:35:50] <ramiro> mru: ping "[PATCH] Use cross-prefix for strip in darwin."
[18:36:35] <mru> ramiro: I saw, I had doubts, I forgot about it
[18:36:45] <mru> will look at it after dinner
[18:36:50] <ramiro> thanks
[18:36:51] * mru is hungry
[19:15:13] <jai> mru: pk__ is the guy you kb'd (or/kick'd i dont recall fully) once
[19:15:16] <jai> :)
[19:16:04] <mru> I've kicked more than one person
[19:16:26] <jai> oh, i thought you'd remember him
[19:16:44] <jai> he was going on about a symbian port of ffmpeg or something in that vein
[19:17:44] <mru> my logs don't have that nick
[19:17:54] <jai> mru: try "pankaj"
[19:17:57] <jai> or sth like that
[19:18:36] <mru> yep, I kicked him several times
[19:18:39] <mru> and pk2010
[19:18:43] <jai> heh
[19:18:53] <mru> that was last june
[19:19:02] <jai> he has begun a new life as a vlc dev since then
[19:27:02] <astrange> http://twitter.com/rickt/status/11063159819 wonder what that means
[19:27:50] <mru> isn't that bg from 2001?
[19:27:53] <Dark_Shikari> it means someone is somewhat retarded
[19:38:03] <CIA-1> ffmpeg: rbultje * r22731 /trunk/ffmpeg.c:
[19:38:03] <CIA-1> ffmpeg: Split out code that auto-chooses a default pix_fmt/sample_fmt in their own
[19:38:03] <CIA-1> ffmpeg: functions.
[20:42:22] <BMintern1> hello again Vitor1001... i'm really stuck this time
[20:47:39] <CIA-1> ffmpeg: michael * r22732 /trunk/libavcodec/error_resilience.c:
[20:47:39] <CIA-1> ffmpeg: Make sure the EC code does not attempt to use inter based concealment if there
[20:47:39] <CIA-1> ffmpeg: is no reference frame available. (this can happen because the EC code will attempt
[20:47:39] <CIA-1> ffmpeg: to use reference frames even for I/IDR frames)
[21:06:02] <CIA-1> ffmpeg: michael * r22733 /trunk/libavcodec/ (h264_refs.c h264.c h264.h): Fix implicit weight for b frames in mbaff.
[21:45:15] <hyc> interesting. Hulu's streams used to list ffmpeg in their metadata
[21:45:21] <hyc> now they show "Hulu 1.0"
[21:45:41] <hyc> I wonder if they've actually written their own transcoders (doubtful)
[21:45:50] <hyc> or if they're just slapping their own name on top of ffmpeg
[21:46:15] <kierank> ask baptiste
[21:46:31] <kierank> he works there iirc
[21:47:13] <Dark_Shikari> hyc: they use x264
[21:48:00] <hyc> Dark_Shikari: ah right. I remember seeing x264 in their metadata before
[21:48:05] <hyc> but not any more
[21:48:24] <hyc> now their tag is Hulu v1.0
[21:49:29] <peloverde> I also noticed last night that some streams use aac main profile
[21:50:53] <hyc> yeah I've seen a few of those, didn't strike me as odd at the time
[21:51:05] <kierank> maybe they did the impossible and mangaged to get a nero licence
[21:51:12] <kierank> managed*
[21:52:35] <Dark_Shikari> kierank: I bitched at nero about that
[21:52:39] <Dark_Shikari> and they are now more open to licensing
[21:52:56] <peloverde> Nero's freeware encoder doesn't do main
[21:54:49] <peloverde> An encoder that supports main is most likely based on an old codebase
[21:57:08] <BBB> faac?
[21:57:23] <BBB> if you're using ffmpeg to convert, you're more than likely using faac for aac encoding
[21:57:40] <BBB> changing metadata isn't so difficult
[21:57:52] <Dark_Shikari> it's trivial to see if it's flac
[21:57:56] <Dark_Shikari> does it sound like shit at 128kbps?
[21:57:58] <Dark_Shikari> then it's faac
[21:59:40] <BBB> how do I count characters in a line using bash tools?
[21:59:48] <BBB> wc -c counts total characters
[21:59:59] <hyc> BBB: man expr
[22:00:22] <BBB> cat file | grep CONV | man expr returned an error
[22:00:47] <hyc> ....
[22:00:51] <hyc> read the expr manpage
[22:01:00] <peloverde> faac at 128 doesn't sound all that bad to me
[22:02:18] <drv> i haven't done any scientific tests, but faac at 128kbps on music sounds ok to me too usually
[22:02:30] <BBB> man expr is like 20 lines on macosx
[22:02:34] <BBB> probably different on unix
[22:03:17] <peloverde> Contact your UNIX vendor and ask for better man pages ;)
[22:03:33] <hyc> Apple has always been one to lobotomize technology...
[22:03:35] <drv> maybe they'll send you a nice stack of dead trees
[22:03:41] <peloverde> (or google it)
[22:03:54] <hyc> expr length "STRING"
[22:04:37] <BBB> expr: syntax error :)
[22:04:52] <BBB> I think apple intoxicated it
[22:05:32] <hyc> sad. you could probably use awk for the job, but that's overkill
[22:05:43] <drv> the gnu coreutils expr has a lot more operators than the BSD one that apple uses
[22:06:40] <mru> http://www.opengroup.org/onlinepubs/009695399/utilities/expr.html
[22:07:12] <mru> I don't see how that would give you the length of a line
[22:07:36] <hyc> you can use also use expr string : .
[22:07:49] <drv> well, probably GNU stuff having the kitchen sink included in every tool
[22:08:02] <hyc> it matches a stirng to a regexp and returns the number of matching characters
[22:08:14] <hyc> so using "." will give you length of the string
[22:08:25] <mru> hyc: that will return 1
[22:08:32] <mru> or 0 for empty lines
[22:09:15] <hyc> mru: ah right. use .*
[22:09:15] <drv> .* or something?
[22:09:25] <drv> with proper quoting
[22:10:06] <CIA-1> ffmpeg: cehoyos * r22734 /trunk/ (9 files in 2 dirs):
[22:10:06] <CIA-1> ffmpeg: Add spectral extension to the E-AC-3 decoder.
[22:10:06] <CIA-1> ffmpeg: Original patch by Justin, updated and resubmitted by
[22:10:06] <CIA-1> ffmpeg: Christophe Gisquet, christophe D gisquet A gmail
[22:10:12] <mru> that would work
[22:10:19] <j-b> \o/
[22:10:20] <j-b> Finaly
[22:12:18] <kierank> j-b: that's for french dvb-t right?
[22:12:43] <j-b> yes
[22:12:55] <j-b> kierank: I patch vlc since almost 8 month for that on Win32 and Mac
[22:13:07] <j-b> well, I patch avcodec in vlc
[22:13:21] <j-b> and I have to say that I hate maintaining non-official patches
[22:13:48] <j-b> because I don't trust /me
[22:14:19] <BBB> gr... expr kills starting spaces
[22:14:39] <mru> you're not quoting properly
[22:14:59] * BBB adds a s/ /x/g hack
[22:16:11] <BBB> hm, I guess I wasn't too far off in my email
[22:16:14] * BBB leaves as-is
[22:27:42] * hyc grumbles again about stupud GNU extensions to standard shell tools...
[22:30:14] <mru> well, sometimes they are useful
[22:30:27] <mru> but all too often they conflict with standards
[22:30:41] <mru> and even when they don't, they're not clearly marked as extensions in the manuals
[22:31:59] <hyc> yeah, that's the worst part
[22:32:23] <hyc> but so many are just gratuitous - a new "user-friendly" way to do what the command already does
[23:32:12] <CIA-1> ffmpeg: stefano * r22735 /trunk/ (383 files in 5 dirs):
[23:32:12] <CIA-1> ffmpeg: Define AVMediaType enum, and use it instead of enum CodecType, which
[23:32:12] <CIA-1> ffmpeg: is deprecated and will be dropped at the next major bump.
[23:32:12] <CIA-1> ffmpeg: stefano * r22736 /trunk/ (libavcodec/avcodec.h libavutil/avutil.h):
[23:32:12] <CIA-1> ffmpeg: Move AVMediaType from libavcodec to libavutil.
[23:32:13] <CIA-1> ffmpeg: This allows applications/libraries which require that symbol
[23:32:14] <CIA-1> ffmpeg: (e.g. libavfilter) to be compiled without to depend on the presence of
[23:32:14] <CIA-1> ffmpeg: libavcodec/avcodec.h, which may not be installed.
[23:43:01] <CIA-1> ffmpeg: stefano * r22737 /trunk/doc/APIchanges:
[23:43:02] <CIA-1> ffmpeg: Update APIchanges after the enum CodecType -> enum AVMediaType
[23:43:02] <CIA-1> ffmpeg: transition.
[23:47:21] <CIA-1> ffmpeg: stefano * r22738 /trunk/cmdutils.c:
[23:47:21] <CIA-1> ffmpeg: Issue a more general message when the function which sets an option
[23:47:21] <CIA-1> ffmpeg: fails.
[23:47:21] <CIA-1> ffmpeg: It may fail not only because of an invalid value for the option, but
[23:47:21] <CIA-1> ffmpeg: also for other reasons, e.g. memory problems etc.