[FFmpeg-devel-irc] IRC log for 2010-07-14

[irc at mansr.com]

[00:03:00] <lu_zero> doing
[00:05:24] <lu_zero> http://ffmpeg.pastebin.ca/1900165
[00:05:33] <lu_zero> hi mchinen_
[00:05:47] <mchinen_> hey
[00:06:34] <mchinen_> what's jason ruggle's handle?
[00:07:16] <kierank> jbr or jbruggles
[00:09:12] <mchinen> there was a flac parser patch from him posted to the ml in march 2009 that never got committed, anyone hear more about this?
[00:10:06] <lu_zero> uhm interesting vlc wiki disappeared
[00:10:14] <hyc> what kind of overflow is this talking about? [msmpeg4 @ 0x30f6770] ignoring overflow at 17 8
[00:10:38] <hyc> and since it was logged in red, should I also ignore it or not?
[00:12:30] <lu_zero> Honoome: managed to reproduce it?
[00:12:47] <Honoome> lu_zero: give me a sec I'm sending out a bunch of bug reports
[00:13:53] <lu_zero> ok
[00:21:38] <saintdev> peloverde: can you have a long_stop followed by a long_start?
[00:21:55] <peloverde> yes
[00:22:28] <saintdev> ok, so you don't have to have a short between the two (i realize i have them reversed :P)
[00:22:50] <peloverde> START STOP is also legal but probably stupid
[00:26:17] <saintdev> yeah, that's what i meant
[00:33:54] <j0sh> is it just me, or is wireshark like, really, REALLY bad at tracing rtmp packets?
[00:36:21] <Honoome> j0sh: define that?
[00:50:18] <j0sh> Honoome: half the time it doesn't decode packets properly
[00:50:33] <Honoome> maybe the dissector is incomplete
[00:50:47] <j0sh> gets messed up in the middle of strings (double-S'es), which throws off everything
[00:51:31] <j0sh> and it doesn't properly mark all rtmp packets as such, which took me a looooong time to realize when i was filtering
[00:52:12] <hyc> yeah, wireshark's rtmp decoder sucks
[00:53:04] <j0sh> hyc: how feasible do youthink it would be to use librtmp in an evented server
[00:55:03] <j0sh> i'm using it right now and it's blocking on reads, but i don't know if it's just because my server implementation is incomplete
[01:01:26] <Honoome> j0sh: can I make use of your better knowledge of rtsp in ffmpeg? :)
[01:02:07] <j0sh> Honoome: yeah i really shoould get back on that. havent done any gsoc work in like, a week
[01:02:39] <Honoome> don't worry, it shouldn't be much about that ;)
[01:03:05] <Honoome> Luca found that the start time for rtsp stream get set negative
[01:03:48] <j0sh> ah
[01:03:57] <j0sh> hope it wasn't something i broke, heh
[01:03:59] <Honoome> he tracked it down to av_update_streams_timing, I tracked it down to update_initial_timestamps further
[01:13:18] <bgentry> hi everyone... I understand there is work underway for ffmpeg to handle generic downmixing, i.e. allowing AAC 6ch => AAC 2ch using the built-in ffaac decoder ?
[01:15:32] <Honoome> j0sh: where is the packet_buffer set? rtsp?
[01:18:48] <peloverde> bgentry: yes, but that will occur outside of the AAC decoder but still inside FFmpeg
[01:19:25] <bgentry> peloverde: yes, that's what I was wondering.. as of right now, I can accomplish that downmix using libfaad in an old ffmpeg build but not with the newest trunk builds
[01:20:08] <peloverde> There is a generic remixing/resampling interface being discussed
[01:20:10] <j0sh> Honoome: packet buffer?
[01:20:31] <bgentry> peloverde: still pretty far off though?
[01:21:01] <peloverde> yes it's still kind of far off
[01:21:17] <Honoome> j0sh: okay tracked it down a bit further: finalize_packet into rtpdec.c, sets the pts to -115 and -119
[01:21:30] <peloverde> in the interim you can pipe ffmpeg output to sox to remix and then back to ffmpeg to encode (ugly, i know)
[01:21:43] <kierank> mplayer has a downmixer iirc
[01:22:09] <Honoome> delta_timestamp is negative
[01:22:47] <j0sh> under what conditions?
[01:23:22] <Honoome> seems like always at the start of the run
[01:23:37] <Honoome> http://ffmpeg.pastebin.ca/1900165 and see query
[01:23:55] <j0sh> for all codecs?
[01:24:08] <Honoome> that's a good question
[01:24:38] <j0sh> Honoome: brb, gotta go eat
[01:25:32] <bgentry> peloverde: any reason i shouldn't use libfaad for that purpose?
[01:27:41] <peloverde> Libfaad is slow, you are required to figure out the actual channel count on your own since it upmixes mono to stereo by default, libfaad is less conformant, libfaad does not support some complicated multichannel scenarios at all (not just remixing wise)
[01:28:44] <bgentry> those are good reasons =)
[01:28:59] <bgentry> not familiar with sox but i will try and figure that out
[01:29:09] <Honoome> okay it seems like we've got a problem either sending rtcp or decoding rtcp
[01:45:24] <peloverde> I really wish 26.403 had a theory section
[01:46:21] <Honoome> I really wish that they didn't call it Normal Play Time since the NPT vs NTP mistakes are present even in the RFC2326 itself
[02:46:47] <peloverde> I think I found a bug, and it is more rewarding than /.
[02:47:42] <saintd3v> peloverde: is tns part of lc, or just main?
[02:47:47] <peloverde> LC
[02:48:11] <peloverde> Why all the interest in AAC all of the sudden?
[02:48:21] <saintd3v> why not? :P
[03:02:05] <peloverde> Does anyone who knows psy know why end up averaging adjacent barks?
[03:03:10] <Dark_Shikari> "why end up averaging"
[03:03:13] <Dark_Shikari> what I can't parse that sentence
[03:03:30] <peloverde> why we
[03:03:39] <peloverde> Does anyone who knows psy know why we end up averaging adjacent barks?
[03:04:13] <Dark_Shikari> averaging what in the adjacent barks?
[03:05:47] <peloverde> Averaging like a smoothing filter
[03:06:12] <peloverde> We calculate barks with "13.3f * atanf(0.00076f * f) + 3.5f * atanf((f / 7500.0f) * (f / 7500.0f))" which I understand
[03:06:53] <Dark_Shikari> averaging WHAT
[03:06:56] <Dark_Shikari> averaging... weights?
[03:06:58] <Dark_Shikari> averaging... energies?
[03:07:07] <Dark_Shikari> averaging... numbers of G20 protestors?
[03:07:19] <peloverde> jesus give me a second, I'm trying to think this through
[03:07:57] <peloverde> coeffs->barks[g] = (barks[i - 1] + prev) / 2.0
[03:08:05] <peloverde> prev = barks[i - 1]
[03:08:17] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/aacpsy.c;h=466b0e9a1a737ac3afa8571fa5b7c4c83d498ea8;hb=HEAD#l124
[03:09:10] <Dark_Shikari> a lowpass filter over the barks I guess?
[03:09:18] <peloverde> yes, why?
[03:10:08] <peloverde> And why do we use the same scale for short and long windows such that the top long sfb is in bark 25 and the top short sfb is only in bark 14
[03:10:26] <Dark_Shikari> ask the person who wrote it
[04:09:28] * peloverde glares angrily at git-svn
[04:11:08] <peloverde> It worked!
[04:11:22] <CIA-99> ffmpeg: alexc * r24230 /trunk/libavcodec/aacpsy.c: aacenc: psy_3gpp_init(): Calculate barks on demand.
[04:11:23] <CIA-99> ffmpeg: alexc * r24231 /trunk/libavcodec/aacpsy.c:
[04:11:23] <CIA-99> ffmpeg: aacenc: psy_3gpp_init(): Fix ath for the first line in each sfb.
[04:11:23] <CIA-99> ffmpeg: Fix the MDCT line to frequency calculation for the first line in each sfb.
[04:11:23] <CIA-99> ffmpeg: Use this value to calculate ATH.
[04:11:24] <CIA-99> ffmpeg: alexc * r24232 /trunk/libavcodec/aacpsy.c: aacenc: aac_psy_init(): Factorize line_to_frequency.
[04:11:25] <CIA-99> ffmpeg: alexc * r24233 /trunk/libavcodec/aacpsy.c: aacenc: psy_3gpp_init(): Fix line_to_frequency for short windows.
[04:20:45] <peloverde> And my reward is that I get to move on to this wonderful artifact: http://i.imgur.com/jlLF4.png
[04:21:16] <saintdev> oh wow, lol
[07:09:04] <peloverde> wow, that bug might actually be in the TLS
[07:09:26] <kshishkov> TLS as in secure sockets?
[07:09:36] <peloverde> TLS as in two loop search
[07:09:41] <peloverde> search_for_quantizers_twoloop()
[07:09:59] <kshishkov> ah, MPEG-2 NBC model
[07:10:30] <peloverde> which means in this case psy is behaving
[07:11:30] <kshishkov> behaving how?
[07:11:41] * kshishkov fears to hear "behaving properly"
[07:12:08] <peloverde> Like not using long window line to bark conversions for short windows?
[07:44:03] <av500> peloverde: "Firefogg is build using ffmpeg2theora and FFmpeg"
[07:44:12] <av500> not "built"?
[07:44:42] <peloverde> close enough
[07:46:24] * Honoome hates on the rtp/rtsp specs!
[07:47:01] <kshishkov> Honoome: please give some hate to RTMP specs as well
[07:47:18] <Honoome> kshishkov: do they juggle between NTP and NPT as name for timestamps as well?
[07:48:02] <kshishkov> Honoome: no, but good luck figuring out timestamps there at all
[07:48:12] <mru> why stop there?  you could have PNT, PTN, TNP, TPN, ...
[07:48:20] <Honoome> rfc2326 sometimes mistypes NPT in NTP
[07:48:28] <mru> send them some TNT
[07:48:30] <av500> NPN, PNP
[07:48:42] <mru> NMOS
[07:48:53] <av500> ECL?
[07:48:55] <peloverde> JFET
[07:49:02] <av500> tubes
[07:49:04] <mru> IGBT
[07:49:14] <kshishkov> CRT
[07:49:19] <mru> LGBT?
[07:49:30] <av500> YGBKM
[07:49:30] <kshishkov> sounds like PRNG
[07:50:33] <saintdev> AES
[07:50:44] <av500> triple rot13
[07:51:12] <mru> but make sure to do the second rot13 _anticlockwise_
[07:51:16] <mru> otherwise it doesn't work
[07:51:31] <av500> of course, and we run it twice for extra security
[07:52:01] <cartman> LGTM
[07:52:01] <kshishkov> New Optimized Permutation
[07:52:32] <mru> LMGTFY
[07:52:39] <av500> HDMITX_CALLBACK_INT_EDID_BLK_READ
[07:52:54] * kshishkov once was responsible to know all abbreviations
[07:53:25] <kshishkov> still better than remember all function graphics
[07:53:54] <saintdev> av500: ECB 3-ROT13?
[07:54:09] <av500> psst...
[07:54:49] <saintdev> CBC then?
[07:55:06] <mru> CDC
[07:55:19] <kshishkov> DEC FTW
[07:55:26] <av500> the computer or the diseace control?
[07:55:34] <av500> c->s
[07:56:24] * kshishkov looks at channel name - #medicine-sanitary
[07:56:32] <kshishkov> yep, disease control
[07:56:47] <twice11> how do you do CBC on ROT13? add letter numbers?
[07:57:02] <mru> PDP
[07:57:13] <kshishkov> VAX
[07:57:14] <mru> or number the letters
[07:58:55] <kshishkov> romans managed that without numbers
[07:59:05] <kshishkov> heck, they even wrote numbers with letters
[07:59:22] <kshishkov> (as many other ancient civilisations)
[07:59:47] <av500> kshishkov: they used tricks: http://www.phy6.org/outreach/edu/roman.htm
[08:00:02] <jai> hmm, so animated gifs no longer work
[08:00:03] <lu_zero> wbs: I cannot find your patch about rtp-info
[08:00:21] <mru> http://img.thedailywtf.com/images/mark/errord/062510/china.png
[08:00:46] <mru> jai: animated gifs never worked, they always made you look like an idiot
[08:01:15] <kshishkov> mru: but they ate trafic well on dialup, don't forget that
[08:01:39] <jai> mru: well, atleast with olf ff*
[08:01:45] <jai> seems like a regression
[08:01:48] <jai> :)
[08:02:41] <wbs> lu_zero: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086465.html
[08:03:24] <mru> http://www.textfiles.com/underconstruction/
[08:04:40] <av500> down for me
[08:05:01] <mru> yeah, but you know what's there
[08:05:20] <av500> http://webcache.googleusercontent.com/search?q=cache:2CaH_Hho520J:www.textfiles.com/underconstruction/+http://www.textfiles.com/underconstruction/&cd=1&hl=de&ct=clnk&gl=de
[08:05:47] <av500> all urls broken too
[08:07:03] <lu_zero> wbs: they might be _quite_ useful now =)
[08:07:23] <av500> ahh, it loads! \\\ooo///
[08:07:37] <wbs> lu_zero: oh, good. :-)
[08:11:00] <Honoome> wbs: read that as luca wanted me to debug an issue last night that was caused by lacking those :P
[08:11:11] <wbs> Honoome: hah :-)
[08:11:50] <av500> lol: "How come you know so much about Assembly? have you been coding Amiga demos or games?"
[08:11:59] <av500> Dark_Shikari: admit it!
[08:14:02] <Dark_Shikari> av500: lol
[08:14:11] <lu_zero> wbs: ok the last two patches fixed a problem
[08:14:47] <lu_zero> after fixing skip_spaces they could go in
[08:14:47] <wbs> oh, nice
[08:15:27] <wbs> iirc they were a bit ugly in some sense (storing a huge amount of parsing buffers in the rtsp context or something), but if you and BBB are ok with it
[08:15:47] <wbs> I think I'd want to reread the patches yet before applying them, it's a while since I wrote them :-)
[08:16:00] * lu_zero now should try to understand yet another strange issue
[08:26:55] * j0sh waves at wbs and lu_zero
[08:27:25] <wbs> j0sh: where's the updated qdm2 patch? :-)
[08:27:38] <j0sh> aye, i know :(
[08:28:02] <j0sh> ah, most of the changes you asked for were minor, let me do it right now
[08:28:17] <wbs> shouldn't be much left on that, I'll apply the patches I sent at latest when the rest is cleared up
[08:28:19] <wbs> yeah
[08:28:29] <lu_zero> =)
[08:28:31] <lu_zero> brb
[08:29:33] <wbs> j0sh: and as next task, the qt depacketizer could be quite interesting, but probably also a bit messy. doing one or a few packetizers instead, so you get to write new code instead of just polishing up old things, is totally ok with me, too
[08:30:16] <wbs> j0sh: but packetizers usually need to be ok'd by luca abeni, too, but I can review them to work out the initial details at least
[08:30:34] <j0sh> wbs: ok, sounds good
[08:30:53] <j0sh> would be nice to write some new code, so i'll do a packetizer
[08:31:18] <wbs> as long as we get the qt depacketizer within the soc schedule, it's ok with me :-)
[08:31:35] <j0sh> heh, alright
[08:31:43] <j0sh> what exactly is preventing it from being committed in its current form?
[08:31:56] <wbs> no idea, I've never read it through
[08:32:17] <j0sh> alright
[09:42:09] <Dark_Shikari> LOL @ michael's newest email
[09:42:23] <ohsix> url
[09:43:12] <Dark_Shikari> Re: [FFmpeg-devel] [FFmpeg-devel-irc] IRC log for 2010-07-09
[09:43:16] <Dark_Shikari> > [02:21:11] <saintdev> i vote pi = 2*C/D
[09:43:17] <Dark_Shikari> C=acos(0)
[09:43:17] <Dark_Shikari> D=1
[09:43:32] <ohsix> nice
[09:44:23] <av500> #define C (acos(0)), no?
[09:49:37] <kshishkov> C=atan(1) and D=0.5 will also work fine
[09:50:50] <av500> now find all possible solutions
[09:51:07] <av500> I just found them, but place to write it down....
[09:52:04] <twice11> ...the margin here is too small?
[09:52:09] <av500> yeah
[09:52:12] <kshishkov> there are infinite number of them
[09:52:32] <av500> see :)
[09:53:20] * kshishkov likes Euler's formula
[09:53:45] <thresh> sounds like facebook to me!
[09:54:02] <kshishkov> OK, back to trolling
[10:15:11] <Honoome> hm faad is gone, right?
[10:15:33] <Honoome> so we no longer upmix mono <22khz?
[10:15:45] <mru> gone, removed, exiled, banished...
[10:16:42] <Honoome> patch coming
[10:28:13] <j0sh> wbs: qdm2 patch sent, i was scratching my head over that NOTS thing for a while
[10:29:01] * janneg fährt meist nur 230km/h mit ICE, die Klimaanlage im verspätete n ICE samstagmittag war auch am rande ihrer kapazität
[10:29:12] <janneg> upps
[10:29:16] <j0sh> its 3:30am here, so my logic is probably strained
[10:30:27] <av500> janneg: you goot cooked too?
[10:31:13] <Honoome> j0sh: don't worry about the thing last night (when it was _my_ 3.30 :P), it was lu_zero who forgot some patches
[10:31:57] <kshishkov> av500: next time you travel by train, take some dill with you - should give you better look
[10:32:27] <av500> kshishkov: I only travel by train in extremely mild weather
[10:32:28] <janneg> not really, it was ok in the cabin, but not enough to cool the parts between the coaches and at the doors
[10:34:27] <janneg> the train had almost an hour delay because the original driver had a "hitzschlag"
[10:34:33] <av500> lol
[10:34:37] <kshishkov> better than Ukrainian "express" - you are not allowed to open windows and no noticeable ventilation in carriages
[10:35:36] <av500> janneg: i guess they need to stock fresh drivers at all stations, like the pony express
[10:35:38] <pross-au> Anyone watch the trans-siberian train video on google.ru ?
[10:35:52] <av500> still watching it
[10:36:14] <pross-au> Cool
[10:36:44] <kshishkov> IIRC it takes a week to go from Moscow to Valdivostok by train
[10:36:54] <kshishkov> and it was usually late by several days
[10:37:12] <kshishkov> beat that, Deutsche Bahn!
[10:37:13] <av500> make it late 7 days and its back on time
[10:37:26] <janneg> av500: I think it was a fresh driver and he didn't made it to the train
[10:38:07] <av500> "..Dear passengers, we have removed the dead driver, train starting any minute..."
[10:39:47] <thresh> kshishkov: you cant buy a ticket from Moscow to Vladivostok
[10:40:07] <thresh> well turns out I'm wrong
[10:40:28] <av500> in soviet russia, ticket buys you....
[10:41:07] <j0sh> Honoome: no worries, i noticed your patch on -devel, glad u were able to track it down
[10:41:09] <thresh> a couple of years ago, you couldnt buy a direct ticket, you would have a couple of transfers here and there
[10:41:39] <thresh> but who in his sane mind would want to travel that far by train anyway
[10:41:41] <Honoome> j0sh: that wasn't much of the issue, missing rtp-info was the problem :P wbs already sent a patch
[10:41:50] <av500> thresh: ash cloud!
[10:42:43] <pross-au> thresh: train lovers
[10:43:18] <mru> the ash cloud is a conspiracy by the train lovers
[10:43:27] <thresh> pross-au: seems like you never tried to travel in russian trains ;-)
[10:43:46] <mru> the love in strong in some people...
[10:43:49] <thresh> most of those do not have air conditioning, not telling about bio toilets
[10:43:52] <thresh> talking
[10:43:56] <kshishkov> thresh: ukrainian ones are reported to be in slightly worse conditions anyway
[10:44:02] <pross-au> we're got our own public transport mess here
[10:44:29] <thresh> my friends are now in a 24h long trip on a train and it's +35 outside
[10:44:42] <thresh> i wonder how dead are they now
[10:44:42] <kshishkov> thresh: dumping all shit ontol rail tracks is not considered "bio" anymore?
[10:45:47] <mru> death is boolean
[10:45:48] <kshishkov> thresh: форточки!
[10:46:03] <kshishkov> mru: not for Norwegian Blue parrots
[10:46:03] <mru> hmm, that has a nice ring to it
[10:46:12] <mru> yeah, for them it's tristate
[10:47:23] <Honoome> guh?
[10:47:36] <kshishkov> dead/not dead/just resting
[10:47:56] <Honoome> HE? o_O
[10:48:13] <pross-au> 35degC sounds nice
[10:48:23] <Honoome> pross-au: if you're a salamader
[10:48:26] <mru> pross-au: only compared to 45
[10:48:53] <pross-au> Compared to 12
[10:49:01] <Honoome> compared to 12 I still prefer 12
[10:49:12] <mru> is 25 not an option?
[10:49:14] <pross-au> Eek, that's the middle of winter
[10:49:28] <Honoome> you can cover youself up from cold, it's difficult to strip further after being naked
[10:49:28] <mru> pross-au: where you are it _is_ middle of winter
[10:49:34] <pross-au> Nods
[10:50:07] <mru> Honoome: heat has some nice side-effects
[10:50:12] <Honoome> such as?
[10:50:13] <kshishkov> Honoome: but like with debts you can shift heat somewhere else with some manipulations
[10:50:14] <mru> like bringing out some skin in the girls
[10:50:26] <Honoome> mru: that only works if you have girls around
[10:52:33] <mru> Honoome: there are always some girls around
[10:52:41] <mru> well, not in the office...
[10:53:01] <kshishkov> expand your range for "around", there's main street not so far away
[10:53:25] * Honoome lives lost in the middle of fields
[10:53:39] <av500> nature girls...
[10:54:17] <mru> kshishkov: so where are the x-ray goggles?
[10:55:38] <kshishkov> mru: with my sight it makes no difference
[10:56:36] <pross-au> You have built in x-ray vision kshishkov? Whoa.
[10:57:17] <kshishkov> pross-au: nope
[10:57:22] <wbs> j0sh: yes, go get some sleep already. ;P this needs yet another round, but there shouldn't be much left
[11:14:03] <KotH> av500: ping
[11:27:00] <av500> plong
[11:28:04] <av500> KotH: ^^^
[11:41:08] <lu_zero> plang?
[11:41:49] <mru> clang?
[11:41:51] <Honoome> lu_zero: check my patch on -devel :P
[11:41:56] <Honoome> mru: sunstudio
[11:43:31] <lu_zero> Honoome: sure
[11:44:00] * lu_zero it is a the top-ix looking at a strange kernel fault (.32) 
[11:48:33] <lu_zero> bbl
[12:27:10] <CIA-99> ffmpeg: mstorsjo * r24234 /trunk/libavformat/ (rtpdec.h rtpdec.c): rtpdec: Allow depacketizers to specify that pkt->pts should be left as AV_NOPTS_VALUE
[12:28:23] <CIA-99> ffmpeg: mstorsjo * r24235 /trunk/libavformat/rtpdec_svq3.c:
[12:28:23] <CIA-99> ffmpeg: rtpdec_svq3: Return the timestamp in *timestamp instead of pkt->pts
[12:28:23] <CIA-99> ffmpeg: The timestamp of the first RTP packet forming the output AVPacket is
[12:28:23] <CIA-99> ffmpeg: written back in *timestamp, which is used in later calculations in generic
[12:28:23] <CIA-99> ffmpeg: rtpdec code (together with RTCP sync timestamps) to form the final pkt->pts
[12:28:23] <CIA-99> ffmpeg: value.
[12:32:50] <CIA-99> ffmpeg: mstorsjo * r24236 /trunk/ (5 files in 2 dirs):
[12:32:50] <CIA-99> ffmpeg: Add a depacketizer for QDM2
[12:32:50] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail, original code
[12:32:50] <CIA-99> ffmpeg: by Ronald S Bultje.
[12:37:24] <tborg> Thanks, Dark_Shikari, I found the conversion!
[12:39:22] <tborg> oh wrong chat...
[13:13:17] <CIA-99> ffmpeg: diego * r24237 /trunk/libavcodec/ (escape124.c fraps.c rl2.c):
[13:13:17] <CIA-99> ffmpeg: Remove incomplete Doxygen for static decode_frame functions.
[13:13:17] <CIA-99> ffmpeg: These functions are not documented for other decoders and
[13:13:17] <CIA-99> ffmpeg: should be obvious enough even without Doxygen.
[13:13:17] <CIA-99> ffmpeg: patch by Thilo Borgmann, thilo.borgmann googlemail com
[14:17:29] <zap0> hello, i was wondering why  codec  r210  (Uncompressed RGB 10 bit)   had a decoder, but no encoder?
[14:18:14] <av500> nobody wrote one?
[14:18:26] <zap0> i know its simple, but im having trouble understanding the pixel packing from the decoder source, can someone look at it, and perhaps explain it.
[14:18:43] <zap0> its in  f210dec.c
[14:19:13] <zap0> oops..  r210dec.c
[14:19:37] <elenril> http://archives.free.net.ph/message/20091216.211852.836d2ff2.fi.html
[14:20:43] * elenril wonders if google is down today =p
[14:24:22] <zap0> elenril, the source code i downloaded is more recent, and is different.
[14:25:31] * zap0 wonders if elenril is stuck in some 6month old time warp :p
[14:30:42] * elenril sighs
[14:30:55] <elenril> note the link to http://samples.mplayerhq.hu/V-codecs/R210/
[14:30:59] <elenril> which contains some docs
[14:35:24] <av500> ...Three 10-bit unsigned components are packed into one 32-bit big-endian word...
[14:35:55] <av500> sounds hellishly complicated
[14:37:07] <kierank> av500: needs a massive bikeshed thread to decide what to do
[14:37:25] <kierank> and an r210 task force
[14:37:36] <jai> and a task force co-ordinator
[14:37:52] <kshishkov> yep, form a comittee
[14:38:06] <jai> ohloh says ffmpeg has a manager, thats convenient
[14:38:32] <mru> loloh
[14:41:28] <kshishkov> told you, in Russian "oh loh" means "aww, (what the) sucker"
[14:43:04] * kshishkov asks if the position of FFmpeg VP on fringe codecs is still open
[14:43:39] <lu_zero> kshishkov: =)
[14:46:43] <zap0> elenril, thanks.
[16:20:57] <funman> hi
[16:21:07] <mru> lo
[16:21:18] <jai> sup funman
[16:22:17] <funman> having a pastis, hacking a demuxer
[16:22:30] <mru> fixed-point demuxer?
[16:22:52] * funman feels confused
[16:23:11] <mru> aren't you the fixed-point guy?
[16:23:13] <funman> there a floating-point ones?
[16:23:15] <funman> no
[16:23:47] <mru> irc says you are: funman [~fun at rockbox/developer/funman]
[16:24:19] <funman> i do mostly reverse engineering in rockbox, nothing with codecs/formats
[16:25:05] <elenril> how big is a performance hit with hw-accelerated virtualization?
[16:25:12] <funman> our codecs guys include saratoga, mt, buschel, stripwax ..
[16:25:39] * elenril wonders if he should virtualize a proper os here instead of dealing with windoze
[16:25:53] <av500> what performance is there to lose then?
[16:28:08] <funman> i wanted to give a try to a demuxer for a (very) simple format : the lego mindstorm RSO, which is raw PCM after a fixed header
[16:28:32] <funman> and i wonder if libavformat/raw.c is the right place for this
[16:28:51] <jai> funman: yeah, should be fine i think
[16:28:53] <mru> copy .wav or .au demuxer and modify
[16:29:13] <mru> .au is probably the simplest
[16:29:24] <funman> all the formats i see are raw variants of some codec, and all the PCM ones have no headers so i would think a new file is needed
[16:29:41] <funman> but the file says "/* simple formats */" so i'm also tempted to add it there
[16:29:53] <mru> where is the .au demuxer?
[16:30:06] <funman> au.c
[16:30:28] <mru> it probably uses read/write/seek functions from raw.c though
[16:31:53] <funman> seek but not read (not sure why)
[16:48:01] <Tjoppen> funman: generalize some of the code in the .wav demuxer so they both can share code?
[16:50:12] <funman> Tjoppen: raw.c alreayd has generic code
[16:55:04] <elenril> if i'm running 32bit windoze on a 64bit cpu, can virtualized oses be 64bit?
[16:55:41] <mru> probably not with vmware workstation/server or virtualbox
[16:55:54] <elenril> :(
[16:55:56] <mru> with xen or vmware esx server it's of course possible
[16:56:03] * elenril is using virtualbox
[16:56:05] <mru> since those sit outside the os
[16:56:15] <elenril> but those are a PITA to setup, no?
[16:56:20] <mru> probably
[16:56:24] <mru> never tried
[16:56:31] <mru> didn't get past the first page of the manual
[16:56:41] <mru> so yes, actually
[16:58:52] <elenril> VMM: fixed host crash when running 64-bit guests on 32-bit hosts << from virtualbox changelog
[16:59:01] <elenril> i guess it works then :)
[16:59:12] <mru> wow
[16:59:16] <funman> if it crashes, it works!
[16:59:20] <mru> I didn't expect that
[17:07:11] <funman> would you recognize which adpcm is used by looking at the pascal source code for the encoder?
[17:07:28] <mru> compare to ours
[17:07:38] <mru> or feed the encoded file to all of ours and see which sounds right
[17:08:39] <funman> i have no encoded file
[17:08:48] <funman> the thing builds in borland delphi iiuc
[17:21:48] <bcoudurier> pastis ?
[17:21:52] <bcoudurier> are you french ?
[17:22:25] <funman> yes
[17:22:53] <av500> not pernod?
[17:22:55] <kshishkov> funman: yes, we will. Even i know Pascal
[17:24:36] <kshishkov> and ADPCM encoder contains decoder anyway
[17:25:50] <funman> kshishkov: http://pastie.org/1044327
[17:25:57] <funman> av500: you mean ricard?
[17:26:19] <jai> hmm, i have only seen a bottle of pastis once
[17:26:26] <jai> pretty rare to come across one here
[17:26:35] <funman> where are you?
[17:26:41] <kshishkov> funman; from the first quick glance - IMA ADPCM
[17:26:48] <jai> funman: je suis indien
[17:26:56] <funman> kshishkov: well the function name told me that already ;)
[17:27:18] <jai> heh
[17:28:04] <funman> listening test is quite hard: encoded data is limited to 16kB
[17:28:14] <kshishkov> funman: looks like plain IMA ADPCM without any deviations from the standard
[17:28:44] <funman> err, 64kB (1<<16)
[17:29:34] <CIA-99> ffmpeg: reimar * r24238 /trunk/ (libavcodec/dvbsubdec.c libavformat/mpegts.c):
[17:29:35] <CIA-99> ffmpeg: Pass the composition and ancillary ID for DVB subtitles via extradata instead
[17:29:35] <CIA-99> ffmpeg: of sub_id, this allows detecting when that information is not available and
[17:29:35] <CIA-99> ffmpeg: just decode everything.
[17:29:35] <CIA-99> ffmpeg: In addition extradata is required for many codecs and thus in contrast to
[17:29:35] <CIA-99> ffmpeg: sub_id generally already passed on by any programs using libav*.
[17:29:36] <CIA-99> ffmpeg: Also ask for a sample if we encounter a stream with multiple/changing IDs.
[17:30:51] <funman> kshishkov: that'd be CODEC_ID_ADPCM_IMA_WAV? this one doesn't like the bitstream
[17:31:38] <kshishkov> yes, it looks so - but this codec also should store initial step and predictor
[17:32:08] <funman> ah so it needs them from demuxer?
[17:32:09] <kshishkov> in that detail it may differ - and your snippet gives no details on that
[17:32:21] <kshishkov> actually its written in bitstream in some way
[17:33:03] <funman> reload the paste, i pasted the full file
[17:33:43] <funman> hm i see a .wav id for IMA_ADPCM in this file
[17:34:36] <funman> that's CODEC_ID_ADPCM_IMA_WAV ($0011)
[17:36:50] <kshishkov> hmm, here it step=predictor=0 and raw ADPCM data
[17:37:19] <kshishkov> ADPCM_IMA_WAV expects predictor and step coded at the beginning IIRC, hence the difference
[17:47:29] <funman> predictor = step_index = 0 gives me silent output
[17:48:12] <funman> do you want a sample?
[17:49:01] <kshishkov> yes
[17:49:27] <kshishkov> I'll deal with this in 10 mins or so
[17:52:54] <kshishkov> and remember - step = step table index, so actual step >= 1
[17:54:35] <funman> kshishkov: http://pastie.org/1044366 (WAV) http://pastie.org/1044367 (RAW ADPCM). base64 encoded, 8kHz 1 channel
[17:56:23] <funman> mru: here comes a fixed-point guy :)
[18:31:23] <kshishkov> looks more like raw indeed
[19:00:39] <Compn> oh, encoding question
[19:01:30] <Compn> say i'm capping at 720:480 and cropping to 716:486 or so, would it be worth it to rescale to 720:480 to get the 16x16 ? or would rescaling introduce more problems than non-16 res ?
[19:01:44] <Compn> er cropping to 476
[19:37:04] <CIA-99> ffmpeg: aurel * r24239 /trunk/libavformat/matroskaenc.c:
[19:37:04] <CIA-99> ffmpeg: matroskaenc: write DisplayUnit element to better match the spec
[19:37:04] <CIA-99> ffmpeg: This makes it clear that we are specifying the aspect ratio, and not
[19:37:04] <CIA-99> ffmpeg: the intended display size in pixels.
[19:50:59] <CIA-99> ffmpeg: rbultje * r24240 /trunk/MAINTAINERS: Add myself as mmst maintainer.
[19:57:56] <lu_zero> hi
[19:58:53] <spaam> hi
[20:14:30] <Dark_Shikari> >lego mindstorms demuxer
[20:14:32] <Dark_Shikari> oh wow.
[20:17:35] * _av500_ waits for a demuxer for those cards that played "happy birthday" in the 80's
[20:18:46] <funman> Dark_Shikari: serious business
[20:22:21] <BBB> jai: does vlc have an online viewgit webpage somewhere?
[20:23:15] <mru> it should
[20:26:17] <BBB> nm found it
[20:26:22] <BBB> well hidden
[20:26:34] <funman> 'git.videolan.org' , can't make it more obvious
[20:27:36] <jai> BBB: ^
[20:27:49] <BBB> how do I know they use git :-p
[20:28:24] <Honoome> funman: he's used to the cvs/svn viewvc stuff that needs to be something like videolan.org/cgi-bin/onemoredirforthesakeofit/viewvc.git/repository/trunk/vlc/whatever :P
[20:28:54] <mru> :-)
[20:28:58] <funman> shortest strings is a built in function of git (like 96067e4922878b125f86509a83c3495670bcb450 for example)
[20:29:58] * Honoome actually dislikes gitweb, but he had no time to keep on working on gitarella
[20:30:13] <mru> gitweb is better than any of the svn ones at least
[20:30:26] <Honoome> used to be much slower
[20:30:46] <spaam> cgit is nice :)
[20:31:15] <spaam> http://cgit.lighttpd.net/  in action ;D
[20:33:54] <kierank> spaam: looks basically the same
[20:38:07] <Honoome> mostly faster
[20:38:16] <Honoome> 'cause it's in C with caching rather than in perl without
[20:39:35] <mru> doesn't gitweb mostly invoke the normal git tools to do the work?
[20:39:45] <mru> caching would still help of course
[20:41:12] <Honoome> mru: it always invoked the normal git tools afaik
[20:41:41] <mru> it obviously does the html formatting in perl
[20:41:47] <mru> but that shouldn't take long
[20:42:12] <Honoome> mru: cgit does not call into git
[20:42:20] <Honoome> it uses the internal library to access the data
[20:42:58] <mru> I would've thought the whole thing was io-bound anyway
[20:43:00] <Honoome> lu_zero: can we close michael and ciaranm in a room together for a couple of months?
[20:45:19] <Honoome> they both expect the whole OS to turn around their personal needs, they both love condorcet voting, but they disagree on the language (C vs C++)... would be a nice match
[20:46:13] <mru> do you think they'd vote on it?
[20:46:38] <Honoome> or they'd end up in trollock
[20:46:45] <Honoome> [which is a deadlock of trolling]
[20:48:01] <funman> expecting the other to troll, or expecting the other to stop trolling?
[20:48:42] <Honoome> I'd expect we could have a troll-powered free energy generator
[20:50:10] <peloverde> Does roundup seem unusually slow (over the past few days) to anyone else?
[20:50:56] <mru> roundup is _always_ unusually slow
[20:52:09] <peloverde> No it's always *usually* slow
[20:52:17] <peloverde> These days it seems bugzilla slow
[21:03:43] * BBB probably fixed all mmst.c bugs he cound find today
[21:04:38] <BBB> back to simd then
[21:05:44] <mru> let's finally beat libvpx
[21:05:59] <Dark_Shikari> \o/
[21:06:05] <Dark_Shikari> did you commit the normal filter yet?
[21:06:07] <Dark_Shikari> or still more to do
[21:07:34] <BBB> I didn't address your issues raised yesterdya yet
[21:07:37] <BBB> will work on that late today
[21:07:50] <BBB> I promised my soc student to help him beat the crapshit out of mmst.c first, to make sure it always works
[21:08:05] <BBB> I sent him all stuff that was wrong, he'll fix it & commit, I'll go back to simd meanwhile :)
[21:10:55] <_av500_> ot: http://cache.gawkerassets.com/assets/images/39/2010/07/periodic_table_cursing712.jpg
[21:16:31] <funman> _av500_: it lacks duke nukem quotes, i suppose those are the heaviest elements
[21:18:34] <_av500_> the duke was not a brit, was he?
[21:21:03] <funman> don't think so
[21:21:27] <funman> is that a brit insults table? (i see the crown)
[21:22:57] <CIA-99> ffmpeg: diego * r24241 /trunk/libavcodec/ (aacadtsdec.h lsp.h ac3_parser.h): Restore mistakenly removed [in]/[out] Doxygen parameter attributes.
[21:36:28] <BBB> wma audio still crashes on my computer :(
[21:36:34] <BBB> anybody else have a problem with that?
[21:37:24] <mru> no, I don't have a problem with wma crashing your computer
[21:37:27] <funman> yeah i've a problem with people using wma
[21:40:52] <BBB> hum...
[21:43:59] <funman> BBB: just tried one file and it sounded ok
[21:44:43] <_av500_> BBB: crash how?
[21:44:53] <BBB> ff_imdct_half_sse
[21:59:14] <BBB> does wmadec.c never call ff_imdct_init()?
[22:00:42] <mru> wma regression tests pass on fate, so clearly it's not totally broken
[22:03:54] <BBB> true
[22:04:02] <BBB> it doesn't check return value of ff_mdct_init()
[22:04:15] <mru> and it's failing?
[22:06:10] <BBB> no, but the values are unallocated nevertheless
[22:06:13] <BBB> I'm trying to figure out why
[22:13:27] <BBB> damn it I need valgrind for mac
[22:13:45] <mru> no, you need a valgrind-capable computer
[22:15:19] <BBB> blegh
[22:21:42] <BBB> does anyone want to do some valgrind runs for me with custom ffmpeg patches?
[22:29:54] * BBB goes search bugzilla for g-mac-10.6 patches
[22:33:48] <bcoudurier> the 10.6 branch works
[22:33:58] <bcoudurier> somewhat
[22:34:04] <BBB> I'm testing it as we speak
[22:34:11] <BBB> should work for ffmpeg, given that that's still 32-bit
[22:34:31] <bcoudurier> huh ?
[22:34:34] <bcoudurier> you can use 64bits
[22:34:42] <bcoudurier> ./configure --enable-64bit-only worked
[22:42:09] <BBB> bcoudurier: I know it works
[22:42:15] <BBB> bcoudurier: but I don't want to mess with it yet ;)
[22:42:23] <BBB> maybe later
[22:44:52] <BBB> let's see if I should not have done this
[22:58:42] <BBB> I'm starting to think I need a make clean or so...
[22:59:21] <BBB> I suppose valgrind is quite wonderous
[23:00:05] <Dark_Shikari> itis
[23:00:24] <BBB> thank god I have a working valgrind again
[23:00:32] <BBB> one of those few tools nobody can live without
[23:22:13] <CIA-99> ffmpeg: bcoudurier * r24242 /trunk/libavformat/oggenc.c:
[23:22:13] <CIA-99> ffmpeg: In ogg muxer, use dyn buffer to compute crc of the page, fix muxing with pipe
[23:22:13] <CIA-99> ffmpeg: when page buffer is bigger than default buffer size. Max page is 65k.
[23:24:03] <Vitor1001> BBB: Did you try to reproduce your bug using -acodec copy?
[23:31:20] <Dark_Shikari> optimization puzzle
[23:31:25] <Dark_Shikari> x = {-2,32} inclusive
[23:31:29] <Dark_Shikari> y = {-2,32} inclusive
[23:31:48] <Dark_Shikari> in the fewest ops, calculate (x == 2 && y == 2)
[23:32:12] <Dark_Shikari> (x+1)&(y+1)==-1 works, but I think it might be worse than the naive way
[23:35:02] <Dark_Shikari> hmm.  newer gcc compiles if(x==2 && y==2) as
[23:35:08] <Dark_Shikari> cmp, je, cmp, je
[23:35:13] <Dark_Shikari> 3.4 compiles it branchlessly
[23:35:20] <Dark_Shikari> e.g. cmp, sete, cmp, sete, test, je
[23:35:32] <Dark_Shikari> Probably can't beat the branchy version in this case.
[23:35:55] <Dark_Shikari> Oh.  I can do if( i_refa + i_refb == -4 )
[23:36:02] <Dark_Shikari> er, x + y == -4
[23:37:08] <roxfan> did you mean (x == -2 && y == -2) then?
[23:37:25] <Dark_Shikari> er, yeah.
[23:37:29] <Dark_Shikari> stupid typo of mine.
[23:40:21] <kierank> gcc will presumably turn that into x + y + 4 then just use je?
[23:41:58] <Dark_Shikari> no
[23:42:01] <roxfan> comparing with -4 is the same as adding 4, so probably not
[23:42:10] <Dark_Shikari> it does
[23:42:15] <Dark_Shikari>      2f6:       8d 04 2e                lea    eax,[esi+ebp*1]
[23:42:16] <Dark_Shikari>      2f9:       83 f8 fc                cmp    eax,0xfffffffc
[23:42:48] <Dark_Shikari> because lea doesn't set flags
[23:42:58] <Dark_Shikari> Now what bugs me about this is
[23:43:02] <Dark_Shikari> esi and ebp are never used again in the function
[23:43:17] <Dark_Shikari> so it doesn't have to maintain them
[23:43:57] <Dark_Shikari> I'm trying to simplify if( b == -2 && c == -2 && d != -2 )
[23:44:14] <Dark_Shikari> damn, gcc loves inserting nops everywhere.
[23:44:33] <roxfan> why -2?
[23:44:39] <Dark_Shikari> -2 ---> ref isn't available
[23:44:46] <Dark_Shikari> -1 ---> ref is invalid (intra)
[23:44:50] <roxfan> hmm
[23:44:52] <Dark_Shikari> 0-32 ---> valid ref values
[23:45:14] <Dark_Shikari> i.e. "if both top mvs aren't available, predict based on left mv"
[23:45:32] <kierank> maybe you could do c xor d and then jne
[23:45:41] <kierank> for the second part
[23:45:46] <Dark_Shikari> how would xor help?
[23:45:51] <Dark_Shikari> I don't see how that would be fewer ops
[23:47:18] <Dark_Shikari> guess it isn't very important.
[23:50:50] <Dark_Shikari> the other one I wish I could get faster is
[23:50:51] <Dark_Shikari> int i_count = (i_refa == i_ref) + (i_refb == i_ref) + (i_refc == i_ref);
[23:50:55] <Dark_Shikari> more specifically
[23:50:58] <Dark_Shikari> if( i_count > 1 )
[23:51:02] <Dark_Shikari> but I can't find any magic for doing that.
[23:51:37] <Dark_Shikari> i.e. if i_ref matches more than one of i_refa, i_refb, and i_refc.