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

[irc at mansr.com]

[00:06:40] <bcoudurier> Yuvi, is it easy to extract vorbis frame duration in the demuxer ?
[00:17:24] <mru> it's impossible
[00:17:33] <mru> without half a vorbis decoder
[00:25:29] <Yuvi> bcoudurier: easy, no
[00:25:34] <Yuvi> possible, yes
[00:25:35] <Yuvi> http://github.com/kfish/liboggz/blob/master/src/liboggz/oggz_auto.c#L648
[00:31:23] * Compn still chuckles at mike being ffmpeg and theora and flash dev
[00:32:20] <mru> some irony
[00:32:20] <Compn> small multimedia world
[00:33:20] <mru> that too
[01:43:48] <Dark_Shikari> mru: how fast is clz on armv6?
[01:44:25] <mru> one cycle
[01:44:39] <Dark_Shikari> 09:43 < derf> The funny bit, is the de Bruijn approach is _faster_ than clz on ARMv6.
[01:44:39] <mru> well, on arm11
[01:44:47] <mru> oh, that idiot again
[01:45:09] <mru> ask him which armv6
[01:45:38] <mru> https://trac.xiph.org/browser/branches/theora-thusnelda/lib/enc/mathops.c?rev=16300#L4
[01:45:42] <mru> that claims arm11 even
[01:45:51] <mru> and it's one cycle there
[01:46:05] <mru> I don't know of any other armv6 implementations
[01:46:49] <Dark_Shikari> gmaxwell proposes it might have been gcc sucking with __builtin_clz
[01:46:58] <Dark_Shikari> 09:46 < gmaxwell> The code generated by GCC for CLZ on ia64 looks stupid, and ICC (at least the last version I tried) was actually producing incorrect code.
[01:47:14] <mru> didn't I do a blog post on that?
[01:47:19] <Dark_Shikari> yup.  linked it
[01:47:38] <mru> iirc gcc did the right thing on arm
[01:47:50] <Dark_Shikari> They might have checked a while ago though.
[01:47:57] <Dark_Shikari> I would be entirely unsurprised if it didn't used to do the right thing.
[01:48:22] <ohsix> it (builtin) collapses into an invocation of clz if the arch is set, isn't it?
[01:48:25] <mru> some version was obviously the first to implement it
[01:48:34] <Dark_Shikari> ohsix: and if the phase of the moon is right
[01:48:47] <mru> ohsix: only if the operation is defined for that architecture/cpu
[01:49:01] <ohsix> well i mean, the builtin isn't actually emitted, it depends on the thing
[01:49:04] <mru> if not, it emits a call to __clzsi3
[01:49:19] <mru> or whatever that function is called
[01:49:32] <mru> __clzsi2 it is
[01:49:41] <mru> never understood that naming convention
[01:49:50] <mru> si is "single int"
[01:49:53] <Dark_Shikari> scalar int?
[01:49:54] <mru> no idea about the 2
[01:50:08] <mru> qi = quarter int (aka byte)
[01:50:11] <mru> hi = half int
[01:50:21] <mru> di = double int (64-bit)
[01:50:59] <ohsix> i think the numbers are just for versions; they keep old versions in libgcc or whatever and supersede them when the abi changes
[01:51:14] <ohsix> divsi is up to 3 already
[01:51:20] <mru> almost everything is 3
[01:51:52] <mru> internally gcc has things like addsi3, subsi3 etc
[01:52:58] <mru> I think the figure denotes the number of operands to the pseudo-instruction
[01:53:06] <mru> seems to match
[01:53:33] <ohsix> hm yea it does, i had only been looking at *3 stuff so i didn't notice
[01:54:17] <ohsix> those files are hard to get around :<
[01:54:57] <ohsix> arm esp has some arch files that live in there with their own trampolines and multiple versions/symbols
[01:55:14] <mru> the arm files are very complicated
[01:55:32] <mru> in part that's due to things like most instructions being conditional
[01:55:46] <ohsix> i get them conceptually, but i wouldn't want to internalize it all to make modifications, otherwise you'd fuck it all up
[01:55:57] <mru> gcc rtl doesn't seem to have a good way of expressing that
[01:56:23] <mru> those files are _very_ fragile
[01:56:48] <mru> the slightest change can have bizarre consequences you'd never expect
[02:03:09] <mru> Dark_Shikari: any more jokes from the clown?
[02:10:35] <mru> Dark_Shikari: gcc 3.2.3 had clz on arm
[02:11:48] <mru> that was released in april 2003
[02:18:15] <bcoudurier> bye guys
[02:21:00] <Compn> It could be replaced with AVERROR_PATCHWELCOME, though.
[02:21:04] <Compn> hehe
[02:21:30] <mru> ?
[02:22:22] <mfg> Are the recent changes to run a test against fate documented?  Can I use that to do a full regression on another change I want to make?
[02:22:44] <mru> yes
[02:22:53] <mru> you need to download the fate samples first
[02:23:05] <mru> http://fate.multimedia.cx/running.html
[02:23:26] <mru> then configure --samples=/path/to/samples
[02:23:49] <mfg> nice -- ty
[02:30:20] <Dark_Shikari> mru: he says ARM1136EJ-S
[02:30:29] <Dark_Shikari> and he says it was in fact using the clz instruction
[02:32:42] <mru> he's either totally incompetent or a liar
[02:32:47] <mru> or possibly both
[02:33:11] <Dark_Shikari> do you have one of those?
[02:33:18] <mru> yes
[02:33:27] <Dark_Shikari> and you've tested, I assume?
[02:33:48] <mru> I can't access a cycle counter directly
[02:33:59] <mru> and I don't remember if I ever tested that instruction
[02:34:04] <mru> the ARM manuals are accurate
[02:37:16] <mru> I measured it now on A8
[02:37:17] <mru> one cycle
[02:38:25] <mru> one cycle latency
[02:38:51] <mru> the A8 can issue two of them per cycle too
[02:48:11] <mru> Dark_Shikari: did he say how he measured the time?
[02:48:49] <Dark_Shikari> no
[02:48:56] <Dark_Shikari> I don't really care
[02:49:10] * mru likes a good laugh
[03:00:06] <CIA-92> ffmpeg: michael * r22572 /trunk/libavcodec/error_resilience.c: Use H264s MC instead of mpeg4-asp qpel for h264 error resilience.
[03:00:44] <Dark_Shikari> oh, so that's why there was that annoying accumulated error.
[03:44:11] <CIA-92> ffmpeg: koorogi * r22573 /trunk/libavfilter/ (vf_aspect.c Makefile allfilters.c): Add video filter to manipulate aspect ratio
[04:25:34] <CIA-92> ffmpeg: ramiro * r22574 /trunk/libavdevice/vfwcap.c:
[04:25:34] <CIA-92> ffmpeg: Do not store a copy of AVFormatContext *s in vfw_ctx.
[04:25:34] <CIA-92> ffmpeg: Save *s directly in SetWindowLongPtr instead.
[04:36:55] <CIA-92> ffmpeg: ramiro * r22575 /trunk/libavdevice/vfwcap.c: vfwcap: Free remaining packets on vfw_read_close().
[04:38:29] <CIA-92> ffmpeg: koorogi * r22576 /trunk/libavfilter/vf_format.c: Cosmetics: rearrange functions to simplify ifdeffery
[04:38:31] <CIA-92> ffmpeg: koorogi * r22577 /trunk/libavfilter/vf_format.c:
[04:38:31] <CIA-92> ffmpeg: Allow format and noformat filters to be more completely disabled when the
[04:38:31] <CIA-92> ffmpeg: other is enabled.
[04:38:31] <CIA-92> ffmpeg: koorogi * r22578 /trunk/libavfilter/allfilters.c: Cosmetics: vertical align
[06:45:42] <ohsix> http://www.knjn.com/shop.html?pg=img&src=5140
[06:56:53] <pJok> god morgen, kshishkov :)
[06:57:05] <kshishkov> goda morgnar ;)
[06:58:19] <thresh> хмутро
[06:58:56] <pJok> utsikt över malmö central
[06:59:34] <kshishkov> thresh: езжай в Питер ;)
[07:00:11] <kshishkov> saw Malmö C a couple of times
[07:00:48] <pJok> right now it just looks like a big construction site
[07:00:58] <kshishkov> Citytunnel
[07:01:03] <pJok> japp
[07:01:15] <pJok> i look forward to that
[07:01:26] <thresh> kshishkov: yeah, to get even worser weather
[07:01:27] <pJok> cuts 7 minutes off my trainride to copenhagen
[07:01:29] * kshishkov too for some unknown reason
[07:01:45] <kshishkov> thresh: I've heard it's consistently bad though
[07:02:14] <thresh> yeah, thanks a lot for the support ;)
[07:02:18] <kshishkov> pJok: for another unknown reason I like reading http://www.banverket.se
[07:03:37] <pJok> so do i
[07:03:55] <pJok> but thats mostly because i look forward to hallandsås tunnellen
[07:04:24] <pJok> which hopefully gives me trains that run at night as well
[07:06:30] <pJok> though that would just be wishful thinking
[07:07:00] <kshishkov> heh, here the only major project I heard of is ralway bridge across Dnieper in Kiev
[07:07:46] <kshishkov> it could have been built already (and cheaper) if they used European workers and not stole 99.9% of money
[07:08:51] <kshishkov> I'm not sure ordinanry man can learn about any projects here
[07:09:01] <pJok> two-track railway from göteborg to lund, hallandsås tunnel, north/south tunnel for helsingborg c... exciting stuff
[07:09:15] <thresh> kshishkov: the sole purpose of our countries is to steal money
[07:09:28] <kshishkov> thresh: yours has oil
[07:10:42] <thresh> kshishkov: yeah, like *i* own a oil-rig or something :)
[07:11:21] <kshishkov> thresh: there's a word for you in Eglish - Muzhik
[07:12:30] <kshishkov> i.e. ordinary citizen of Russia who has only one right - to vote for Yedinaya Rossiya and its leader
[07:50:25] <CIA-92> ffmpeg: kostya * r22579 /trunk/libavcodec/indeo5.c: document two variables in Indeo5 decoding context
[07:54:04] <CIA-92> ffmpeg: kostya * r22580 /trunk/libavcodec/indeo5.c:
[07:54:04] <CIA-92> ffmpeg: Correct reference buffer switching in Indeo 5 decoder.
[07:54:04] <CIA-92> ffmpeg: Patch by Maxim ($indeo5decauthor)
[08:15:13] <roozhou> hi, anyone knows how to set time_base in stream copy mode?
[08:15:45] <kshishkov> the same way as non streamcopy
[08:16:00] <kshishkov> isn't it copied from source though?
[08:17:01] <roozhou> i tried frame copy H264 from mkv to other container
[08:17:24] <roozhou> and it uses different time_base depending on output container
[08:21:41] <kshishkov> well, maybe astrange/bcoudurier/Yuvi knows
[08:22:00] <roozhou> i am trying to fix stream copy to avi problems
[08:23:07] <roozhou> this is the last thing i need to fix
[08:23:19] <kshishkov> that's unrealistic ;)
[08:24:33] <roozhou> ffmpeg will be the first tool allowing H264 frame copy from mkv/mp4/flv to avi
[08:29:10] <superdump> merbzt, janneg : i stopped rendering 05_throwing-04 because it was on all yesterday evening and it did two frames because it was swapping so much
[08:29:15] <superdump> not feasible
[08:29:33] <superdump> blender really need to code something to avoid excessive ram use
[08:29:33] <KotH> not-enough-ram-fail
[08:29:43] <superdump> indeed
[08:29:49] <superdump> i have 6GB
[08:29:51] <superdump> not enough
[08:30:06] <kshishkov> superdump: drop Python support?
[08:30:08] <KotH> o_0
[08:30:16] <KotH> superdump: wtf?
[08:30:26] * KotH wonders how they rendered BBB back then
[08:30:36] <superdump> with lots of ram i assume
[08:30:41] <superdump> kshishkov: probably not a bad idea
[08:31:10] <superdump> it was using upwards of 8GB
[08:31:25] <twnqx> ugh.
[08:31:29] <kshishkov> KotH: maybe they used smaller resolution
[08:31:35] <twnqx> why are you actually rerendering it?
[08:31:41] <superdump> i started rendering a different scene that was already underway, though i didn't know
[08:31:51] <superdump> that was taking about 5-6 minutes per frame
[08:32:02] <kshishkov> twnqx: to pretend later it can be done with array of BeagleBoards in real time
[08:32:06] <superdump> twnqx: they're doing it for a 2700x1440 video wall
[08:32:18] <twnqx> hm
[08:32:39] <twnqx> do you still need nodes? and what's needed to participate?
[08:32:55] <kshishkov> more RAM of course!
[08:33:03] <twnqx> that's not a prob
[08:33:11] <twnqx> i have two pretty idle boxes with 16G each
[08:33:12] <superdump> http://jannau.net/bbb_videowall/
[08:33:19] <superdump> they would be handy i expect
[08:33:20] <twnqx> and lots of cpu power.
[08:33:26] <superdump> lots ==?
[08:33:34] <twnqx> one has 7 2ghz opteron cores
[08:33:39] <twnqx> the other 16x 2.4
[08:33:39] <superdump> :)
[08:33:45] <superdump> niice
[08:33:50] <superdump> let em rip
[08:34:31] <twnqx> (and don't ask why of all numbers seven...)
[08:34:42] <superdump> if you can't get the torrent for firewall reasons, i can upload a tarball of it
[08:34:53] <twnqx> torrent's not a prob
[08:34:53] <superdump> if you have an ftp
[08:34:55] <superdump> ok
[08:35:15] <twnqx> disk space is, those are my fileservers & they are in the middle of raid migration :P
[08:35:27] <superdump> oh
[08:35:44] <twnqx> well
[08:35:49] <twnqx> abot 1T free atm
[08:35:56] <twnqx> (unassigned LVM space)
[08:37:00] <kshishkov> my fileserver has 160GB
[08:39:13] <kshishkov> and currently only one box with HDD
[08:44:00] <twnqx> superdump: link me the torrent and the setup instructions, please :P
[08:45:15] * KotH plugs some wires into twnqx's nose
[08:45:19] <KotH> ;-)
[08:45:26] <twnqx> ouch :S
[08:49:21] <superdump> twnqx: i already did
[08:49:26] <superdump> http://jannau.net/bbb_videowall/
[08:49:40] <twnqx> oh.
[08:51:38] <twnqx> blender 2.49a will do?
[08:52:06] <twnqx> !!! One of the following packages is required to complete your request:
[08:52:06] <twnqx> - media-video/ffmpeg-9999-r1 (Change USE: +theora)
[08:52:08] <twnqx> noooooooooooooooooo
[08:52:13] <twnqx> :S
[08:52:46] <KotH> lol
[08:53:07] <kshishkov> like an old joke "it needs Theora 1.0 encoder or better that's why I chose x264"
[09:13:06] <av500> twnqx: thx for the cpu power!
[09:13:52] <twnqx> i'm not ripping videos ATM :P
[09:14:20] * av500 can haz login? :)
[09:15:07] <twnqx> errr
[09:16:19] <av500> for the rips... :)
[09:16:22] <av500> (joking)
[09:16:30] <twnqx> you like anime? they are all over :P
[09:17:21] <twnqx> HM
[09:17:30] <twnqx> i need a 50GB rewritable bluray disk :S
[09:17:33] <kshishkov> twnqx: you'd better ask that in #mplayerdev
[09:18:14] <twnqx> anime ripping & watching are driving x264 and mplayer development, that's a known fact
[09:18:43] <kshishkov> no
[09:18:52] <kshishkov> for x264 it's Touhou Project
[09:18:56] <twnqx> that too.
[09:19:26] <Dark_Shikari> well, we optimize for those eroge intros too
[09:19:33] <Dark_Shikari> thanks to the japanese providing us with stupidly large amounts of them
[09:19:39] <Dark_Shikari> and the entire japanese x264 community testing on NOTHING ELSE
[09:19:42] <Dark_Shikari> for some fucked up reason
[09:19:52] <kshishkov> literally :)
[09:19:57] <Dark_Shikari> ha ha ha
[09:20:21] <kshishkov> you should've provided presets for target audiences
[09:20:35] <kshishkov> some people may encode _movies_ with x264 after all
[09:20:46] <astrange> japanese bug reports for perian tend to be ads for bottled tea
[09:20:59] <kshishkov> or something else filmed and not rendered/drawn
[09:21:09] <Dark_Shikari> astrange: what
[09:21:31] <Dark_Shikari> kshishkov: rendered content is so much fun though
[09:21:37] <Dark_Shikari> it completely violates all your assumptions about the nyquist limit
[09:21:47] <kshishkov> Dark_Shikari: go tell janneg or av500 that
[09:21:57] <Dark_Shikari> well BBB is easy, it has motion blur
[09:22:14] <Dark_Shikari> (and ultra low detail/motion, but whatever)
[09:22:18] * kshishkov has not thought until recently that "Nyquist" is a typical Swedish name
[09:22:29] <Dark_Shikari> nyquist was swedish?
[09:23:00] <andoma> yes
[09:23:40] <andoma> apparently he's from the same province of sweden as I am!
[09:23:49] <kshishkov> indeed
[09:23:49] <andoma> Värmland
[09:23:49] <Dark_Shikari> and it's pronounced nyqvist
[09:23:50] <Dark_Shikari> not nyquist
[09:24:00] <Dark_Shikari> Which sounds MUCH more swedish.
[09:24:10] <kshishkov> actually Swedish use "kv" now
[09:24:14] <Dark_Shikari> I know
[09:24:23] <Dark_Shikari> the point being, the v sounds more swedish
[09:24:35] <superdump> wouldn't be pronounced 'n-eye' though
[09:24:51] * kshishkov wonders why Hollywood emnployed actors of Swedish origin to fake Russian accent
[09:26:00] <kshishkov> superdump: you should have learned how to read Swedish by now
[09:26:08] <superdump> i have
[09:26:27] <superdump> learning the sounds was one of the first things i did
[09:27:00] <superdump> so i was surprised when i met a guy from hong kong recently when he said they learn english for... 10 years or something, but they only learn grammar, never pronunciation
[09:27:07] * kshishkov still has troubles pronouncing "sje" properly
[09:27:22] <superdump> i don't know what the fuss is about that
[09:27:37] <superdump> but maybe i'm not doing it quite right
[09:27:47] <kshishkov> superdump: they need it only to read/write, not for tech support
[09:27:51] <superdump> i'm normally pretty good at copying sounds people make just from hearing them though
[09:28:31] <superdump> he said he'd probably only spoken english for a couple of hours total in his entire life
[09:28:35] <kshishkov> superdump: have you tried http://www.slayradio.org/mastering_swedish_lesson_3.php ?
[09:28:39] <superdump> and i still had a full conversation with him
[09:28:46] <superdump> i still haven't listened to that
[09:29:18] <kshishkov> Skäms!
[09:29:26] <merbzt> it's awesome
[09:29:57] <kshishkov> indeed
[09:31:11] <kshishkov> not that I can use it in everyday conversation though
[09:31:36] <superdump> listening
[09:31:41] <superdump> 'are sheep allowed on the plane'
[09:32:24] <kshishkov> no, try lesson 3, it's the hardest
[09:33:10] <superdump> i'm normally lazy and don't make the swedish extra bit on 'i' and 'y'
[09:33:20] <superdump> the cute throat bit
[09:33:40] <superdump> that we normally make in english when we're being silly and pretending to be very young
[09:34:18] <kshishkov> go for lesson 3, it features Swedish-only sounds
[09:37:11] <superdump> jag lyssnar nu, or whatever the correct grammar is
[09:37:50] <kshishkov> seems correct
[09:38:00] <superdump> lol
[09:38:08] <superdump> scottish people shit gelatine and cheddar
[09:38:22] <superdump> (yel-ah-teen and shedd-ahr)
[09:38:44] <kshishkov> it's not quite "sh" sound though
[09:38:48] <superdump> i know
[09:39:19] <kshishkov> that's the trickiest thing for me, the rest of sounds sounds fine
[09:40:33] <superdump> some are more of a sh sound and some are more of a 'noise' sound made by narrowing the flow of air between your tongue and the roof of your mouth
[09:40:51] <superdump> you can hear the guy (boz?) gets it
[09:41:23] <superdump> like clearing your throat but in your mouth
[09:41:34] <kshishkov> the second sound is something closer to "ch"
[09:42:01] <superdump> not in the british way of making the ch sound
[09:42:08] <superdump> which is not 'sh'
[09:42:25] * superdump has seen a number of swedish adverts punning on the sound of 'ch'
[09:42:49] <superdump> like 'cheap' and 'sheep' sounding the same
[09:42:53] <superdump> which they don't
[09:43:01] <kshishkov> well, you can think of it like the sound in true Japanese "し"
[09:43:16] <kshishkov> or short Russian "щ"
[09:43:36] <superdump> but some people say 'kan-sher' and others say 'kan-<the noise>'
[09:43:42] <superdump> swedish people
[09:43:58] <kshishkov> could be
[09:46:06] <superdump> they do, i've heard it
[09:46:53] <superdump> sometimes it would make more sense to me to say 'sh' as then the word would more closely resemble the english word
[09:46:59] <superdump> but i like the new sound :)
[09:47:14] <superdump> i sound like an idiot if i try to make the 'i' sound properly though
[09:47:32] <superdump> consistently while talking i mean
[09:49:10] <twnqx> heh, from kernel 2.6.33.1 changelog
[09:49:11] * kshishkov has noted that Swedes speak better English than in English-speaking countries
[09:49:13] <twnqx>     GCC 4.5 introduces behavior that forces the alignment of structures to
[09:49:13] <twnqx>      use the largest possible value. The default value is 32 bytes, so if
[09:49:13] <twnqx>      some structures are defined with a 4-byte alignment and others aren't
[09:49:13] <twnqx>      declared with an alignment constraint at all - it will align at 32-bytes.
[09:49:26] <twnqx> caused non-booting kernels :P
[09:50:09] <kshishkov> way to go
[09:50:24] <kshishkov> maybe Linus finally will start compiler project
[09:50:41] <twnqx> yeah, seems it can "result in a non-standard array"
[09:51:23] <superdump> kshishkov: for the most part yes :)
[09:51:34] <superdump> maybe the accent is more consistent than accents in england
[09:51:59] <kshishkov> and it doesn't have Scotland
[09:52:54] <superdump> :)
[09:53:04] <superdump> kshishkov: maybe look on youtube for rab c nesbit videos
[09:53:08] <superdump> see if you can understand him
[09:53:32] <kshishkov> superdump: forgot to add that long time ago Sweden controlled Scotland though
[09:55:10] <kshishkov> what's the problem? I've watched MPFC without almost any problem
[09:55:27] <superdump> what's that?
[09:55:42] <kshishkov> Monty Python's Flying Circus
[09:55:49] <kshishkov> and it featured Gumbies
[09:56:15] * Kovensky never saw anything monty python
[09:56:22] * Kovensky feels that he should but is too lazy
[09:56:44] * kshishkov drops 16ton weight on Kovensky
[09:56:48] <Kovensky> and I guess I should join the fad and study swedish too but I guess I lack time :S
[09:57:31] <kshishkov> no since you don't belong to Swedish FFmpeg developers group
[09:57:38] <Kovensky> not like I'm really busy but I really should be studying my maths / physics / chemistry (just HS level!) for the upcoming test in july :S
[09:57:55] <Kovensky> kshishkov: I want to go to sweden, does that count? :X
[09:58:10] <superdump> kshishkov: http://www.youtube.com/watch?v=Nrmcxa1yBec
[09:58:12] <superdump> for example
[09:58:17] <superdump> he's the guy in the string vest
[09:58:24] <Kovensky> hmm, I guess not, I'm still missing the "FFmpeg developer" part
[09:58:44] * Kovensky can't do maths to save his life :V
[09:58:52] <twnqx> :S
[09:59:34] <astrange> i always forget the procedures when i have to take tests
[10:01:12] <Kovensky> heh
[10:01:21] * Kovensky *really* needs to study physics / chemistry
[10:01:51] <elenril> look at you still talking when there's science to do
[10:02:00] <Kovensky> since I didn't study those during high school (we had no physics teacher for like 2/3 of HS, and the chem teacher was useless)
[10:02:06] <Kovensky> elenril: :P
[10:02:24] <Kovensky> well, time for me to not skip class today
[10:02:33] <Kovensky> aka time for my daily battle for catching a bus at all :V
[10:02:39] * KotH should study math and psychology
[10:02:42] * Kovensky is off
[10:03:12] <elenril> btw why isn't metadata writing for ogg/flac applied?
[10:03:14] * KotH is on
[10:03:27] <elenril> KotH: why don't you do it =p
[10:03:49] * KotH isn't an ffmpeg developer
[10:03:58] <elenril> you don't have commit rights?
[10:04:11] <astrange> 3905 dezicycles in decode_residual, 2096825 runs, 327 skips -> 3903 dezicycles in decode_residual, 2096812 runs, 340 skips
[10:04:25] <astrange> how do you interpret changing skips, run it over again until it stops?
[10:04:46] <KotH> elenril: i didnt say that i dont have commit right, i just said that i'm not a developer
[10:06:07] <elenril> you have commit rights -> you can apply approved stuff
[10:06:17] <elenril> doesn't really matter if you're a developer or not
[10:08:58] * elenril wonders if chapters should only be copied by default when there's one output file
[10:09:34] <astrange> what other numbers of output files are there?
[10:10:10] <elenril> you can have tons of output files
[10:14:15] <av500> elenril: one could adjust chapter timestamps from multiple input files to multiple output files
[10:15:11] <elenril> av500: that's not something ffmpeg can reasonably guess
[10:15:15] <astrange> hmm
[10:15:26] <astrange> i think it makes sense to copy to everything
[10:15:29] <elenril> i'm only talking about what it should do by default
[10:15:44] <av500> elenril: why guess?
[10:16:02] <av500> ffmpeg should know what output timestamp belongs to what input file, no?
[10:16:41] <av500> elenril: btw, I would like to have an autochapter feature in ffmpeg
[10:16:50] <av500> like, create a chapter every 10min
[10:16:55] <twnqx> superdump: will 8G /tmp be enough?
[10:17:05] <elenril> av500: send patches ;)
[10:17:09] <superdump> not sure
[10:17:13] <av500> elenril: yes, I prolly will
[10:17:21] <superdump> you'll have to ask janne
[10:17:26] <av500> I also have ffplay skip to chapters on PGUP/PGDOWN
[10:17:27] <superdump> but for now you could try it
[10:17:37] <superdump> have a go at 05_throwing-04
[10:17:42] <twnqx> and: who is the "me" in "notify me of the jobs you took"
[10:17:45] <twnqx> ok
[10:17:47] <av500> janneg:
[10:17:51] <superdump> right
[10:17:54] <av500> twnqx: janneg
[10:18:05] <twnqx> eh, throwing 04 isn't there any more :P
[10:18:13] <superdump> oh, cos i have it :)
[10:18:15] <superdump> e-mail?
[10:18:43] <superdump> /query as you please
[10:35:34] <astrange> http://github.com/astrange/ffmpeg/commit/48ff55fc9f3f393633f4e24b0bb8658f72803788 huh, i can't get this to make any difference now that i try it again
[10:35:41] <astrange> across two gccs and clang
[10:48:57] <kshishkov> superdump: seems quite easy to understand, any examples of Welsh accent?
[10:50:02] <j-b> Good morning
[10:50:43] <kshishkov> bonjour
[10:51:02] <av500> 'jour
[10:55:26] <superdump> kshishkov: just search youtube
[10:55:36] <superdump> rab c nesbitt is not easy to understand at all
[10:55:56] <kshishkov> why?
[10:56:05] <superdump> because he doesn't pronounce things
[10:56:09] <superdump> he slurs them all together
[10:56:17] <superdump> signal to noise ratio is very very low
[10:56:36] <superdump> if you speak like him, don't expect to be understood
[10:56:37] <kshishkov> you've not heard local people who think they know English
[10:56:49] <superdump> local where?
[10:57:11] <kshishkov> eastern europe
[10:57:38] <superdump> well, don't expect english natives to understand you
[10:57:44] <superdump> if you sound like rab
[10:58:22] <kshishkov> I'll move to the land of unicorn then
[10:59:22] <superdump> watch english/american tv, pick an accent you like, copy it :)
[10:59:27] <kshishkov> I think the only useful phrase for people like me is "spare a bob, guv"
[10:59:43] <superdump> i don't think so
[10:59:51] <superdump> you're highly skilled
[11:00:07] <superdump> you should be able to get a job
[11:37:00] <av500> j-b: u at "solutions linux"?
[11:37:28] <j-b> I was, yesterday. But VideoLAN has a stand
[11:37:35] <j-b> av500: you are going there?
[11:37:59] <av500> j-b: no
[11:38:10] <av500> I just saw u have a booth
[11:38:39] <j-b> yes, we do. We offer candy and Soda :D
[11:38:48] <j-b> So our booth is popular
[11:39:19] <kshishkov> you should offer striped ice cones
[11:39:56] <thresh> or strippers with cones
[11:40:32] <av500> j-b: the booth is not hidden behing video wall :)
[11:42:41] <janneg> twnqx: thanks
[11:44:12] <twnqx> janneg: my blender produces openexr instead of png, is that a problem? :P
[11:44:37] <janneg> superdump: it's strange, I'm rendering 05_throwing-02 now and it doesn't use more than 6G
[11:44:58] <kshishkov> wrong Blender version then
[11:45:02] <superdump> it's probably just the scene
[11:45:12] <superdump> well maybe i can grab an older blender
[11:45:16] <janneg> twnqx: that wouldn't be a problem but I suspect you're also not rendering the correct resolution
[11:45:30] <twnqx> :o
[11:45:47] <superdump> twnqx: did you download the render_settings.py and overwrite the one in production/scripts/ ?
[11:46:26] <janneg> do you have the render_settings.py from my server in production/scripts/
[11:46:39] * twnqx rm -rf's render
[11:47:43] * twnqx makes up for that by rendering two sets in parallel since 800% was never exceeded
[11:48:33] <kshishkov> don't forget RAM
[11:48:53] <twnqx> i'll add 16G swap to the 16G physical
[11:49:32] <superdump> if it starts swapping it'll be hella slow
[11:49:37] <janneg> twnqx: don't. it will makes things just slow and 8G per frame should be enough
[11:49:43] <kshishkov> so it saves CPU power, see?
[11:49:48] <superdump> :)
[11:53:15] <twnqx> cpu frequency scaling takes care of that :P
[11:56:47] * kshishkov curses at debian having less not installed by default
[11:57:33] <twnqx> lol
[11:57:38] * thresh just doesnt understand who uses 'default' distros
[11:57:52] <janneg> not having more not installed by default would be a bigger problem?
[11:57:57] <janneg> ;0
[11:58:40] <kshishkov> thresh: lazy people who just try it instead of installing it permanently
[12:01:19] <twnqx> lol
[12:01:23] <twnqx> linux kernel sucks
[12:01:27] <twnqx> all cpus @ 100%
[12:01:34] <twnqx> but no, cpu freq stays at 100 MHz
[12:01:37] <twnqx> 1100*
[12:01:43] <kshishkov> wait for GNU Hurd
[12:02:07] <kshishkov> and maybe run cpufreq-info
[12:02:13] <bilboed-pi> twnqx, running as nice ?
[12:03:31] <twnqx> i just forced all cpus to max speed
[12:03:50] <twnqx> and yeah, i hate that the kernel ignores the load of niced processes
[12:04:26] <twnqx> also
[12:04:30] <twnqx> box is stalled
[12:04:34] <twnqx> deleting a file >_>
[12:04:35] <thresh> :-)
[12:04:47] <bilboed-pi> twnqx, yay for io schedulers :)
[12:04:50] <kshishkov> overheated?
[12:04:57] <twnqx> no
[12:05:04] <twnqx> sd 10:0:0:0: [sdi] Very big device. Trying to use READ CAPACITY(16).
[12:05:05] <twnqx> sd 10:0:0:0: [sdi] 13375635456 512-byte logical blocks: (6.84 TB/6.22 TiB)
[12:05:09] <twnqx> Oo funny messages
[12:05:33] <kshishkov> it will be funnier in 10 years
[12:05:39] <thresh> too old.
[12:06:27] <twnqx> i don't think the device is THAT big, even for today
[12:06:34] <twnqx> especially since it's iscsi
[12:06:43] <thresh> not a home machine, though: /dev/mapper/vg-lv00    20T   15T  5,7T  72% /var/lib/vz
[12:07:02] <twnqx> yeah, exactly
[12:07:05] <thresh> plus three others, around 8T each ...
[12:07:06] <twnqx> it's not that big
[12:07:15] <thresh> yeah, it's been there for 3 or so years already
[12:07:39] <twnqx> never noticed it before
[12:07:46] <janneg> twnqx: which cpufreq governor? which kernel? my ondemand has a ignore_nice_load file in sysfs which is set to 0
[12:07:53] <twnqx> ah!
[12:07:58] <twnqx> yes, it was ondemand
[12:08:54] <twnqx> and i need to change some things... a) hardware raid controller, b) hardware crypto accelerators
[12:24:34] <twnqx> janneg: does that file only exist when ondemand is active?
[12:25:41] <twnqx> hm, janneg, my ignore_nice_load is 0 too, yet the cpus stay at 1.1ghz
[12:41:14] <twnqx> superdump: 18 minutes per frame now :S
[12:45:27] <janneg> twnqx: it works as intended here with 'nice -n 19 burnP6'
[12:51:24] * KotH needs more numbercrunching machines
[12:54:36] <twnqx> what for?
[12:54:51] <KotH> BBB and cracking passwords
[12:54:59] <twnqx> just get a mssive array of beagleboards
[12:55:14] <av500> a BBB-BB array
[12:55:18] * KotH doesnt think that most of the heavy stuff runs on a BB
[12:55:32] <twnqx> just use swap on nfs
[12:55:34] <twnqx> or iscsi
[12:55:38] <KotH> lol
[12:55:53] <KotH> or just wait 10y for BBv23
[12:55:59] <thresh> swap on iscsi.
[12:56:06] <thresh> oh joys of 21 century
[12:56:08] <MrNaz_out> awesome! my baklava just arrived
[12:56:12] * MrNaz_out dccs the plate around
[12:56:32] * twnqx grabs some pieces
[12:56:41] <twnqx> thanks!
[12:56:42] <KotH> hey! dont klog my tubes with all that suggar!
[12:57:23] <MrNaz_out> KotH it's ok, your series of tubes can be cleared with a little exercise
[12:57:48] * av500 prefers baklava with less sugar and more nuts
[12:58:08] <MrNaz_out> av500 this has walnuts in the base and crushed pistacio on top
[12:58:21] * KotH preferes baklava that has not traveled around the globe...twice
[12:58:23] <av500> accepted
[12:58:51] <av500> the stuff availabel here is mostly sugar water :(
[12:59:03] <twnqx> poor av500
[12:59:06] <KotH> av500: i feel your pain...
[12:59:14] <twnqx> i'll get you some next time i'm in saudi
[12:59:30] <av500> twnqx: thx!
[12:59:33] <twnqx> usually i only grab a few kg of almond-stuffed, chocolate-covered dates
[12:59:45] <MrNaz_out> twnqx you work in saudi?
[12:59:56] <twnqx> i lived there until december :P
[13:00:01] <twnqx> still have a residency visa
[13:00:03] <MrNaz_out> almost-chocolate dates are awesome
[13:00:10] <MrNaz_out> i lived there in 1994 for a year
[13:00:13] <MrNaz_out> i was 14 years old
[13:00:18] <twnqx> poor you :P
[13:00:19] <MrNaz_out> man... talking about 1994 makes me feel old
[13:00:24] <MrNaz_out> on wait... i *am* old
[13:01:12] <KotH> lol
[13:05:23] <CIA-92> ffmpeg: benoit * r22581 /trunk/libavcodec/qtrleenc.c:
[13:05:23] <CIA-92> ffmpeg: qtrleenc: add rgb555 output
[13:05:23] <CIA-92> ffmpeg: Patch by Alexis Ballier std_gmail_addr(name.surname)
[13:06:39] * KotH wonders who'll be able to decode this email adr in 20y, when gmail will be long gone
[13:07:06] <av500> they can look it up in bing-archive
[13:08:17] <MrNaz_out> KotH the IT staff at that time will need to confer with the village elders
[13:08:40] <av500> they will have to negotiate for generator fuel as well
[13:08:40] <MrNaz_out> in 20y from now we'll have gotten ww3 out of the way and will be well on our way to rediscovering the wheel
[13:09:35] <MrNaz_out> ive been stockpiling manuals on assembler so when we re-invent the 8086 microprocessor i'll have a huge head start!
[13:09:45] <KotH> lol
[13:10:34] * av500 files an A20 gate patent to be applied in 19ys...
[13:11:00] <MrNaz_out> that's assuming the patent office survives the coming war
[13:11:06] <MrNaz_out> i'm hoping it doesnt
[13:11:12] <MrNaz_out> i plan on patenting yoyos
[13:11:32] <av500> MrNaz_out: they will reopen that 1st thing after the war
[13:11:33] <mmu_man> hmm it should be doable with IPOT
[13:11:43] * mmu_man pets IP Over Time
[13:13:49] * KotH notes that this should be made into an RFC... in a non-french language
[13:14:10] <MrNaz_out> with x264 and ffmpeg now being codependent, installing either is now a gigantic pita
[13:14:18] <jai> av500: they might even run a makeshift one out of the trenches during the war...
[13:14:36] <MrNaz_out> jai how would they enforce patents?
[13:14:51] <jai> MrNaz_out: shotguns ofcourse
[13:15:14] <MrNaz_out> im imagining a fat lawyer jumping up and pointing at an incoming shell and yelling "HEY! NO FAIR! THAT STABILIZOR FIN DESIGN IS PATENTED!"
[13:15:53] <jai> lul @ fat lawyer
[13:16:28] <av500> MrNaz_out: no, they will ambush the supply trewck and confiscate the shells with a subpoena :)
[13:16:40] <Kovensky> lol
[13:17:29] <MrNaz_out> yea, the enemy soldiers will end up having to spend their r&r time working to pay off the IP infringement fine
[13:17:41] <MrNaz_out> i think we've just confirmed it:
[13:17:49] <MrNaz_out> lawyers are the ultimate weapon for waging war
[13:18:05] <MrNaz_out> however, i'm sure that there's a geneva convention about that
[13:18:26] <av500> MrNaz_out: there is a reason why the US airdrops lawyers right after bunker busters...
[13:19:42] <jai> lmao
[13:20:20] <av500> now, if they would airdrop them together....
[13:20:51] <MrNaz_out> av500 now i know that the bunker nudter bombs are inanimate objects, but there's no reason to be cruel to them in their last moments of existence
[13:20:57] <MrNaz_out> buster*
[13:25:56] <MrNaz_out> errr
[13:26:05] <MrNaz_out> Ron? i cant find your patch buddy...
[13:27:41] <MrNaz_out> wow speak of the devil
[13:27:48] <MrNaz_out> BBB
[13:27:53] <BBB> ?
[13:27:56] <MrNaz_out> i dont see a posting from you on the mailing list
[13:28:17] <MrNaz_out> with that patch
[13:28:18] <BBB> Fix FFM-based audio streaming from FFmpeg to FFserver
[13:28:30] <BBB> it's there
[13:28:39] <MrNaz_out> ffserver-users ?
[13:28:54] <BBB> huh? is that a mailinglist?
[13:28:56] <jai> hmm, did my matroska muxer patch get lost somewhere
[13:28:57] <BBB> no, ffmpeg-devel
[13:29:00] <MrNaz_out> aah
[13:29:01] <MrNaz_out> k
[13:29:02] <jai> Yuvi: ^
[13:29:07] <BBB> this is a development question in ffmpeg itself
[13:29:09] <BBB> :)
[13:29:15] <BBB> btw I'm not on ffserver-users
[13:29:17] <BBB> maybe I should be
[13:29:33] <jai> BBB: or you could just read the archives...
[13:29:34] <MrNaz_out> BBB yea i petitioned for a ffserver ML a while back and got it... its proven quite useful (although i havent managed to help anyone for a few months now due to lack of time:(  )
[13:30:08] <jai> that reminds me, havent been to #ffmpeg in a while
[13:30:17] <MrNaz_out> BBB nvm once -head gets to a working state i'll start by writing a ffserver zero to basic working guide and use that as a starting point to do support for ffserver
[13:32:58] <BBB> great
[13:33:06] <BBB> I'll look at the archives to see if I'm missing something
[13:33:12] * BBB is not on ffmpeg-users@
[13:50:27] <MrNaz_out> BBB i *think* the audio was the only outstanding issue
[13:51:10] <MrNaz_out> i'm compiling now, if audio is fixed then i believe ffserver is in a currnelty working state with all extra functionality that i've requested over the past year or so
[13:57:58] <DonDiego> superdump: do you accept aac bug reports these days or should i direct them all to peloverde?
[14:01:54] <superdump> put them on roundup, then whoever wants and has time to can look at them
[14:02:53] <DonDiego> i'd like to quickly discuss them here on irc first
[14:03:10] <DonDiego> i'll wait until the two of you are around
[14:03:24] <superdump> well you can say it now if you want
[14:06:14] <DonDiego> i was just testing the samples collection and noticed a few things
[14:06:34] <superdump> such as...?
[14:06:38] <DonDiego> let's talk about this later, i need to run out anyway
[14:06:50] <DonDiego> bbl
[14:07:46] <superdump> ok
[14:11:24] <kshishkov> is there any kind of horoscope to predict where you three will meet?
[14:12:07] <mru> who three?
[14:12:47] <kshishkov> DonDiego and two people who he wanted to talk to about AAC
[14:13:11] <BBB> MrNaz_out: don't forget you need the FFM patch also
[14:13:29] <BBB> MrNaz_out: [PATCH] fix the SAMPLE_FMT_NONE case in ffmdec.c
[14:13:33] <BBB> that thread
[14:13:39] <BBB> otherwise the FFM file itself is invalid
[14:14:06] <MrNaz_out> oh there's two patches?
[14:14:22] * MrNaz_out looks again
[14:27:28] <BBB> MrNaz_out: let me know if you cannot find it
[14:27:57] <MrNaz_out> BBB i can see the one thread
[14:28:20] <BBB> there's a one-liner patch for ffmdec.c
[14:28:27] <BBB> and somewhat bigger patches for ffserver.c/ffmpeg.c
[14:28:34] <MrNaz_out> and i have the patch from that one... which are the two files? i only see fix-ffm-no_sample_fmt.patch
[14:29:17] <BBB> the other one is in the other thread I just pointed out
[14:29:29] <BBB> "Fix FFM-based audio streaming from FFmpeg to FFserver"
[14:30:16] <MrNaz_out> i dont suppose i could be a total pain in the ass noob and ask you to email them all to me so i know which ones are the right ones? there's a few versions there and it's not clear to me which one is the latest as the thread branches off in a few places and theres different versions and fixes along the way
[14:30:39] <BBB> they all work, they're just under review
[14:30:45] <MrNaz_out> ok
[14:30:47] <BBB> so you can pick any one
[14:30:55] <BBB> they do the same thing, but differently
[14:33:28] <MrNaz_out> got e,
[14:33:29] <MrNaz_out> em
[14:33:32] <MrNaz_out> compiling now
[14:43:51] <CIA-92> ffmpeg: mru * r22582 /trunk/common.mak:
[14:43:51] <CIA-92> ffmpeg: Make ranlib silent in brief output mode
[14:43:51] <CIA-92> ffmpeg: Running ranlib is quick and uninteresting, no need to print it.
[14:43:53] <CIA-92> ffmpeg: mru * r22583 /trunk/subdir.mak:
[14:43:53] <CIA-92> ffmpeg: Remove $(MSG) override for install-lib targets
[14:43:53] <CIA-92> ffmpeg: This is no longer needed and causes incorrect output in some cases.
[14:44:40] <roozhou> hi, anyone knows how to set internal time_base in frame copy mode?
[15:04:27] <MrNaz_out> BBB you still here?
[15:04:40] <MrNaz_out> if you are   http://www.ymatv.com/?watch&res=high    i think i can say that those patches work :)
[15:05:54] <jai> you patched your production server??
[15:06:14] * av500 wonders why he is spying on right now...
[15:06:45] <av500> why->who
[15:07:16] <CIA-92> ffmpeg: cehoyos * r22584 /trunk/libavcodec/h264dsp.c: Fix compilation on PPC 470.
[15:12:47] <BBB> MrNaz_out: thanks for confirming! :)
[15:15:11] <MrNaz_out> BBB dont suppose you want to help me get the h264 params right do you? :)
[15:15:25] <BBB> no h264 hero here, sorry
[15:15:33] <BBB> you want to ask dark_shikari
[15:15:41] <CIA-92> ffmpeg: rbultje * r22585 /trunk/libavformat/ffmdec.c:
[15:15:41] <CIA-92> ffmpeg: Cast sample_fmt (as read from bitstream as a 16-bit value) to int16, so that
[15:15:41] <CIA-92> ffmpeg: negative values, e.g. SAMPLE_FMT_NONE (-1), are read correctly also.
[15:18:43] <kierank> MrNaz_out, what about h.264 do you need to know? I might be able to help
[15:19:24] <MrNaz_out> kierank ive got a ffserver config file with some h264 settings in it
[15:21:55] <MrNaz_out> http://pastebin.com/WQNd8z5u  <-- that's the conf i have right now...
[15:22:01] <MrNaz_out> for stremaing, can you recommend any changes ?
[15:25:10] <kierank> bufsize is a bit big
[15:26:16] <kierank> but you might want it like that
[15:28:52] <MrNaz_out> kierank when you watch the stream, do you get pauses? http://www.ymatv.com/?watch&res=high
[15:29:12] <MrNaz_out> when i watch it here it's pausing every so often as though to buffer
[15:29:49] <kierank> yes
[15:29:55] <MrNaz_out> see
[15:30:07] <MrNaz_out> i dont get that with the old version
[15:30:30] <kierank> reduce bufsize to something more reasonable
[15:30:46] <MrNaz_out> such as?
[15:31:15] <kierank> 300-500k
[15:31:30] <MrNaz_out> i thought that bufsize had to be bitrate * buffer length
[15:31:37] <MrNaz_out> in this case, i want 4 seconds worth of buffer
[15:31:59] <kierank> then what you have is ok if you want 4 seconds of buffer
[15:34:02] <BBB> peloverde: it's an iterative wiener filter, if you want to test your google skills, I figured that out yesterday
[15:34:10] <BBB> there's some good papers on it
[15:36:49] <peloverde> glad to hear you figured it out
[15:37:00] <MrNaz_out> BBB dont suppose you could offer some shell scripting advice?
[15:37:09] <BBB> I can try
[15:37:22] <BBB> peloverde: thanks for the repeated hints at hilbert, that helped a lot
[15:37:58] <BBB> MrNaz_out: what exactly do you need? I'm not a shell-scripting hero, but know a little
[15:38:30] <mru> don't we have any resident shell gurus here?
[15:39:09] <BBB> you
[15:39:12] <BBB> and dondiego
[15:39:14] <MrNaz_out> BBB  http://pastebin.com/bpRdbVYV  currently that's my script to feed ffmpeg... however, if there are any network latency issues or for some other reason ffmpeg is held up... the resulting stuttering occurs in the grabbed dv file as well... is there any way to ensure that the dvgrab and tee part of that command are not affected by whatever happens with ffmpeg? i think a fifo could work but my script-fu is nowhere near good enough
[15:39:15] <BBB> more than me at least
[15:39:42] <MrNaz_out> well my question is open to all :)
[15:42:35] <mru> dvgrab loses frames if the pipe blocks?
[15:43:55] <MrNaz_out> yea
[15:44:33] <MrNaz_out> well
[15:44:43] <MrNaz_out> it could be that tee is what actually loses the data
[15:44:56] <mru> dvgrab -f dv1 >"$fname" &
[15:45:08] <mru> tail -c+1 "$fname" | ffmpeg -i - ...
[15:45:17] <mru> tee never loses data
[15:45:37] <mru> but if its output blocks, the input will block
[15:46:15] <MrNaz_out> so if ffmpeg blocks then that will cause tee's input to block ?
[15:46:28] <mru> once the pipe buffers fill up, yes
[15:46:37] <mru> the pipe buffers are typically a few k
[15:47:24] <MrNaz_out> mru http://pastebin.com/0hnKB8Ab  so that will prevent ffmpeg blocks from killing dvgrab's output ?
[15:48:02] * peloverde scratches his head at some of the stranger SBR bug reports
[15:48:20] <mru> MrNaz_out: that runs dvgrab and ffmpeg independently
[15:48:46] <mru> it might fail if tail polls the file too infrequently
[15:49:11] <mru> you could always cook your own tee-like app with two threads and bigger buffers
[15:50:41] <DonDiego> peloverde: nice to see you are around..
[15:50:52] <DonDiego> peloverde: have you already tested all the samples from our collection?
[15:51:10] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/
[15:51:26] <peloverde> yes
[15:52:52] <DonDiego> i found some issues
[15:53:01] <peloverde> which files?
[15:53:10] <DonDiego> superdump: ping
[15:53:18] <DonDiego> let me run through the lot of them..
[15:53:20] <superdump> pong
[15:53:47] * superdump is expecting a bunch of channel config related crap for invalid files
[15:54:59] <DonDiego> gah, give me a sec i need to pull the samples
[15:55:03] * DonDiego is at work
[15:55:07] <MrNaz_out> mru that does not work when i need to use sudo
[15:55:10] <DonDiego> psssst! ;)
[15:55:29] <mru> MrNaz_out: huh?
[15:55:36] <MrNaz_out> http://pastebin.com/6vX7XQD8
[15:55:48] <mru> and?
[15:55:57] <MrNaz_out> prolly easier if i paste
[15:56:21] <mru> you really shouldn't be running stuff as root
[15:56:29] <mru> why does dvgrab need to be root?
[15:56:47] <MrNaz_out> http://pastebin.com/yQ7mtycx
[15:57:26] <bilboed-pi> chmod a+x /dev/raw1394 (or whatever the device is) should avoid having to run dvgrab as root
[15:57:31] <MrNaz_out> dvgrab needs to be root coz it accesses raw1394 and a few other devices that require root... i'm not entirely sure, but a year ago when i was first setting all this up i spent the best part of 4 hours trying to get around that
[15:57:39] <bilboed-pi> s/a+x/a+rwx/
[15:57:45] <mru> bilboed-pi: why x?
[15:57:47] <MrNaz_out> bilboed-pi can you chmod a device like that?
[15:57:51] <bilboed-pi> MrNaz_out, sure
[15:57:56] <mru> surely you don't want to _execute_ the dv data
[15:58:06] <MrNaz_out> i seem to recall that not working... let me try again
[15:58:19] <mru> MrNaz_out: your ffmpeg is old
[15:58:23] <mru> it's missing a fix from last night
[15:58:25] <bilboed-pi> mru, I did encounter a case when it needed to have the executable bit set :(
[15:58:34] <av500> mru: if you points the camera at a code printout, it might work
[15:58:45] <MrNaz_out> mru 48 hours is old these days? shit eh...
[15:58:56] <mru> 48h is ancient
[15:59:13] <mru> we're talking 18h here
[15:59:37] <MrNaz_out> in related news, the ffmpeg scene starts talking in l33t and referring to patches as "0day"
[15:59:44] <av500> tversity looking for ffmpeg codec wrappers..... maybe openmax :)
[16:00:19] <jai> av500: did you ask what exactly they have in mind?
[16:00:26] <mru> oh, and tail needs a -f flag
[16:00:46] <av500> jai: no, its on the ml
[16:01:10] <MrNaz_out> mru so    tail -c+1 -f "$fname"     ?
[16:01:17] <mru> should work
[16:01:59] <jai> av500: ah, i see you replied
[16:02:10] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/8_Channel_ID.m4a
[16:02:14] <DonDiego> let's start here
[16:02:22] <DonDiego> ffplay tells me it cannot open codecs
[16:02:35] <DonDiego> but mplayer has no problems (with lavf demuxer)
[16:02:52] <jai> sdl sucks
[16:02:53] <peloverde> DonDiego: FFplay doesn't work on my system
[16:03:49] <av500> peloverde: and that cannot be fixed?
[16:03:51] <jai> you could test with alsa i think
[16:03:55] <superdump> i'll give it a go in a sec
[16:04:10] <mru> DonDiego: that's an ffplay/sdl bug it seems
[16:04:19] <jai> yep
[16:04:31] <jai> same goes for a bunch of truehd samples we have
[16:04:36] <av500> 8_Channel_ID.m4a: could not open codecs
[16:04:37] <mru> the file plays fine with non-sdl players
[16:04:49] <mru> the error message should probably be improved
[16:05:46] <DonDiego> [aac @ 0x26ab710]max_analyze_duration reached
[16:05:46] <DonDiego> [aac @ 0x26ab710]Estimating duration from bitrate, this may be inaccurate
[16:05:52] <DonDiego> several files print this stuff
[16:06:04] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/ct_faac-adts.aac
[16:06:07] <DonDiego> this one for example
[16:06:08] <peloverde> DonDiego: That isn't the AAC decoder
[16:06:20] <peloverde> that's the probes
[16:06:52] <DonDiego> it's still your area :)
[16:06:52] <peloverde> Or demuxer
[16:07:07] <peloverde> No it isn't, it's a techincal limitation of the ADTS format
[16:07:18] <DonDiego> but do we need the spam?
[16:07:35] <DonDiego> if it will get printed for every adts file, it's pointless
[16:07:37] <jai> bump up the max_analyze_duration vaue
[16:07:40] <jai> *value
[16:08:48] <peloverde> ADTS doesn't have any sort of size field, for VBR ADTS the only way to get the length is to decode the whole file
[16:09:17] <DonDiego> fine, but do we need to be informed about this for every file?
[16:09:27] <peloverde> That error is printed in libavformat/utils.c, complain to said maintainer
[16:09:41] <peloverde> I find it useful to know that the size estimate may be wrong
[16:09:48] <av500> mru: so the issue is that avctx->request_channels asks for 2, but the codec is not able to fullfill that and still delivers 8, then SDL fails
[16:09:53] <peloverde> It doesn't print it every frame
[16:09:59] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/faad2-fail.mkv
[16:10:02] <jai> the reason its verbose is because people complain about duration being incorrect
[16:10:06] <DonDiego> this one is seriously broken
[16:10:19] <roozhou> peloverde: iirc frame length is stored in ADTS header
[16:10:25] <DonDiego> sound is played much too slowly
[16:11:08] <peloverde> roozhou: kind of, the frame length in samples is always 1024 samples, except when it's not :), the issues is the total number of frames
[16:12:12] <roozhou> peloverde: i mean the size of frame in bytes
[16:12:29] <peloverde> DonDiego: faad2-fail plays fine for me
[16:12:42] <roozhou> why do we need to DECODE the frame?
[16:13:03] <jai> roozhou: he said decode the _file_
[16:13:45] <roozhou> better call it "parse the file"
[16:13:59] <mru> DonDiego: that file plays just fine here
[16:14:24] <jai> roozhou: i think we understood what he meant
[16:16:30] <peloverde> I meant parse
[16:16:50] <roozhou> can anyone help me with time_base issues in frame copy mode?
[16:16:52] <peloverde> You can't get the channel count without decoding
[16:18:40] <roozhou> ffmpeg -i input.mkv -vcodec copy -an output.flv
[16:18:40] <roozhou> ffmpeg -i input.mkv -vcodec copy -an output.mp4
[16:18:40] <roozhou> I get different time_base, why?
[16:19:04] <peloverde> But I'm not seeing an issue with "ffmpeg -vn -i faad2-fail.mkv out.wav"
[16:19:27] <av500> mru: peloverde: it plays too slow here
[16:20:28] <mru> av500: up to date ffmpeg?
[16:20:48] <av500> rebuilding
[16:21:01] <av500> it was *cough* yesterdays
[16:21:44] <peloverde> I imagine yesterday's should be good
[16:21:54] <av500> still to slow
[16:22:08] <mru> get a faster computer :-)
[16:22:27] <av500> right, there was this 6core I7....
[16:22:38] <av500> and it is a 6channel file, so it makes sense
[16:22:50] <BBB> mru, MrNaz_out: bash has a buffer command for that
[16:23:10] <BBB> at least in linux, it used to have something like that
[16:23:16] <BBB> we used it a lot in mjpegtools for obvious reasons
[16:23:22] <KotH> is anyone working on wma lossles?
[16:23:39] <BBB> KotH: I thought jai was working on lossless
[16:23:50] <mru> BBB: literally "buffer"?
[16:24:01] <jai> KotH, BBB : on and off, yeah :)
[16:24:16] <KotH> jai: do you have enough samples?
[16:24:19] <jai> got busy because of postgrad applications :/
[16:24:34] <KotH> jai: or shall i extort some from all the users showing up in #mplayer that want wma lossless support?
[16:24:38] <jai> KotH: yep, have the refernce encoder :)
[16:24:40] <BBB> mru: IIRC yes, but doesn't work on my mac :)
[16:24:49] <jai> KotH: people actually want wmals???
[16:24:57] <jai> i'm doing this for the kicks
[16:25:11] <jai> err, *reference
[16:25:12] <KotH> yeah tons of them
[16:25:22] <KotH> about one per week or so
[16:25:27] <jai> lol
[16:25:48] <KotH> there was just one in  #mplayer who was confused why his mplayer couldnt play that stuff
[16:25:54] <peloverde> DonDiego, av500: is it proper speed if you decode to a file then play that?
[16:26:03] <BBB> KotH: is wmavoice used at all?
[16:26:08] <KotH> and complaining that he'd use ffmpeg if possible
[16:26:11] <BBB> jai: upload it to the codecs repo so we can help
[16:26:17] <BBB> I'd like to see how you do it also
[16:26:26] <KotH> BBB: uhmm.. i think there were people who are using that too
[16:26:26] <jai> BBB: sure thing
[16:26:36] <av500> peloverde: as in? ffmpeg to something?
[16:26:39] <merbzt> the music industry uses wmalossless also
[16:27:09] <kierank> btw merbzt i have the wma pro over spdif spec if you don't have it
[16:27:10] <jai> BBB: according to Facebook's user upload stats, wmavoice is quite rpevalent
[16:27:13] <jai> *prevalent
[16:27:27] <merbzt> kierank: send it to my email
[16:27:52] * KotH wonders whether he should propose a patch that would collect codec usage data from mplayer
[16:27:52] <peloverde> av500: as in "ffmpeg -vn -i faad2-fail.mkv out.wav", then "ffplay audio.wav"
[16:29:21] <av500> peloverde: yes, still slow
[16:29:46] <av500> let me play that on someting else
[16:29:51] <BBB> jai: ok, cool
[16:30:40] <av500> peloverde: out.wav is ok on PC with VLC
[16:31:41] <BBB> jai: how is ralf going?
[16:32:02] <peloverde> hmmm... that's strange
[16:32:31] <av500> peloverde: I think the issue is SDL
[16:32:51] <av500> if I play 6ch AC3, we request 2ch from decoder and get them, then SDL plays 2ch fine
[16:32:55] <kierank> merbzt: anything else you want while i'm at it?
[16:33:07] <av500> for this file, we request 2, but get 6 and SDL does not seem to handle that here
[16:33:36] <peloverde> ac-3 has an in-codec downmix feature
[16:33:39] <av500> yes
[16:33:56] <av500> and it seems that this SDL here happily accepts 6ch, only to play it over 2, so 3x slow
[16:35:00] <jai> BBB: also, slow :/ though i'm planning to get back to the pending stuff soon
[16:35:12] <jai> BBB: done with admissions etc so should have free time
[16:35:53] <BBB> ok, don't let me push you, just interested in the codecs themselves
[16:35:54] <peloverde> That's probably what's happening
[16:36:42] <jai> BBB: nah, i really need to get some stuff done :)
[16:38:51] <jai> BBB: btw, i see that ralf is a gsoc project?
[16:39:01] <BBB> oh, I added that
[16:39:03] <BBB> nobody applied
[16:39:07] <BBB> I was hoping you'd apply for it
[16:39:18] <kierank> hmm seems i also have access to jpeg-xr specs
[16:39:27] <jai> BBB: ah, technically i'm a student from august onwards so.. :)
[16:40:32] <jai> anyway, there seem to be other tasks which should be more priority i guess
[16:40:49] <jai> libavfilter audio support for example
[16:43:15] <BBB> anything that you like :)
[16:49:24] <nfl> hi im interested in the seeking api gsoc task. was wondering if yop demuxer/decoder is a good enough small task for this..
[16:52:38] <BBB> ait for bcoudurier, he will mentor that
[16:52:40] <BBB> +w
[17:09:54] <BBB> peloverde: when you have some time, could I ask you to review my complete postfilter patch to see if it looks sane to you?
[17:10:16] <BBB> without tables, it's about 550LOC
[17:15:54] <BBB> merbzt: same question for you, if you have time
[17:18:59] <peloverde> BBB: I'm really trying to make some serious headway on PS today, I should have time tomorrow to give it a look
[17:19:06] <BBB> ok, thansk
[17:26:06] <superdump> ok, everyone form a wall around peloverde
[17:35:43] <ramiro> there's someone on ffmpeg-user saying the native aac encoder is horrible. can we say it's still "experimental"?
[17:36:26] <kshishkov> since peloverde changes have not hit SVN yet, it is experimental
[17:36:32] <kshishkov> (and horrible)
[17:36:49] <peloverde> yes, we can still say it's experimental
[17:36:56] <peloverde> that's what the changelog entry says
[17:37:06] <peloverde> I should have some time for it post PS
[17:37:43] <ramiro> replied.
[17:38:44] <kshishkov> it will be  major piece of news when ffaacenc becomes non-experimental
[17:38:53] <ramiro> kind of like vlc went 1.0?
[17:40:27] <DonDiego> peloverde: ok, so it was an sdl problem
[17:40:29] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/faad_infinite_long.aacp
[17:40:39] <DonDiego> this one produces some serious console spam
[17:40:48] <DonDiego> [aac @ 0x1a114d0]Parametric Stereo is not implemented. Update your FFmpeg version to the newest one from SVN. If the p
[17:40:49] <peloverde> because it has serious errors
[17:40:51] <DonDiego> roblem still occurs, it means that your file has a feature which has not been implemented.
[17:41:07] <peloverde> DonDiego: people asked for that message during SBR review
[17:41:09] <DonDiego> other similar messages are only printed once
[17:41:34] <DonDiego> they did not ask for that message to be printed thousands of times :)
[17:41:53] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/faad_infiniteloop.aacp
[17:41:55] <DonDiego> same problem
[17:42:18] <av500> DonDiego: the SBR message was also printed for every frame....
[17:42:19] <peloverde> ff_log_missing_feature("ff_log_missing_feature_once()", 0);
[17:43:01] <DonDiego> peloverde: fix it :)
[17:43:04] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/Major%2006%20kwestia%2003.mka
[17:43:11] <DonDiego> that sample also spams the console
[17:43:21] <DonDiego> and i think it's not a broken file
[17:43:57] <peloverde> The choices were log not at all, log every frame it happens, or someone else implement ff_log_missing_feature_once()
[17:46:05] <peloverde> That file seems trashed to me, it's calling reserved SBR extensions
[17:46:48] <kshishkov> reminds me of RealVideo
[17:47:11] <kshishkov> if somewhere dquant is met, it means that file is broken
[17:47:40] <av500> I always used the file extension to match for that :)
[17:47:41] <kshishkov> it's valid bitstream syntax but no actual file is using it
[17:49:42] <DonDiego> peloverde: well, it's annoying..
[17:49:43] <peloverde> Also that file reads past the end of SBR elements which is a serious issue
[17:50:04] <peloverde> Then implement ff_log_missing_feature_once() and I'll be glad to change it
[17:50:13] <DonDiego> :)
[17:50:32] <DonDiego> i just ran through the list of samples today to doublecheck
[17:50:51] <av500> av_log(c, AV_LOG_INFO | AV_LOG_ONCE, "foo"); ?
[17:50:52] <DonDiego> and check what libfaad can do that ffmpeg can't
[17:51:12] <av500> or av_log_once(c, AV_LOG_INFO, "foo");
[17:51:55] <astrange> http://pastebin.com/FZY9s2u5
[17:52:11] <astrange> but now i think it should just be another parameter to av_log_missing_feature()
[17:52:45] <DonDiego> astrange: please submit this :)
[17:53:34] <av500> once could even be default, no?
[17:55:49] <peloverde> DonDiego: Do you have anymore information on where that file came from? it is very screwed up but seems to playback ok
[17:56:19] <peloverde> My main complaint with the samples archive is that it never says where anything came from or what feature/bug it tests
[17:56:50] <astrange> there are supposed to be .txt files for that but many are missin g
[17:59:13] <DonDiego> no, i dunno where it came from
[18:01:15] <peloverde> That file is seriously screwed up but it feels constructed
[18:02:08] <DonDiego> astrange: also, what was it about ffmpeg2 being slow compared to libmpeg2?
[18:02:21] <mru> nonsense
[18:02:31] <mru> that was the case a long time ago
[18:03:40] <astrange> it was 1s faster in my mplayer on a 30sec 1080p clip, but i noticed my mplayer is actually a month or two old
[18:03:50] <astrange> not that mpeg12 has changed since then
[18:04:10] <mru> try it on arm
[18:04:15] <astrange> ffmpeg2 should be faster using the xvid idct or using threads, but those aren't default
[18:05:25] <DonDiego> nobody doubts it's faster on arm, but it should be faster on x86 as well
[18:05:38] <DonDiego> astrange: you said you knew how to speed it up...
[18:06:02] <mru> someone should write ssssseeeeee3 asm for it
[18:06:09] <mru> I'm sure something could be improved there
[18:08:04] <astrange> i think some multiplies can be taken out of the C part before getting to that
[18:08:21] <astrange> but sse2/4 simpleidct would help a lot, yes
[18:08:44] <astrange> anyway they're still pretty close and ffmpeg2 is already the default, so i don't mind removing internal libmpeg2
[18:10:30] <BBB> DonDiego: you can surely fix up a patch that makes ff_log_missing_feature() only do that once
[18:12:07] <astrange> i'm going with adding a 'once' parameter to it, but that has the side effect of adding NULL to every existing call
[18:15:31] <mru> the alternative is to make it a macro
[18:16:36] <BBB> make it a macro
[18:16:38] <kshishkov> probably a macro - how else it will deal with static variables?
[18:16:40] <mru> that could be done without breaking abi
[18:16:43] <BBB> and always make it once
[18:16:51] <BBB> I cannot imagine that you'd NOT want it to be once and spam the console
[18:17:12] <kshishkov> you're not evil enough then
[18:17:16] <mru> if some place really need that, it can override the macro by calling it as (func)(args)
[18:17:17] <BBB> :)
[18:17:24] <astrange> well, you have to add a context variable for every log if they're all going to be once
[18:17:31] <mru> no
[18:17:36] <astrange> it's either that or a hash table per log message
[18:18:00] <kshishkov> yuck
[18:18:07] <mru> #define blah() do { static int once; if (!once) blah(); once=1; } while (0)
[18:18:13] <BBB> #define ff_log_missing_feature(ctx, bla, one_zero) { static int did = 0; printf(""); did=1; }
[18:18:21] * BBB kicks mru
[18:18:26] <BBB> you type faster, unfair
[18:18:39] <kshishkov> type smarter, not faster :P
[18:18:48] <BBB> ohyeah he added the if()
[18:18:49] <BBB> :)
[18:19:03] <mru> that's an essential part
[18:19:03] <astrange> might be printed twice with threads. doesn't matter i guess
[18:20:59] <BBB> astrange: indeed
[18:21:25] <kshishkov> depends on number of tracks for that race condition
[18:22:00] * BBB goes look for new project to RE
[18:22:19] <BBB> jai does losslesses, wvp2 is for gsoc...
[18:22:24] <kshishkov> VoxWare! Indeo Audio!
[18:22:24] <BBB> what shall I do?
[18:22:32] <BBB> indeo... yeah you mentioned that before
[18:22:41] <BBB> I'll see what I think of it in a debugger
[18:22:44] <jai> BBB: VP8 ;)
[18:22:49] <kshishkov> voxware is more important though
[18:22:52] <BBB> vp8 will be open soon, no reason to RE
[18:22:54] <BBB> waste of time
[18:23:00] <peloverde> ProRes, AIC?
[18:23:02] <jai> heh
[18:23:07] <jai> BBB: tak
[18:23:25] * BBB goes look at wvp2 also
[18:23:26] <kshishkov> jai: tak goes to Ukraine
[18:23:29] <BBB> does anyone have that binary?
[18:23:31] <jai> wasnt kshishkov working on aic
[18:23:35] <kierank> dts-hd
[18:23:48] <kshishkov> BBB: mplayerhq.hu does
[18:23:53] <jai> kshishkov: excellent :)
[18:23:57] <BBB> what's the name again?
[18:23:58] <kshishkov> BBB: wmvadvdec.dll
[18:24:01] <peloverde> mp3pro
[18:24:31] <kshishkov> jai: in case you still didn't get it, I tend to use word "Ukraine" instead of certain swearwords
[18:24:49] <jai> kshishkov: oh, i thought you meant you'll do it at some point :)
[18:24:54] <astrange> if you RE tak he'll probably change the format in the next version
[18:25:11] <kshishkov> I read discussion about opensourcing it at HA
[18:25:11] <jai> astrange: same threat came from bink devs
[18:25:19] <kshishkov> jai: no
[18:25:27] <jai> but yeah, it would be a pita
[18:25:37] <jai> kshishkov: so they have frozen the format?
[18:25:42] <kshishkov> from RAR devs - yes, from Bink dev it was "go ahead"
[18:26:12] <BBB> wmvadvd.dll for me
[18:26:15] * BBB loads
[18:26:18] <kshishkov> no, but it would be easy to update in case of something
[18:26:19] <jai> kshishkov: hmm, didnt that guy say that they keep changing it with every release
[18:26:43] <kshishkov> jai: who cares, most samples play well
[18:26:57] <jai> kshishkov: sure
[18:27:07] <kshishkov> and someone can add Bink version b for completeness sake
[18:27:46] <peloverde> DonDiego: turns out nothing was screwed up about Major 06 kwestia 03, I was in my PS tree and it was bumping up against my incomplete PS code
[18:28:13] <kshishkov> BBB: I have a bit of practice recognizing functions in binary WMV decoders
[18:28:31] <kshishkov> BBB: if you don't know WVP2 may be described as "WMV3 with sprites"
[18:29:05] <kshishkov> BBB: seems to be almost the same bitstream format with additional logic
[18:30:05] <BBB> uhm... so it's an adaptation of wmv3?
[18:30:18] <kshishkov> of course!
[18:30:53] <BBB> yay
[18:31:17] <kshishkov> ever wondered why that dll decodes WMV3, WMVA and WVP2 in a single package?
[18:31:38] <BBB> really?
[18:31:47] <kshishkov> yes
[18:32:18] <BBB> omg I picked the biggest of the wm* dlls
[18:32:23] * BBB bashes head against wall
[18:32:25] <BBB> ohwell
[18:32:36] <BBB> if it's an adaptation of wmv3 then it shouldn't be too bad
[18:32:43] <kshishkov> no, look at MSS1/2 DMO decoder
[18:33:09] <BBB> famous last words?
[18:33:22] <kshishkov> it's also more than a megabyte - and it's decoder only
[18:35:05] <kshishkov> unfortunately, all that IDA work resides on harddrive I can't read
[18:35:15] <BBB> :-p
[18:35:22] <kshishkov> (because there's no box with sata here)
[18:35:37] <mru> get usb-sata cable
[18:35:38] <BBB> I think I should simply start by wrapping the DLL in a ffmpeg wraper
[18:35:58] <kshishkov> mru: I shall, when it's possible to walk outside
[18:46:27] <kierank> any idea what SRCD could stand for? (Context: "subroutine error DD_SRCD_CONV returned %d" )
[18:46:47] <kshishkov> source code?
[18:47:09] <kshishkov> or source data
[18:47:56] <mru> or SR code, whatever that is
[18:48:22] <kshishkov> or shift-right coded decimal :)
[18:48:48] <astrange> sample rate conversion something
[18:48:53] <mru> google offers some options
[18:48:59] <mru> Society for Research in Child Development
[18:49:09] <mru> Sydney RC Drifters
[18:49:24] <mru> Scoil Rince Chill Dara
[19:00:10] <astrange> oops, changed the patch and it won't finish recompiling before i have to go to class... a few minutes ago
[19:00:13] <astrange> i'll send it later
[19:00:44] <ramiro> astrange: I guess I'm not the only one who should have been in class a few minutes ago...
[19:06:12] <bcoudurier> hi guys
[19:06:39] <kshishkov> hi scripted greeting
[19:10:52] <DonDiego> peloverde: please fill me in about latm support again
[19:11:05] <DonDiego> i know i must have asked about a thousand times, sorry
[19:11:24] <BBB> there's several issue tracker entries claiming sbr is broken btw?
[19:11:32] <BBB> (recent ones, like "last few days")
[19:21:29] <peloverde> DonDiego: the LATM has been in the same situation since Last april http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-April/068484.html
[19:22:00] <peloverde> BBB: Across a variety of configure options I've been unable to reproduce the silent SBR issue
[19:22:41] <peloverde> I've tried x86 32 and 64 bit builds with no asm, no yasm, and full asm, none trigger it for me
[19:25:46] <nfl> bcoudurier: hi im interested in the seeking api gsoc task. is yop playback system a good enough small task for this?
[19:33:15] <bcoudurier> IMHO latm should be added to the decoder
[19:33:27] <bcoudurier> parsing could get quite complicated
[19:33:35] <bcoudurier> peloverde, what do you think about that ?
[19:33:47] <bcoudurier> nfl, not really IMHO
[19:34:03] <peloverde> LATM isn't AAC specific
[19:34:13] <kierank> it should be chained demuxing imo as with smpte-337m
[19:35:00] <bcoudurier> well I'm not sure
[19:35:11] <bcoudurier> s337m is trivial
[19:35:29] <kierank> but there's still multiple streams that impersonate as one
[19:35:33] <kierank> which is similar to latm
[19:35:52] <bcoudurier> is it used in practice ?
[19:36:05] <kierank> only with dolby e
[19:36:16] <bcoudurier> that's because dolby-e is marked as pcm
[19:36:23] <bcoudurier> used in passthough
[19:37:03] <kierank> everything is effectively pcm with smpte-337m
[19:37:05] <bcoudurier> through SDI link basically
[19:37:18] <bcoudurier> then the dobly-e hardware decoder is plugged in
[19:37:43] <bcoudurier> I believe LATM is only used with AAC in TS currently
[19:38:04] <kierank> well yes but my point is that ts -> latm -> multistream aac is sort of like ts -> smpte-302m -> smpte-337m -> dolby e
[19:38:12] <kierank> in that there are multiple demux stages
[19:38:30] <bcoudurier> I have a feeling that probably chained decoders is easier that chained demuxers
[19:39:29] <Dark_Shikari> we already do chained demuxers
[19:39:41] <bcoudurier> like ?
[19:39:54] <kshishkov> that's ball-and-chained demuxers
[19:40:01] <kshishkov> dv-in-avi
[19:40:08] <Dark_Shikari> dv in mov
[19:40:08] <kshishkov> mpeg-in-mov?
[19:40:14] <bcoudurier> that's the only case dv in something
[19:40:27] <Dark_Shikari> if we ever supported it
[19:40:29] <bcoudurier> and that is awfully hackish
[19:40:29] <Dark_Shikari> vorbis in ogg in avi
[19:40:33] <Dark_Shikari> ;)
[19:40:48] <kshishkov> asf-in-mov ftw
[19:41:48] <mru> I've heard of mpegts in mp4
[19:41:55] <kierank> i've heard of that too
[19:41:56] <bcoudurier> mru, exact
[19:42:03] <bcoudurier> there are specs also
[19:42:11] <superdump> lol
[19:42:12] <kshishkov> there is mpeg-ts/es in avi too
[19:42:18] <peloverde> The truth is there are about a dozen ways to mux AAC into various containers and they shouldn't all be jammed into the AAC decoder, it's nutty, especially when many of them can be used with any MPEG-4 audio format
[19:42:35] <peloverde> Just handling ADTS and ASC has already caused a huge mess
[19:42:56] <superdump> the channel config stuff is fuuuuun
[19:43:05] <superdump> especially when people don't do it right
[19:43:12] <superdump> (files i mean)
[19:43:13] <bcoudurier> well according to manufacturers APIs they all support LATM through the aac decoder
[19:44:23] <bcoudurier> for dolby-e I'm sure it supports s302m as input and if its pcm, just copy the frames
[19:44:51] <bcoudurier> like the wrle decoder handles both uncompressed and compressed
[19:45:51] <bcoudurier> but peloverde if you feel it will be cleaner and simpler through a parser or demuxer, that's fine :)
[19:48:51] <peloverde> It belongs in a demuxer, there are too many ways we generate illegal streams or refuse to do legal simple things with just ADTS and ASC as first class AAC formats, not to mention that it is a codec agnostic intermediate format
[19:49:08] <peloverde> And it is used in the wild with things other than AAC
[19:49:19] <peloverde> like BSAC in T-DMB
[19:58:00] <mru> oi
[19:58:08] <mru> oops
[19:58:21] <mru> damn android softkbd
[19:58:44] <peloverde> Is icl on windows a supported platform?
[19:58:51] <mru> no
[19:59:01] <mru> it emulates msvc
[19:59:46] <peloverde> Then why are people complaining that the AAC decoder causes heap corruption using it?
[20:00:41] <kshishkov> selfinflicted damage?
[20:00:47] <jai> they use it at work perhaps
[20:03:42] <peloverde> Oh well, that's one SBR "bug" dealt with
[20:07:24] <mru> what are you saying?  did someone manage to compile ffmpeg with icl?
[20:08:46] <peloverde> see the AAC memory corruption thread
[20:11:42] <peloverde> Dude was complaining about memory corruption, we asked for a GDB backtrace or valgrind log, says he doesn't use GNU tools, admits to using icl on windows
[20:11:49] <mru> reading it now
[20:37:13] <BBB> peloverde: did you run it under valgrind? just to make sure
[20:37:28] <peloverde> BBB: yes I did run under valgrind
[20:37:33] <BBB> ok
[20:38:01] <peloverde> In fact I've run it extensively under valgrind. I've even fuzzed it under valgrind.
[20:39:35] <BBB> that's pretty awesoe
[20:40:10] <ramiro> pavel pavlov has a badly hacked up ffmpeg to build with icl
[20:40:19] <ramiro> he started a couple of threads last year about it.
[20:41:00] <peloverde> I believe some of the google people have expressed vague interest in ffmpeg+icl
[20:41:53] <twnqx> expect more such reports with gcc 4.5 :P
[20:45:44] <ramiro> http://gcc.gnu.org/ml/gcc/2010-03/msg00155.html
[20:45:51] <ramiro> nice way to "fix" a bug. downgrade it to p2...
[20:46:21] <peloverde> I was about to paste that
[20:46:35] <DonDiego> icl?
[20:46:39] <mru> hmm, archive reckons mr pavlov is mostly clueless
[20:46:46] <mru> DonDiego: intel compiler for windows
[20:46:55] <mru> msvc compiler is cl.exe
[20:47:03] <DonDiego> ah, thx
[20:47:41] <elenril> wtf
[20:47:53] <elenril> all these uses of start_time in ffmpeg.c look horribly wrong
[20:49:17] <elenril> anyone knows how it's supposed to work?
[20:49:24] <mru> no
[20:50:01] * elenril git blames
[20:54:15] <elenril> hmm and apparrently it's been wrong since at least 2003
[20:55:08] <mru> that's plenty enough time for reality to adapt
[20:58:09] <pJok> if it has been wrong for so long, it must be right ;)
[20:59:18] <elenril> start_time is set to 0 after opt_input_file()
[20:59:36] <elenril> but it's used in av_encode() and output_packet()
[20:59:44] * elenril sighs
[21:00:02] <elenril> and i just wanted to copy chapters, not uncover sceletons in ffmpeg's closet
[21:00:31] <pJok> you should have knocked before you opened up
[21:02:26] <bcoudurier> yes
[21:02:51] <bcoudurier> start_time has different behaviour whether is before -i or after -i
[21:03:10] <mru> self-modifying semantics
[21:03:53] <elenril> as in it's not a bug, it's an undocumented feature?
[21:05:20] <elenril> what does -ss mean for an output file then?
[21:08:09] <mru> nothing I suppose
[21:14:03] <elenril> well either it's been wrong for 7+ years or it has some hidden meaning
[21:14:08] * elenril hopes it's the latter
[21:15:07] <Kovensky> if it's the former it will make for some fun ML discussion
[21:15:10] <Kovensky> fflames :D
[21:16:05] * twnqx sets kovensky on fire
[21:18:54] * Kovensky burns
[21:20:54] * twnqx tries to extinguish the flames with some Cachasa
[21:21:18] <Kovensky> cachaça*
[21:21:59] <twnqx> i lack that key :X
[21:22:15] <mru> copy&paste
[21:22:22] <twnqx> ç
[21:22:24] <twnqx> ¢
[21:22:25] <twnqx> ©
[21:22:27] <twnqx> hm
[21:23:11] <twnqx> ẞß
[21:23:20] <twnqx> weird, two of those...
[21:29:35] <J_Darnley> Um... I can tell you what -ss does for an output file.
[21:30:32] <elenril> so?
[21:31:34] <J_Darnley> It appears to tell the encoder to wait TIME before encoding the first frame
[21:34:00] <elenril> hmmm, yeah, it seems you're right
[21:34:21] * elenril headdesks
[21:34:26] <elenril> why does it have to be so complicated
[21:35:08] <J_Darnley> People have complained in the past that using -ss "makes ffmpeg slow"
[21:35:21] <J_Darnley> but that is because it was after -i
[21:40:53] <elenril> i hope -t doesn't have any hidden meanings
[21:47:53] * elenril wondes how do -ss'es before and after -i combine
[21:53:58] <J_Darnley> Add probably