[gst-devel] Daily IRC logs

[<wim...@ch...>]

[07:10] Nick change: ajmitch -> ajbusy
[07:25] _gst_newt_ joined #gstreamer.
[07:28] <taaz> anyone awake?
[08:05] taaz (dlehn@66.37.66.32) left irc: Ping timeout for taaz[66.37.66.32]
[08:10] _gst_newt_ joined #gstreamer.
[08:26] iGN_ (ig...@lo...) joined #gstreamer.
[09:00] richardb (richard@195.153.205.133) joined #gstreamer.
[09:05] BBB (BB...@uc...) joined #gstreamer.
[09:06] <BBB> hey omega_dinner, can you send me the xawtv MJPEG video? :)
[09:06] <BBB> or someone else maybe....
[09:12] <richardb> Hmmm, early morning for me today.  Never been up before omega went to bed.
[09:14] <BBB> wow, a new record? :)
[09:25] Action: BBB needs an xawtv MJPEG AVI for testing.....anyone where to find it?
[09:32] BBB (BB...@uc...) got netsplit.
[09:33] BBB (BBB@131.211.105.116) joined #gstreamer.
[11:48] ajbusy (me@203.173.237.120) left irc: Ping timeout for ajbusy[203.173.237.120]
[11:50] ajbusy (me...@p5...) joined #gstreamer.
[14:40] Gandalf_ (ga...@tu...) left irc: Ping timeout for Gandalf_[tux.rsn.bth.se]
[14:41] Gandalf_ (ga...@tu...) joined #gstreamer.
[16:52] thomas (th...@21...) joined #gstreamer.
[17:51] steveb (steveb@24.132.238.49) joined #gstreamer.
[17:55] <BBB> does anyone here have an xawtv-recorded MJPEG-AVI movie for me to borrow?
[18:01] Nick change: wtay-sleeping -> wtay
[18:01] <wtay> BBB: I have one
[18:01] <wtay> 1.5MB
[18:02] <wtay> no audio though
[18:02] <BBB> no problem
[18:02] <wtay> not very interesting either
[18:02] <BBB> as long as it'a an MJPEG AVI.... to test the MJPEG-tools :)
[18:02] <wtay> ok, uploading to gstreamer.net/media
[18:02] <BBB> I made a nice toy (long live SDL) to combine video layers, I will try the same with gstreamer quickly
[18:03] <BBB> look at http://ronald.bitfreak.net/images/yuvplay.png :)
[18:03] <BBB> can I alread merge video streams into one with gstreamer? 
[18:04] <wtay> nope
[18:04] <BBB> hm.... we can make that for you if you want
[18:04] <wtay> cool
[18:05] <BBB> phlipp made something to combine yuv streams into one, we already had something for video->yuv and I made something to preview the combined yuv-stream and philipp made something to make a new avi out of this yuv stream and andrew made mpeg2enc with yuv-input
[18:06] <BBB> so we can preview and create these yuv streams and make video files out of it
[18:06] <BBB> very neat
[18:06] <wtay> nice
[18:06] <wtay> gstreamer.net/media/movie3.avi
[18:06] <BBB> thnx :)
[18:07] <BBB> is it almost totally white?
[18:07] <BBB> I get a "christmas-like" atmosphere here.....:?
[18:08] steveb (steveb@24.132.238.49) left irc: Ping timeout for steveb[24.132.238.49]
[18:09] <wtay> BBB: I told yo it wasn't interesting at all :-)
[18:09] <BBB> okay, but it's supposed to be white? :)
[18:09] <BBB> then t least I know it plays back okay
[18:09] <wtay> yes, a chistmas tree
[18:09] <BBB> ok, kewl!
[18:10] <wtay> completely white :)
[18:10] <BBB> kewl
[18:10] <wtay> I have something more interesting too but that one is *huge*
[18:10] <BBB> our player doesn't play it back ok, but yuv2lav/yuvplay does.....weird, it's both SDL-based
[18:11] <wtay> 41MB...
[18:14] <BBB> hm.... now to find out why lavplay doesn't play it back right
[18:17] Nick change: wtay -> wtay-eating
[18:17] <thomas> wtay-eating: is there a simple linux-supported video card that takes coax cable signal in and outputs either coax signal or tv RCA out ?
[18:23] Uraeus (Ur...@c2...) joined #gstreamer.
[18:23] <Uraeus> hi ho
[18:25] <BBB> does somebody here also have a "nuppelvideo" movie or know what that is? :)
[18:25] <Uraeus> BBB: German porn?
[18:29] ChiefHighwater (pa...@te...) left irc: Read error to ChiefHighwater[temple-baptist.com]: Connection reset by peer
[18:34] <matth_> wtay-eating: i have a few questions for you about gst_queue_get()...
[18:34] <matth_> wtay-eating: let me know when you have a sec
[18:35] <matth_> s/sec/minute
[18:48] thomas (th...@21...) left irc: [x]chat
[18:53] <BBB> Uraeus: nah......... rather american porn >:)
[18:53] Action: BBB was gone for a bit
[18:53] <BBB> :)
[18:54] Gandalf_ (ga...@tu...) got netsplit.
[18:57] Nick change: taaz_ -> taaz
[18:57] Gandalf_ (ga...@tu...) returned to #gstreamer.
[19:09] ChiefHighwater (pa...@te...) joined #gstreamer.
[19:13] Nick change: wtay-eating -> wtay
[19:13] <wtay> matth_: ?
[19:13] Uraeus (Ur...@c2...) left irc: Ping timeout for Uraeus[c224s9h5.upc.chello.no]
[19:16] <matth_> wtay: sorry - i was distracted.  okay:
[19:16] <matth_> first off: is queue->block ever set to FALSE?  who sets it?
[19:17] <wtay> I think it's an arg to the gtkObject, checking
[19:17] <wtay> it is
[19:17] hadess (ha...@pc...) joined #gstreamer.
[19:18] <wtay> yo
[19:18] <wtay> but no app has ever set it to non blocking AFAIK
[19:18] <hadess> yo
[19:19] <matth_> wtay: what is its intent?
[19:19] <wtay> no idea...
[19:19] <wtay> it returns a NULL buffer when the queue is empty...
[19:20] <wtay> I think it was a request/idea/future plan from Erik...
[19:22] <matth_> okay: we just conferred and it's no longer relevant -- i'll remove. 
[19:22] <wtay> ok
[19:23] <omega_dinner> just got response from Andrew, he's drooling
[19:23] <matth_> wtay: next: what is gst_pad_set_eos() supposed to do?  (i'm looking in gst_queue_get())
[19:24] <wtay> omega_dinner: :-)
[19:25] <wtay> matth_: ok
[19:25] <wtay> matth_: hmm
[19:25] <omega_dinner> er
[19:25] Nick change: omega_dinner -> omega_rr
[19:25] <omega_rr> wtay: you wrote eos....
[19:25] <wtay> current eos handling is handled by setting the pad EOS flag at the eos provider
[19:26] <matth_> it looks like this gst_pad_set_eos() stuff is a way to propogate the eos to the other side of the queue... is that right?
[19:26] <wtay> for example the disksrc will call the gst_pad_set_eos() on its src pad
[19:26] <wtay> yes
[19:27] <wtay> but only if the queue is empty
[19:27] <matth_> this propogates left-to-right or downstream?
[19:27] <wtay> so eos comes in on the sink pad, flag is set inside the queue, queue runs empty, flag is set on the src pad
[19:27] <wtay> left to right
[19:27] <matth_> got it.
[19:27] <matth_> thx
[19:32] Uraeus (Ur...@c2...) joined #gstreamer.
[19:32] <wtay> hi
[19:33] <Uraeus> hi wtay
[19:35] ajbusy (me...@p5...) got netsplit.
[19:35] ajbusy (me...@p5...) returned to #gstreamer.
[19:35] <Uraeus> test
[19:35] <Uraeus> test 123
[19:47] <omega_rr> 456
[19:49] <Uraeus> :)
[19:50] <wtay> hmm smpeg still hasn't figured out that there is a bug in the mpeg_play code regarding motion comp... maybe I should mail them..
[19:50] <omega_rr> what kind of bug?
[19:50] <Uraeus> wtay: no flame them instead :)
[19:50] <omega_rr> I have one in my code, maybe you should check out libmpeg1
[19:51] <wtay> no half pel motion compensation for one and an error with a sign somewhere
[19:51] <wtay> looks horrible..
[19:51] <wtay> omega_rr: what's wrong?
[19:52] <omega_rr> bidir macroblocks are fragged
[19:52] <omega_rr> I think it might actually have something to do with the idct, since the patterns I see are odd, but it only seems to happen on bidir macroblocks
[19:53] <wtay> maybe I should try to create a gstreamer plugin from it and check it out..
[19:53] <omega_rr> from libmpeg1?
[19:53] <omega_rr> I wouldn't recommend it just yet
[19:54] <omega_rr> I'll do it, because that's how I want to refine the API, anyway
[19:54] <wtay> oh
[19:54] <wtay> ok
[19:54] <omega_rr> but check it out, lemme put up the test video I've been using
[19:54] <wtay> is there a test program for it then?
[19:54] <omega_rr> yes
[19:54] <omega_rr> gst.net/media/everest.m1v
[19:54] <wtay> codecs.org is not responding :(
[19:54] <omega_rr> as soon as I can talk to sf.org
[19:54] <wtay> oh, I already have that one
[19:55] <omega_rr> ok
[19:55] <omega_rr> sf is back
[19:55] <wtay> what's the cvs module?
[19:57] <wtay> ok libmpeg
[19:59] <omega_rr> oh
[19:59] <omega_rr> you need libcodec and libbitstream too <g>
[19:59] <wtay> I noticed :)
[19:59] <wtay> looking at the src...
[20:02] <omega_rr> BBB: does Andrew live on IRC anywhere?
[20:07] <BBB> nope :)
[20:07] <BBB> I can ask him to come here if you want, though
[20:08] <BBB> did you see my yuv-stream-combiner-ith-preview-option? I think I'll port it to gstreamer too someday when I understand gstreamer
[20:09] <omega_rr> if he's around, yeah
[20:09] <omega_rr> no, lemme check that out
[20:10] steveb (st...@no...) joined #gstreamer.
[20:10] <omega_rr> interesting.  it just takes N yuv streams and merges them with offsets?
[20:10] <hadess> "all your iTunes components are belong to me"
[20:10] <BBB> omega_rr: kind of
[20:11] <steveb> hi all
[20:11] <omega_rr> BBB: do you have a Miro DC10+
[20:11] <wtay> hi
[20:11] <BBB> omega_rr: http://ronald.bitfreak.net/images/yuvplay.png
[20:11] <BBB> omega_rr: yup
[20:11] <omega_rr> does it have a tuner?
[20:13] <BBB> no
[20:13] <omega_rr> grrr
[20:13] <omega_rr> so much for that idea
[20:13] <BBB> lol
[20:13] <omega_rr> which mjpeg cards do have tuners?
[20:13] <omega_rr> the G400-TV does
[20:13] <omega_rr> but it's also a video card
[20:13] <BBB> G400/G200 do
[20:13] <omega_rr> BBB: see gstreamer.net/wiki/Gbox
[20:13] <BBB> rainbow runners
[20:14] <steveb> i've been thinking a lot about an implementation for time-dependant parameters for elements - I think the time has come to wiki my ideas
[20:14] <omega_rr> yup
[20:14] <omega_rr> you mean sample-accurate control?
[20:14] <steveb> yes
[20:14] <omega_rr> thus the node name SampleAccurateControl
[20:14] <hadess> omega_rr: what is Gbox ?
[20:14] <omega_rr> or somesuch
[20:14] <omega_rr> <g>
[20:14] <omega_rr> hadess: see the page
[20:14] <omega_rr> I have another idea for a name, actually
[20:15] <steveb> I was thinking DynamicParams
[20:15] <omega_rr> since CHW has some concerns about the public perception of anything with a G in front of it
[20:15] <steveb> ie, parameters that have an awareness of time
[20:15] <omega_rr> right
[20:16] <BBB> omega_rr: why do you need a tuner?
[20:16] <omega_rr> because it's supposed to timeshift TV
[20:16] <BBB> omega_rr: the input for a DC10+ is regulated by the input from the VCR/vidcam
[20:16] <omega_rr> you can't do TV without a tuner
[20:16] <hadess> interesting
[20:16] <BBB> then connect the VCR to the input and tune with the VCR :)
[20:16] <omega_rr> um, no
[20:16] <omega_rr> single-box
[20:17] <BBB> hm........
[20:17] <BBB> then a Matrox is probably a better idea
[20:17] <steveb> wtay, omega_rr: do either of you have a burning desire to implement dynamic params yourself?  I'd like to give it a crack if my idea gets a positive response
[20:17] <BBB> I just implemented a big "enable-tuner-for-matrox" patch for lavrec
[20:17] <omega_rr> G400-TV or rainbow runner?
[20:17] <omega_rr> steveb: no, other pressing issues for me, though I definitely need it for my own projects
[20:17] <BBB> uhm.... dunno...... look @ marvel.sourceforge.net
[20:18] <BBB> they should know which is best
[20:18] <steveb> omega_rr: thought so
[20:18] <wtay> grr, I need mmx.h and sse.h
[20:18] <omega_rr> steveb: so I very much want to debate the design, yes
[20:18] <omega_rr> they're in gstreamer/include, I think
[20:18] <omega_rr> or I'll put mine on gstreamer.net
[20:19] <omega_rr>  /*.h
[20:19] <wtay> they don't mix very well last time I tried
[20:19] <steveb> omega_rr: I will even encourage inline comments in the page
[20:19] <omega_rr> cool
[20:20] <omega_rr> BBB: the choice of cards is very tricky
[20:20] <steveb> what is the unit of time for timestamp?
[20:20] <omega_rr> the mobo I'm looking at (the ASUS A7VI-VM) has onboard video
[20:20] <omega_rr> UST, or nanoseconds since boot/origin
[20:20] <omega_rr> in 64bit
[20:20] <BBB> omega_rr: I know. most don't have hardware acceleration which really really sucks
[20:20] <omega_rr> lemme dblcheck it's nanoseconds though
[20:21] <omega_rr> BBB: the key is that I need a mjpeg card with tuner, that can draw raw YUV to a framebuffer
[20:21] <omega_rr> primarily so I can put 2 or more of these in the machine, without having 2 or more VGA cards
[20:21] <BBB> hm...... with tuner?
[20:21] <BBB> quite difficult
[20:21] <BBB> I think you cannot get more than one marvel in a machine
[20:21] <omega_rr> ick
[20:21] <BBB> you can try a buz and a DC10+ together :)))
[20:22] <BBB> in windows, windows crashes directly on that
[20:22] <omega_rr> of course
[20:22] <BBB> in linux with sergueis driver, it rocks!
[20:22] <omega_rr> but I'd also rather have N of the same....
[20:22] Nick change: omega_rr -> omega_lunch
[20:22] <omega_lunch> I'll be back
[20:22] <BBB> hm....ok :)
[20:22] <omega_lunch> bring Andrew in in 30-45min if you can
[20:22] <steveb> nothing seems to use timestamp in gstreamer yet
[20:22] <BBB> lol
[20:23] <BBB> I'll ask him to come here - I think he's at home :)
[20:23] <wtay> steveb: mpeg_play does
[20:24] <steveb> wtay: which elements do though?
[20:24] <wtay> plugins/mpeg1/mpeg_play/gstmpeg_play.c for one and xvideosink too
[20:24] <steveb> ok, i'll check them out
[20:26] Action: hadess is messing up his system
[20:27] <BBB> haha, I sent the email to Andrew
[20:27] <BBB> let's hoep he reads it tonight
[20:40] <BBB> I'll be back later I have some work to do :)
[20:40] Action: BBB is away: work2do
[20:56] taaz (dlehn@66.37.66.32) left irc: Ping timeout for taaz[66.37.66.32]
[20:56] taaz (dlehn@66.37.66.32) joined #gstreamer.
[21:04] wtay (wim@195.162.214.190) left irc: Client Exiting
[21:10] Nick change: ajbusy -> ajmitch
[21:23] wtay (wi...@ca...) joined #gstreamer.
[21:23] <ajmitch> hi wtay
[21:24] <wtay> hello
[21:24] <wtay> did the mail arrive?
[21:24] <taaz> hey, you were saying something about bugs in smpeg?
[21:24] <wtay> yes?
[21:25] <ajmitch> wtay: to me? nope
[21:25] <wtay> hmm
[21:25] <taaz> is that just mpeg1 stuff?  cause libmpeg2 can do mpeg1 streams too
[21:25] <wtay> yup, only mpeg1 stuff
[21:25] <taaz> could try to use mpeg2dec plugin for mpeg1 streams and see how it performs
[21:26] <wtay> taaz: yes
[21:26] <wtay> ajmitch: trying to send to myself now
[21:26] <taaz> i was trying to view a divx/avi/whatever the other day with gstmediaplay... the sync was waaaay off.. like 1 second or more.
[21:27] <wtay> taaz: indeed, avi sync is not very well implemented
[21:27] <ajmitch> wtay: send me the script you use (via dcc)
[21:27] <taaz> by "not very well" do you mean not at all? ;)
[21:27] <hadess> hey taaz, ajmitch
[21:27] <wtay> taaz: somewhat, I mean
[21:27] <ajmitch> hi hadess
[21:27] <wtay> cd /home/wim/
[21:27] <wtay> cat logs/fd_header logs/fd.log logs/fd_separator logs/scrappy.log |sendmail -t -F"Wim Taymans" -fwi...@ch...
[21:27] <wtay> ajmitch: that's it :-)
[21:28] <wtay> and I got the mail to myself...
[21:28] <ajmitch> wtay: hmm... not much too it, how could it go wrong? ;)
[21:28] <ajmitch> wtay: ok, shall i use anoher of my email addresses? ;)
[21:28] <wtay> ajmitch: yes
[21:29] <ajmitch> wtay: aj...@ih... might work (my SF one points there)
[21:30] <wtay> ajmitch: sent (twice)
[21:35] <ajmitch> willl await it in my mail... ;)
[21:36] Action: hadess just created 4 useless bonobo components
[21:36] <wtay> 2001-04-26 21:29:39 14srSI-0006Fx-00 => aj...@ih... R=smarthost T=remote_smtp H=out-mx.chello.be [195.162.196.21]
[21:36] <wtay> 2001-04-26 21:29:39 14srSI-0006Fx-00 Completed
[21:36] <wtay> 2001-04-26 21:29:43 14srSL-0006G5-00 => aj...@ih... R=smarthost T=remote_smtp H=out-mx.chello.be [195.162.196.20]
[21:36] <wtay> 2001-04-26 21:29:43 14srSL-0006G5-00 Completed
[21:36] <ajmitch> useless?
[21:37] <hadess> yep, they just display a table, or a tree
[21:37] <omega_lunch> so any ideas on the Gbox idea?
[21:37] <hadess> and that's it
[21:37] <hadess> omega_lunch: yeah, rhythmbox will do the first 2 paragraphs =)
[21:37] <wtay> omega_lunch: I'm tempted to try the diskcache...
[21:37] Nick change: omega_lunch -> omega_rr
[21:38] <omega_rr> for that, yeah.
[21:39] <wtay> libmpeg doesn't compile...
[21:39] Action: omega_rr looks surprised
[21:39] <wtay> reconstruct.c:345: `lc_mcomp_sum_U8_S16_U8_8x8_mmx' undeclared (first use in this function)
[21:39] <wtay> reconstruct.c:345: (Each undeclared identifier is reported only once
[21:39] <wtay> and I think I know what the problem is
[21:39] <omega_rr> lemme give it a try, then check in what I need to do
[21:39] <omega_rr> brb
[21:40] <omega_rr> <gulp>
[21:40] Action: omega_rr does a diff
[21:43] <wtay> you include mcomp.c in mcomp.h but parts af the code are #ifdef'ed out because __LC_HAVE_MMX isn't defined when compiling libmpeg
[21:43] <omega_rr> hrm
[21:43] <omega_rr> remove config.cache and reconfig with mmx.h in the right place
[21:43] <omega_rr> or check the configure.in check
[21:44] <wtay> did that with the configure results:
[21:44] <wtay> checking for MMX-capable compiler... yes
[21:44] <wtay> checking for 3DNow!-capable compiler... no
[21:44] <wtay> checking for SSE-capable compiler... yes
[21:44] <wtay> in libmpeg
[21:45] <wtay> hmm, you do define __LC_HAVE_MMX in configure.in...
[21:45] <omega_rr> hmm
[21:45] <omega_rr> well, cvs update in libcodec
[21:45] <omega_rr> then I'll go patch up libmpeg
[21:46] <omega_rr> I changed the arch names to __LC_HAVE_X86_MMX
[21:46] <wtay> ooh, lots of changes 
[21:46] <omega_rr> so I have to update the configure.in in libmpeg
[21:46] <wtay> I also did make install
[21:46] <omega_rr> and some other stuff
[21:46] <omega_rr> see commitlog
[21:46] <omega_rr> ok
[21:46] <omega_rr> you'll want to do it again with libcodec
[21:46] <omega_rr> libbitstream should still work without changes
[21:47] <omega_rr> I have a massive rewrite of bitstream in the works, but in a separate working copy
[21:48] <wtay> how much faster is an MMX optimised bitstream?
[21:48] <ajmitch> bbl
[21:48] Nick change: ajmitch -> ajbusy
[21:48] <steveb> will richard's configure.in patch go into cvs?
[21:48] <omega_rr> also, you might be interested in signing onto the codecs.org lists, esp if Andrew gets onboard
[21:48] <omega_rr> wtay: depends, I'm working out the best mechanism still
[21:48] <omega_rr> but it's supposedly 2x faster, roughly
[21:48] <wtay> omega_rr: ok, I'll subsribe
[21:48] <omega_rr> my timings indicate that I can do 1000 5-bit reads at 5 cycles each, including next_word overhead
[21:49] <omega_rr> but that's in a tight loop
[21:50] <wtay> pretty good
[21:52] Action: omega_rr is timing the C equiv now
[21:53] Nick change: hadess -> hds-busy
[21:54] <omega_rr> ok, it works for me, I'll now commit and you can update
[21:55] <wtay> ok
[22:07] <omega_rr> gstreamer.net/cvs/ is a forwarder to the viewcvs now, as a shortcut...
[22:13] <steveb> what version of automake do you lot use?
[22:14] newbie (ar...@ho...) joined #gstreamer.
[22:15] <ChiefHighwater> ello
[22:19] <steveb> night
[22:19] steveb (st...@no...) left irc: [x]chat
[22:21] newbie (ar...@ho...) left #gstreamer (lilo: KVIrc).
[22:25] dobey (do...@dr...) joined #gstreamer.
[22:30] Wackston (as...@f-...) joined #gstreamer.
[22:32] <Wackston> Any gstreamer dev folk around
[22:34] <wtay> yeah
[22:34] Action: wtay is a little distracted
[22:34] <Wackston> Just got an email from Ronald Bultje...
[22:34] <Wackston> Suggested Erik Watkinson wanted to chat re: MPEG 1/2 encoders...
[22:35] <wtay> Are you Andrew?
[22:36] <Wackston> That's me.  I use "wackston" for historical reasons.
[22:36] <wtay> cool, welcome :)
[22:36] <Wackston> I gather the issue is packing a reasonably o.k. MPEG encoder into gstreamer.
[22:37] <wtay> yes
[22:37] <wtay> but I would first create a library out of mpeg2nc
[22:37] <ChiefHighwater> omega (Erik) says ETA 10 mins...he's in a meeting just now
[22:37] <dobey> hrmm
[22:38] <Wackston> Ok doke... I'll just lurk here and send Ronald an email or two - I'll be listening up.
[22:38] <Wackston> Got a niggly YUV422 / YUV420 issue in JPEG to sort out.
[22:54] Action: omega_rr is here
[22:55] <Wackston> Hi Omega...
[22:55] <BBB> wackston? that can only be one guy!!!
[22:55] Action: BBB is Ronald :)
[22:55] <Wackston> Thats me (Andrew Stevens)...its a long story.
[22:55] Action: omega_rr is gonna commit his libmpeg stuff for wtay, sec..
[22:55] <dobey> ppppshftf
[22:56] <BBB> Wackston: the yuv-player is getting along quickly, I think I'll have a search-system in a few days.... if school doesn't bother me too much
[22:57] <Wackston> I should have a nice quiet weekend.  No project pressure at work
[22:57] <omega_rr> wtay: ok, update libcodec and libmpeg
[22:57] <Wackston> and my Mommy is overnighting friday which kills
[22:57] <wtay> ok thx
[22:57] <BBB> hm...... nice
[22:57] <Wackston> ski-ing for sat and sun is supposed to be crud weather
[22:57] <BBB> I have about a hundred school projects to go this weekend and next week :(
[22:58] <omega_rr> so, I haven't looked through the code much, is there a roadmap somewhere for mpeg2enc?
[22:58] <BBB> I'll leave you two alone and go back to schoolwork ;)
[22:58] <omega_rr> heh
[22:59] <Wackston> There's a TODO but its fairly low-level.
[22:59] omega_ (om...@qw...) joined #gstreamer.
[22:59] Action: omega_ can read better on this screen
[22:59] <Wackston> The exec. summary is that mpeg2enc is feature frozen.
[22:59] <Wackston> I.e. further work will be bugs and interoperability/environment only
[22:59] <Wackston> The reason is that it would be a major league pain to
[22:59] <Wackston> update to do the stuff that's not there.
[22:59] <omega_> but this is for 1.4 only, right?
[23:00] <Wackston> I'd rather invest the time in the sampeg-4 project and on stuff
[23:00] <Wackston> like.... (tada)
[23:00] <Wackston> getting it all into gstreamer so its really widely useful
[23:00] <omega_> url for sampeg?
[23:00] <Wackston> I very much doubt I will do much more to it.  The law of diminishing returns
[23:00] <Wackston> (hold on sec)
[23:01] <omega_> uni-mannheim doesn't respond, trying again
[23:01] <omega_> wtay: you trying latest cvs?
[23:01] <Wackston> http://sourceforge.net/projects/mpegvideo/
[23:01] <wtay> omega_ I see something, it looks good
[23:02] <Wackston> (pop)
[23:02] <omega_> play everest.m1v with plaympeg too
[23:02] <Wackston> is applyin fairly strongly.  What's really needed isn't better MPEG
[23:02] <omega_> any code for this project yet?
[23:02] <wtay> omega_ horrible with plaympeg :-)
[23:02] <Wackston> but stuff that relates to pre and post processing
[23:02] <omega_> wtay: hrm, even latest? I get cleaner mb's for B's with plaympeg
[23:03] <omega_> Wackston: yeah, that's the way things are going
[23:03] <Wackston> Code - yes definately.  I haven't looked for a bit.
[23:03] <wtay> omega_ well, the yuv scaling doesn't work so I can't see much details
[23:03] <Wackston> Move of house and job got in the way.  However I was hoping to start
[23:03] <omega_> the startup I worked for before RR was working on a workflow for encoding that involved significant preprocessing
[23:03] <Wackston> serious work with those guys sometime this year.  Dirk is good and knows his
[23:03] <omega_> no code in CVS on sf though
[23:03] <Wackston> compression / MPEG stuff
[23:04] <Wackston> However, I want to get closure on mpeg2enc first.   The big job
[23:04] <Wackston> is the multiplexer.  There isn't a good general purpose open source muxer.
[23:04] <Wackston> Its needed not just for the MPEG encoder folk but also the linuxtv guys
[23:04] <omega_> wtay: how well does the one in gstreamer work?
[23:04] <omega_> right
[23:05] <Wackston> They can pull MPEG from their sat / cable boards but remux / transcode isn't so hot.
[23:05] <wtay> omega_ it used to work somewhat
[23:05] <Wackston> What's the code base - "mplex".  That was my biggest error. Should have started
[23:05] <wtay> implemented from scratch without docs etc...
[23:05] <omega_> wtay: you're insane
[23:06] <Wackston> from scratch.  The author was *almost* right but not quite right.
[23:06] ajbusy (me...@p5...) left irc: Ping timeout for ajbusy[p56-max6.dun.ihug.co.nz]
[23:06] <Wackston> The killer with mux-ing is VCD/SVCD.  The former especially is a MESS.
[23:06] <omega_> howso?
[23:06] <Wackston> Actually from old philips hands I have it on reliable authority that the
[23:07] <Wackston> coloured book "spec" was more or less "how our first bodged chipset worked".
[23:07] <omega_> oy
[23:07] <Wackston> E.g.  The last 14 or 16 or whatever bytes of every audio sector in the stream are
[23:07] <Wackston> simply ignored.  Woe betide the naive mux author who does it correctly and actually fills his
[23:07] <Wackston> audio sectors.   
[23:07] <omega_> ic
[23:07] <omega_> er, ick
[23:08] <Wackston> Also the mux rate is not the actual data-rate in the MPEG stream but the date rate coming
[23:08] <Wackston> *raw* of the MODE2 XA CD stream.   Its 20 bytes more per sector.
[23:08] <omega_> hmm
[23:08] <Wackston> The reason is (presumably) that the first chipsets were bodged audio CD chips with a DSP "side-car"
[23:09] <omega_> neat
[23:09] <Wackston> SVCD is much more rational in this respect but has the evil (vile) habit of
[23:09] <Wackston> mixing its layers.
[23:09] <omega_> layers?
[23:09] <Wackston> Seek info for navigation in the program stream is packed into user-date
[23:09] <omega_> ah
[23:09] <Wackston> sections of the video sequence.  The info is *CD* sector info.  It is,
[23:10] <Wackston> needless to say not info that is available when the video stream is being generated.
[23:10] <omega_> wtay: compare the haze surrounding the ridge that's 'behind' the climber between plaympeg and ./decode
[23:10] <omega_> Wackston: cool
[23:10] <Wackston> Anyway, the current muxer is also brainless in that it 
[23:11] <Wackston> unnecessarily does two passes and is hard-wired for 2 streams.
[23:11] <omega_> oops
[23:11] <Wackston> It really needs to be able to mux 1 video + n audio.   
[23:12] <Wackston> Getting rid of the two-pass guff shouldn't be too hard it is *almost* there
[23:12] <omega_> any use for n video + m audio?
[23:12] <Wackston> already access unit info is held in big vectors which could easily morph
[23:12] <Wackston> into dynamically updated buffers.
[23:13] <Wackston> However,  as with mpeg2enc I wanted to get a stable final out
[23:13] <Wackston> and then move into gstreamer so that (for me) side-issues like
[23:13] <Wackston> filters and pre-proc could be "assumed" to be dealt with in the enc pipeline.
[23:13] <omega_> right
[23:14] <wtay> omega_ I can't see any obvious errors...
[23:14] <omega_> it looks like idct fuzz, but when I look at the plaympeg output I see roughly the same
[23:14] <omega_> wtay: maybe I fixed it accidentally <g>
[23:15] <omega_> Wackston: so sampeg, is it going to basically be a codec suite, plus pre-proc filters?
[23:15] <wtay> omega_ so it seems...
[23:15] ajbusy (me@203.173.238.184) joined #gstreamer.
[23:15] <Wackston> sampeg is going to be a nice built from scratch MPEG-4/2/1 encoder.
[23:15] <omega_> wtay: can you time the decode now, I'm gonna commit some speedups (just use sse instead of C for epsilon mcomp)
[23:15] ajbusy (me@203.173.238.184) left irc: http://www.freedevelopers.net
[23:15] <omega_> Wackston: cool
[23:15] <Wackston> Idea is to do it cleanly in C++ and incorporate the lessons learn from sampeg-2
[23:15] <omega_> sounds like codecs.org stuff is exactly what's needed
[23:16] <omega_> c++? ick
[23:16] <omega_> why??
[23:16] <Wackston> and (if I ever do anything on it) my stuff in mpeg2enc.
[23:16] <Wackston> C++ - fine no issue if you undertstand anonymous object creation
[23:16] <Wackston> placement new and implicit copy constructors.
[23:16] <omega_> but what does an object system give to an encoder/decoder?
[23:17] Action: omega_ thinks a codec should be as *bare* metal as possible
[23:17] <Wackston> It makes it possible to do the fiddly control stuff you need for
[23:17] <Wackston> really high end results.
[23:17] <omega_> howso?
[23:17] <Wackston> The CPU cycles are all in about 5 sub-routines anyway. The rest is in the noise.
[23:18] ajbusy (me...@p5...) joined #gstreamer.
[23:18] <Wackston> That's why "Tom's hardware" are a bunch of lamers using MPEG encoding as a
[23:18] <Wackston> benchmark.
[23:18] <Wackston> Change 5 asm instructions or even your source material and you get
[23:18] <omega_> mpeg encoding as a benchmark is reasonable if every single attempt is highly optimized for that chip
[23:18] <Wackston> totally different results.
[23:18] <Wackston> Back to C++:  Example:
[23:19] <Wackston> You want to do dynamic selectino between B/P frames.
[23:19] <omega_> if you compare uber-tuned encoders of the same architecture on different chips, then it gets useful, but anyway
[23:19] <omega_> for encoder or decode?
[23:19] <wtay> omega_ libmpeg is on par with gstmpeg_play (quality wise), and much better than smpeg
[23:19] <omega_> cool
[23:19] <Wackston> Of course you still want to do your multi-threading et all.
[23:20] <Wackston> This gets really hairy unless you can nicely encapsulate
[23:20] <omega_> multi-threading where?
[23:20] <Wackston> the notion of "frame being encoded" and suchlike.
[23:20] <Wackston> I.e. you use the "++" stuff for the despatcher and control
[23:20] <Wackston> and the low-level stuff is C and the real work gets done in asm.
[23:21] <omega_> wtay: time decode, update libmpeg/reconstruct.c, and time decode again
[23:21] <Wackston> Multi-threading:  macro level parallelism in frame encoding.
[23:21] <Wackston> Basically you can do part of every frame independent of every other
[23:21] <omega_> define macro-level?
[23:21] <omega_> ok, right
[23:21] <Wackston> the rest of each B*P group up to rate control in parallel
[23:22] <Wackston> but rate control and VLC coding is essentially serialised.
[23:22] <omega_> right
[23:22] <Wackston> If you want to get really aggressive you also have worker pools for 
[23:22] <Wackston> motion compensation and DCT/quantisation.
[23:22] <Wackston> The latter is not needed for a dual CPU machine you can get
[23:23] <Wackston> 80%+ utilisation of a dual machine with just the macro level stuff.
[23:23] <omega_> wtay: results?
[23:23] <omega_> how do you mean 'macro-level' ?
[23:23] <Wackston> Add in audio encoding, filtering, decoding of input stream and muxing and you have
[23:23] <wtay> omega_ doh I forgot to time *before* the update :)
[23:23] <wtay> 1.2s user
[23:23] <Wackston> enough for 3 CPU's.
[23:23] <omega_> wtay: rev 1.2 
[23:23] <Wackston> mpeg2enc as it stands does the macro-level multi-threading.
[23:24] <omega_> define macro-level ?
[23:24] <Wackston> Is this an issue for gstreamer plug-in's? 
[23:24] <Wackston> Macro-level = "top-level chunks of computatin".  In the case of MPEG
[23:24] <Wackston> this would be encoding of the seperate frames.
[23:24] <Wackston> Micro-level would be splitting an individual computatino 
[23:24] <omega_> ok, then I'd call it frame-level paralellism
[23:25] <Wackston> like the motion compensating the macro blocks of a frame
[23:25] <Wackston> between multiple threads.  
[23:25] <Wackston> Too much time amoungst distrib. proc. peolpe atOxford I guess...
[23:25] <omega_> heh
[23:25] <wtay> 1.5 sec
[23:26] <omega_> nice
[23:26] <omega_> compare to plaympeg ?
[23:26] <wtay> 1.3..
[23:26] <wtay> 0.3
[23:27] <omega_> I get 6.4sec vs 5.4sec without/with sse
[23:27] <omega_> Wackston: so where is the sampeg code right now?
[23:28] <wtay> it's about the same here
[23:28] <Wackston> No idea really.  I've been busting a gut to get mjpegtools to final (at last).
[23:28] <omega_> wtay: it's not using mmx idct right now, either
[23:28] <Wackston> I'd hoped to have it done a month ago but stuff just keeps coming up.
[23:28] <wtay> omega_ ok
[23:28] <Wackston> Now we're down to YUV422 MPJPEG from xawtv and gstreamer - makes lavplay
[23:29] <Wackston> barf at present. 
[23:29] <omega_> hmm
[23:29] <Wackston> Can be mpeg encoded though.
[23:29] <Wackston> lavlpay does some real dirty stuff to get decent software MJPEG speed.
[23:30] <Wackston> Anyway, regarding gstreamer.  Wim ??nameforgot?? has offered to hand-hold
[23:30] <omega_> == wtay
[23:30] <Wackston> embedding mpeg2enc 
[23:30] <Wackston> mplex is still a little way away from this.  The two-pass crud needs to be
[23:30] <Wackston> got rid of first and then it can get "the treatment too".  Do you have
[23:30] <wtay> There is a one pass muxer in gstreamer...
[23:31] <Wackston> toolame or somesuch encapsulated.  
[23:31] <Wackston> What state is its code-base in?  It might perhaps be easiet to
[23:31] <wtay> mpegaudio for layer2 and lame for layer3 mpeg audio
[23:31] <Wackston> put the lesson learned from mplex into a clean code base
[23:31] <wtay> it's in a very bad shape but it used to work
[23:31] <Wackston> than make mplex a clean code base ;-)
[23:32] <Wackston> Oh dear... mux-ing is damn fiddly.  There may also be some code
[23:32] <omega_> wtay: mmxext idct screws the image (different reorder matrix needed), but goes from 5.4sec to 4.1sec
[23:32] <Wackston> frmo the linuxtv guys.  I'll have to look...
[23:32] <Wackston> For layer 2: toolame is way better than mpegaudio.
[23:33] <wtay> Wackston: hmm
[23:33] <Wackston> If mpegaudio is MSSG audio encoder...
[23:33] <wtay> Wackston: I think so yes
[23:33] <Wackston> Yup, then toolame is mucho better.  The "mp2enc" in mjpegtools is
[23:33] <Wackston> mpegaudio.
[23:33] <omega_> wtay: can you change the lc_idct_8x8_inplace_S16 line to:
[23:33] <omega_>           _lc_idct_8x8_inplace_S16__x86_mmxext(mb.blocks[i].coeffs);
[23:33] <wtay> libraryfied?
[23:33] <Wackston> Aside: anyone got the source code for Intel's recommend *SSE*
[23:34] <Wackston> *forward* DCT.
[23:34] <omega_> um, no, but I know people who might
[23:34] <Wackston> Their appnote only has code fragments in their macro asm.
[23:34] <omega_> need that for libcodec
[23:34] <Wackston> Getting that stuff right in a port is way fiddly work.
[23:34] <wtay> I saw an implementation of it once...
[23:34] <Wackston> where where where
[23:34] <wtay> good question...
[23:34] <wtay> I know it's out there somewhere..
[23:34] <Wackston> One for codecs.org for sure.... (needless to say I'd like to use that
[23:35] <Wackston> for mpeg2enc sometime too).  gstreamer first tho.
[23:35] <taaz> does mpeg2dec have it?  i know walken did the mmx one... maybe a sse one too
[23:35] <omega_> Wackston: have you checked out the code?
[23:35] <omega_> taaz: forward, not idct
[23:35] <wtay> taaz: nope, mpeg2dec only has iDCT
[23:35] <taaz> uh... just do it in reverse ;)
[23:36] <omega_> fyi, switching from C to mmxext (3dnow) idct and C to sse for mcomp caused a 56% jump in speed of my libmpeg code, with no other changes
[23:36] <omega_> because of libcodec
[23:36] <omega_> taaz: not quite <g>
[23:37] <Wackston> Anything more to chat - gotta hit sack soon, gotta earn my
[23:37] <Wackston> techno toys and ski money
[23:37] <omega_> heh, just take a look at libcodec, libbitstream (in mid-rewrite, so don't get too attached) and libmpeg
[23:37] <wtay> omega_ hmm, where is that idct call?
[23:38] <omega_> esp tests/decode.c from libmpeg, as a high-level usage of low-level routines
[23:38] <omega_> wtay: tests/decode.c
[23:38] <wtay> huh?
[23:38] <omega_> libmpeg/tests/decode.c
[23:38] <omega_> Wackston: my dream decoder/encoder lib has access to lower-level routines, so you can play with enhancing the encoder/decoder with just the top-level code equiv to decode.c
[23:38] <wtay> oh, you do part of the decoding in decode.c..
[23:39] <omega_> yeah, that will get moved down into helper routines eventually, just didn't get around to it
[23:39] <wtay> 1.2sec
[23:39] <omega_> better than plaympeg <g>
[23:39] <omega_> er, wait
[23:39] <Wackston> That's more or less what the sampeg-4 project is about.
[23:39] <omega_> no it isn't
[23:39] <wtay> hmm, sorry 
[23:39] <omega_> Wackston: good, though I still don't like the C++ idea
[23:40] <wtay> 0.9
[23:40] <omega_> wtay: yeah, I'm looking at the wrong numbers
[23:40] <Wackston> Panic not.   Really honestly its not a performance issue if you
[23:40] <Wackston> know what you're doing.
[23:40] <omega_> yes, but I don't think it gives sufficient advantage, if you sturcture your C code right
[23:40] <Wackston> Actually, for a lot of "clean" C code you can sometimes gain
[23:41] <Wackston> because the compiler can optimise passing around of this pointers and such
[23:41] <omega_> wtay: I see better results from decode than plaympeg, time-wise
[23:41] <omega_>  /usr/bin/time
[23:41] <Wackston> which it can't if all its sees are struct's.
[23:41] <omega_> Wackston: check out libcodec and libmpeg, I think I have a good arch in C for that
[23:41] <wtay> omega_ 0.3 vs 0.8 now
[23:42] <Wackston> Of course, you'd be insane to encapsulate your MC code in a class rather
[23:42] <Wackston> than straight functinos wrapping asm ;-)
[23:42] <omega_> that's what libcodec is for <g>
[23:42] <Wackston> Hmmm... cycle of reincarnation... C++ grew out of AT&T labs
[23:42] <Wackston> C coding conventions.  
[23:43] <wtay> omega_ anyway plaympeg only does a half job (no half pel motion comp) so...
[23:43] <Wackston> Simulating C++ classes in C with the same compiler back-end doesn't
[23:43] <omega_> wtay: oh??
[23:43] <Wackston> save much and only adds coding overhead.
[23:43] <wtay> omega_ X and Y helf pel isn't implemented
[23:43] <Wackston> HOWEVER: you have to *understand* C++ class instantiation/copying
[23:43] <omega_> wtay: I get 0.6357 decode vs. 0.9196 for plaympeg
[23:44] <wtay> omega_ hmm
[23:44] <Wackston> if you don't want "surprisingly slow results"
[23:44] <omega_> that's /usr/bin/time user time * PU
[23:44] <omega_> Wackston: yeah, but I think C is just better for this stuff regardless
[23:44] <omega_> maybe we can compete C++ vs C if we get enough of the core routines into libcodec <g>
[23:44] <omega_> which is C, of course
[23:45] <wtay> real	0m1.965s
[23:45] <wtay> user	0m0.890s
[23:45] <wtay> sys	0m0.010s
[23:45] <wtay> decode
[23:46] <wtay> real	0m4.813s
[23:46] <wtay> user	0m0.310s
[23:46] <wtay> sys	0m0.040s
[23:46] <wtay> plaympeg
[23:46] <wtay>  time plaympeg /opt/data/everest.mpg
[23:46] <wtay> time ./decode /opt/data/everest.mpg
[23:46] Uraeus (Ur...@c2...) left irc: 
[23:47] <omega_> wow
[23:47] <Wackston> O.k. beddy-byes for me... gotta build the scaler-from-hell tomorrow...
[23:47] <omega_> use /usr/bin/time though
[23:47] <omega_> Wackston: ok, cya round, maybe subscribe to codecs-dev ?
[23:47] <omega_> there's no traffic there, but there will be soon
[23:48] <omega_> and codecs-cvs if you're interested
[23:48] <Wackston> WIll do for sure.   It'll be mpeg2enc platform one day.  Night all...
[23:48] Wackston (as...@f-...) left irc: using sirc version 2.211+4KSIRC/1.1
[23:48] <omega_> brb
[23:48] <wtay> decode: 0.82user 0.03system 0:01.97elapsed 43PU (0avgtext+0avgdata 0maxresident)k
[23:49] <wtay> plaympeg 0.37user 0.02system 0:04.87elapsed 8PU (0avgtext+0avgdata 0maxresident)k
[23:51] <omega_> um, now I'm confused over times
[23:51] <omega_> is user time absolute in seconds?
[23:51] <wtay> I think so yes
[23:51] <omega_> oh
[23:52] <omega_> there's no way there's that much difference
[23:52] <wtay> gstmediaplay: 0.21user 0.11system 0:05.71elapsed 5PU (0avgtext+0avgdata 0maxresident)k
[23:52] <BBB> hey, I'm reading through the discussion a bit...:) C/C++ conflict? :P
[23:53] <omega_rr> yeah
[23:53] <BBB> lol
[23:53] Action: BBB has absolutely no knowledge about which would be better for what...
[23:53] <wtay> and sampeg fails to compile for that reason...
[23:53] <omega_rr> where did you get sampeg??
[23:53] <BBB> I should start doing computer courses, or programming courses or something for that :)
[23:53] <wtay> image/bitmap.cc:105: duplicate explicit instantiation of `class Bitmap<unsigned char>'
[23:54] <wtay> omega_ freshmeat search I think
[23:54] <omega_rr> hmm, ok
[23:54] <wtay> http://rachmaninoff.informatik.uni-mannheim.de/sampeg/
[23:54] <omega_rr> no response last I tried
[23:54] <omega_rr> can you email me the tarball?
[23:55] <wtay> sure
[23:55] <omega_> turning off half-pel can shave 20+% off decode time
[23:56] <wtay> sent
[23:57] <wtay> plaympeg is twice as slow as the current gst one...
[23:57] <omega_> wow
[23:59] <omega_> I average 10% penalty for half-pel
[23:59] <omega_> and that's just forcing the flags to zero after computing them
[23:59] <omega_> and still switching out on thost flags
[23:59] <omega_> so even bigger diff without those
[00:00] --- Fri Apr 27 2001
[00:00] <omega_> so, can you write up or at least finger the changes you made to the mpeg_play in gstreamer?
[00:00] <omega_> since you made significant performance improvements
[00:00] Action: dobey pokes hadess
[00:00] <omega_> maybe add a page on the codecs.org wiki
[00:00] <hds-busy> dobey: si ?
[00:01] <wtay> hmm
[00:01] <dobey> sup?
[00:01] <wtay> it adds and averages in one pass..
[00:01] <omega_> for which?
[00:01] <wtay> all
[00:02] <omega_> I mean, during mcomp or elsewhere?
[00:02] <wtay> during mcomp
[00:02] Ow3n (ow...@ti...) joined #gstreamer.
[00:02] <omega_> yo
[00:02] <Ow3n> yo
[00:02] <wtay> hi
[00:02] <omega_> wtay: ok, something to add to libcodec somehow
[00:03] <wtay> a huge improvement
[00:03] <omega_> what file is that in?
[00:03] <omega_> recon.c or recon_mmx*.c ?
[00:03] <wtay> hmm yes
[00:03] <omega_> um, ok
[00:03] <wtay> I first dit this with macros and then hand optimised the gcc output
[00:04] <omega_> hmm, ok
[00:04] <omega_> can you write up the concepts and how they fit into mpeg_play on codecs wiki?
[00:05] <wtay> my mpeg knowledge is not good at all, I have never seen the specs so I might speak rubish
[00:05] <omega_> so? you succeeded in making mpeg_play faster than smpeg
[00:05] <omega_> that counts for a lot
[00:05] <wtay> I merely optimised the existing code :)
[00:05] <omega_> exactly
[00:06] <hds-busy> wtay: full-screen with xvideosink ?
[00:06] <wtay> also, the DCT coef parsing is quite optimised in the decoder.h macros
[00:06] <wtay> hds-busy: for which?
[00:06] <omega_> you mean the vlc decoder?
[00:06] <wtay> DecodeDCTCoeff whatever that is...
[00:06] <omega_> right, vlc decoding
[00:06] <wtay> ok :-)
[00:07] <dobey> vlc sucks, it won't play my dvds
[00:07] <omega_> not videolan client, variable length code
[00:07] <wtay> it also has sparse idct..
[00:07] <dobey> oh
[00:07] <omega_> I'm sure that's an intentional confusion on the part of the vlc guys
[00:07] <omega_> wtay: how did it decide to use sparce idct?
[00:07] <hds-busy> dobey: there are xine debs, so you might grab the sources and give it a try
[00:07] <omega_> on all error macroblocks only?
[00:08] <dobey> hds: it doesn't work on ppc afaik
[00:08] <hds-busy> wtay: for mpeg_play
[00:08] <wtay> omega_ you're asking a lot now... let me see...
[00:08] <dobey> it bitches about not having x86 in ./configure
[00:08] <hds-busy> dobey: does, there are ppc debs with fixes et al
[00:08] <wtay> ParseReconBlock?
[00:08] <hds-busy> dobey: lemme find the mail
[00:09] <wtay> if only one coef was decoded and the position was 0, it's sparse
[00:09] <omega_> um
[00:09] <omega_> that's not even sparse, that'd DC only
[00:09] <omega_> and 'never' happens
[00:09] <wtay> um
[00:09] <omega_> what file/func?
[00:10] <wtay> parseblock.c
[00:10] <omega_> ok, one AC coeff
[00:10] <omega_> interesting
[00:10] <hds-busy> dobey: http://people.debian.org/~daenzer/xine/
[00:11] <wtay> doesn't count for a large speedup boost though
[00:11] <hds-busy> dobey: xine and vlc
[00:11] <dobey> ack
[00:11] <omega_> wtay: any numbers?
[00:11] <dobey> can i get a tarball?
[00:11] <wtay> 1%?
[00:11] <omega_> not bad, considering
[00:11] <omega_> I'm interested in applying every optimization I can get my hands on
[00:11] <hds-busy> dobey: just use alien, or ...
[00:11] <dobey> hrmm, i need libelf sources too
[00:12] <wtay> the biggest optimisation is doing compensation and adding errors in one pass
[00:12] <omega_> hmm, ok
[00:12] <wtay> cache lines etc..
[00:13] <omega_> right, though I wonder if that's a win in the libmpeg case, since it's done macroblock at a time anywy
[00:13] <omega_> mpeg_play decodes the error frame in its entirety, then constructs the reconstructed frame, then sums the two?
[00:14] <hds-busy> dobey: the links to the sources are at the bottom
[00:14] <dobey> xine.html?
[00:14] <dobey> ppc-compat sources?
[00:14] <wtay> the add is just one mmx instruction added to the sum so
[00:14] <hds-busy> yeah, stuck with lynx and no cut'n'paste
[00:14] <hds-busy> dobey: should be
[00:14] <omega_> wtay: is it frame-level?
[00:14] <wtay> frame-level?
[00:14] <dobey> hrmm
[00:14] <dobey> ok
[00:14] <omega_> see above
[00:15] <wtay> oh no
[00:15] <wtay> one mb at a time
[00:15] <omega_> hrm, and you get a significant win from that even then???
[00:15] <wtay> hmm?
[00:15] <wtay> I think it works like this:
[00:15] <omega_> the cache should hold things nicely then, though you will see a cycle loss per re-load
[00:16] <wtay> decode error... take reference frames... sum+add error, next mb...
[00:16] <omega_> wow, what kind of % gain?
[00:16] <wtay> no idea x4?
[00:17] <omega_> no, I mean globally
[00:17] <wtay> only the mb at hand is in the cache then
[00:17] <hds-busy> night gang
[00:17] <wtay> cya
[00:17] <omega_> hds-busy: 'night
[00:17] hds-busy (ha...@pc...) left #gstreamer.
[00:17] <wtay> omega_ do I make sense?
[00:18] <omega_> yes, but I don't see how you can get significant (still not quantified) gain with just that
[00:18] <ChiefHighwater> now there's a loaded question
[00:18] Action: omega_ is incredulous, not uncomprehending
[00:18] <omega_> ChiefHighwater: yeah, yeah
[00:18] <wtay> omega_ you decode *all* the errors first and then add them to the two ref frames?
[00:18] <ChiefHighwater> wtay:notice, I'm not asking omega_ that question
[00:18] <omega_> no, I do it mb at a time
[00:18] <wtay> hmm
[00:19] <dobey> combo boxen rule
[00:19] <omega_> I'm wary of the idea that doing avg+sum is that much faster than avg, sum
[00:19] <wtay> you don't have any extra loop overhead..
[00:20] <omega_> I don't have loop overhead anyway, iirc
[00:20] <wtay> and you avoid a load/store pair..
[00:20] <omega_> true
[00:20] <omega_> btw, incsched is working afaict
[00:20] <wtay> cool
[00:20] <omega_> but nego is screwed
[00:20] <wtay> and gstplay too?
[00:20] <wtay> oh
[00:20] <omega_> untested
[00:21] <wtay> ok
[00:21] <omega_> but autoplug is gonna need some changes to work with incsched
[00:21] <omega_> which is why I need you to screw with INCSCHED1 ASAP
[00:21] <wtay> I have a copy checked out and I was about to do that :-)
[00:21] <omega_> updated?
[00:21] <omega_> I merged last night
[00:21] <omega_> and lemme commit some fixes
[00:21] <wtay> I don't have that one yet
[00:22] <wtay> and... after the sse optimisations the decoder was twice as fast..
[00:22] <omega_> yeah
[00:22] <omega_> they help a lot
[00:22] Action: omega_ wants access to a P4 to test out the SSE2 optimizations
[00:23] <wtay> you should consider .s files instead of those macros, gcc adds a lot of crap...
[00:24] <omega_> yes, I want to once I get more familiar with the .s syntax and the required x86 asm supports
[00:24] <wtay> for final optimisations that is...
[00:24] <omega_> ok, update incsched1
[00:24] <omega_> you may need to hack the mp1vid.c file location, I hardcoded it
[00:24] <omega_> tests/mp1vid.c
[00:25] <omega_> and I sent you the output of mp1vid, which should show failed nego of some form
[00:25] <wtay> test dynamic pad connections?
[00:25] <omega_> yup
[00:25] <dobey> sig
[00:25] <dobey> sigh rather
[00:25] <dobey> xine didn't build
[00:25] <wtay> dobey: get a real pc :)
[00:25] Action: wtay ducks
[00:26] <BBB> <g>
[00:26] <dobey> i did
[00:26] <dobey> i don't use any of that legacy intel crap
[00:26] <omega_rr> heh, I thought intel did PCI
[00:26] <omega_> and AGP
[00:27] <dobey> their chips are legacy
[00:27] <dobey> they don't support not sucking ass
[00:27] <omega_> hrm, new way of looking at it <g>
[00:29] <omega_> the problem with avgsum routines is that they have 4 pointers and strides
[00:29] <omega_> or... wait
[00:29] <omega_> just 3, ok
[00:29] <wtay> omega_ sound is bad?
[00:30] <omega_> yes
[00:30] <omega_> stereo/mono mixup, and/or 8/16 mixup
[00:30] <omega_> lemme see if I can determine which
[00:30] <omega_> 8/16
[00:30] <omega_> er, not really
[00:30] <wtay> I'll have to run anyway it to understand the problem...
[00:30] <omega_> stereo seems ok, but there's no 8/16 mixup either
[00:30] <wtay> hmm
[00:31] <omega_> it also pauses a lot
[00:31] <omega_> play,play,play,pause,repeat
[00:31] <wtay> wow
[00:31] <wtay> you're sure the pull works?
[00:31] <omega_> why?
[00:31] <omega_> ooh, it faults at the end, unsurprisingly
[00:31] <wtay> dunno, same buffer pulled twice for example...
[00:32] <omega_> nope
[00:32] <wtay> oh, maybe you don't call gst_pad_connect but set the ->peer pointers right away...
[00:33] <wtay> hmm, can't be...
[00:33] <omega_> do you get any audio at all?
[00:33] <wtay> still compiling :)
[00:33] <omega_> oh
[00:33] <omega_> hrm, well, wait until you run it to see
[00:33] <wtay> docs...
[00:34] Action: BBB is gonna zzzz
[00:34] <BBB> nite all
[00:34] <omega_> darn, I wanted to discuss libcodec avgsum api while it compiled...
[00:34] <wtay> nite
[00:34] <omega_> BBB: later
[00:34] Action: BBB is away: zzz
[00:34] Nick change: BBB -> BB-zZz
[00:34] Nick change: BB-zZz -> BBB-zZz
[00:34] <wtay> I have to sleep too... :(
[00:35] <omega_> darn
[00:35] <wtay> heh: ** ERROR **: GstElement: error in element 'src': opening file "/home/omega/media/AlienSong.mpg"
[00:35] <omega_> ok, well, I'll think about it and give it a try
[00:35] <omega_> yeah, EMESTUPID
[00:35] <wtay> looks like a rate problem
[00:35] <omega_> but what about the pauses
[00:36] <wtay> that's because the audiosink undeflows
[00:36] <omega_> ah, makes sense
[00:36] <omega_> I didn't think it would take that long to decode that it would cause an underflow
[00:36] <omega_> esp since it's threaded
[00:36] <wtay> it does, mpeg1parse syncs on the SCRs
[00:37] <omega_> hrm, ok
[00:37] <omega_> but it can't delay anything can it, or does mad carry timestamps through?
[00:37] <wtay> I think it does..
[00:37] <omega_> so is this a nego problem?
[00:38] <wtay> yes
[00:38] <omega_> well, that'd be your job <g>
[00:38] <omega_> fix it in HEAD if you can reproduce it, I'll merge up <g>
[00:38] <wtay> try osssink and it"ll work
[00:38] <omega_> hrm, ok
[00:38] <omega_> testing
[00:38] <omega_> stop xmms, killall -9 esd
[00:39] <omega_> ooooooh
[00:39] <wtay> esd has a poor set of caps...
[00:39] <omega_> I see
[00:40] <wtay> in fact it doesn't even care about mono/stereo right now...
[00:40] <omega_> grrr
[00:40] <omega_> there's still a pause at startup, as before
[00:40] <wtay> yup
[00:40] <omega_> we need to make sure the player uses a highwater mark on the queue to start the actual player threads and clocks once stuff is full enough
[00:41] <omega_> but incsched works!
[00:41] <wtay> yes, somebody should start the clock..
[00:41] <omega_> or set the origin
[00:41] <wtay> works very well I would say :-)
[00:41] <omega_> yup
[00:42] <wtay> ooh, you add the queue to the thread...
[00:42] Action: wtay drools
[00:42] <omega_> yes
[00:42] <wtay> is that intentional or it doesn't matter where the queue is put?
[00:43] <omega_> doesn't matter
[00:43] <wtay> good
[00:43] <wtay> so...
[00:43] <wtay> it's all currently cothread based, right?
[00:44] <omega_> how do you mean?
[00:44] <wtay> so no real problems when mad (cothreaded) is added
[00:44] <omega_> as long as the incsched does it job, yes
[00:44] <omega_> afaict so far
[00:45] <wtay> imagine creating a stupid pipeline, the scheduler sets it up as chain based.. then you add a loop based element and it is turned into a cothreaded pipeline.. will that be possible?
[00:46] Action: omega_ chats with matth simultaneously
[00:47] <wtay> hmm... /usr/bin/ld: cannot find -ldb
[00:47] <omega_> -devel
[00:47] <wtay> strange...
[00:47] <wtay> rerunning autogen.sh
[00:48] <wtay> pff, full recompile again...
[00:49] <omega_> ok, mad carries timestamps through decode
[00:49] <omega_> good
[00:51] <wtay> I didn't verify that the timestamps actually match the decoded frame as outputed by mad, but..
[00:51] <omega_> heh
[00:51] <omega_> close enough
[00:51] <wtay> it's possible that mad buffers a frame..
[00:51] <omega_> yeah
[00:54] <omega_> grr, clocking gets in my way
[00:54] <wtay> that's odd I don't have libdb...
[00:54] <omega_> whoops
[00:55] <wtay> hmm I have libdb3-dev...
[00:55] Nick change: ajbusy -> ajmitch
[00:56] <wtay> hacked the makefile... now gstplay compiles..
[00:57] <ajmitch> yay
[00:57] <wtay> oops gstplay crashed :)
[00:59] omega_ (om...@qw...) left irc: Ping timeout for omega_[qwest.dsplinux.net]
[00:59] <wtay> hmm, a little bit better with a pipeline as the top element... but still a crasg
[01:00] <wtay> omega_rr: ?
[01:00] <wtay> omega_rr: I always have to have a pipeline as the toplevel bin now, right?
[01:01] <omega_rr> omega_ got disconnected
[01:02] <ajmitch> now his clone is here to take his place?
[01:02] <dobey> hey aj
[01:02] <ajmitch> hi dobey
[01:02] <dobey> <- totally was hacking kick-ass ui stuff earlier
[01:02] <omega_rr> wtay: yeah, you should, but as matth pointed out it's kinda dumb not to have threads for all the elements, in the majority of cases
[01:02] <ajmitch> nice..
[01:03] <dobey> for encompass anyway
[01:03] <wtay> omega_rr: so the toplevel thread in gstplay should simply be put in a pipeline then
[01:03] omega_omicron (om...@qw...) joined #gstreamer.
[01:03] <omega_omicron> yes
[01:03] <ajmitch> encompass isn't in sid...
[01:03] <wtay> ok, will try to fix that tomorrow
[01:04] <wtay> I need sleep now.. cya all
[01:04] <omega_omicron> ok, l8r
[01:04] Nick change: wtay -> wtay-sleeping
[01:04] <dobey> aj: not yet, no
[01:13] <omega_omicron> but /me isn't so sure <g>
[01:13] <omega_omicron> grrr, nevermind
[01:28] herring (se...@nu...) joined #gstreamer.
[01:28] <herring> I'm having difficulties compiling CVS gstreamer
[01:29] <herring> Configure seems to go fine until it starts generating Makefiles
[01:29] <herring> At which point it starts spewing tons of things like:
[01:29] <herring> sed: can't read ./plugins/Makefile.in: No such file or directory
[01:29] <herring> creating plugins/aasink/Makefile
[01:29] <omega_omicron> hmm
[01:29] <omega_omicron> you ran ./autogen.sh ?
[01:29] <herring> Yes
[01:29] <omega_omicron> odd
[01:29] <herring> Which had one minor weirdness
[01:30] <herring> ./autogen.sh: line 60: 14475 Killed                  automake --add-missing
[01:30] <herring> creating cache ./config.cache
[01:30] <omega_omicron> neat
[01:30] <omega_omicron> what version of automake?
[01:30] <herring> When I run automake --add-missing on the commandline it eventually just prints out
[01:30] <herring> "Killed"
[01:30] <omega_omicron> wow
[01:30] <omega_omicron> sh -x automake --add-missing and see what dies
[01:30] <herring> 1.4a
[01:30] Action: omega_omicron has 1.4
[01:31] <omega_omicron> in automake-land, 1.4a is before 1.4, I think
[01:31] <herring> seth@null /gnome-source/gstreamer $ sh -x automake --add-missing
[01:31] <herring> + eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
[01:31] <herring> ++ exec /usr/bin/perl -S automake --add-missing
[01:31] <herring> Killed
[01:31] <omega_omicron> just like 1.3b came before 1.3.x
[01:31] <omega_omicron> wow
[01:31] <herring> give me a second...
[01:31] <omega_omicron> is your perl in one piece?
[01:31] <herring> I *think* so
[01:32] <herring> I use Debian, so its excercised pretty heavily by debconf
[01:32] <herring> And other autogens work just fine
[01:32] <herring> I just finished building a GNOME source tree a few hours ago w/o problems
[01:33] <herring> Let me try running this with my system automake
[01:33] <herring> Yah, it barfs with automake 1.4 too
[01:39] Nick change: ajmitch -> aj_uni
[01:43] <omega_omicron> hrm
[01:44] <omega_omicron> odd, it sounds like perl is the problem somehow
[01:44] Nick change: omega_omicron -> omega_
[01:44] <omega_> are you Seth @ Ximian, by chance?
[01:46] <Ow3n> herring: What does perl --version say?
[01:50] <Ow3n> omega_: how're things going?
[01:51] <omega_rr> pretty good, getting incsched close
[01:51] <Ow3n> nice. Have there been any devlopments on the netowkring front?
[01:51] <omega_rr> not yet
[01:52] <Ow3n> Is zaheer still working on the RTP sink/src? Come to think of it I havn't seen him around much recently.
[01:53] <omega_rr> yes
[01:53] <omega_rr> he's busy this week
[01:53] <Ow3n> I'm still fighting a battle with bonobo.
[01:53] <Ow3n> I think I'm starting to win though :)
[01:54] <Ow3n> It's kind of tough seeing The Right Way [tm] to do things when there are very few examples.
[01:54] <Ow3n> And those that do exist rely on old implementations.
[01:54] <Ow3n> Evolution is my guide.
[01:55] <omega_rr> whee!
[01:55] <Ow3n> But it has chunks of #if 0 so just when my grep -r finds an example of what I'm looking for, closer inspection reveals it as a red herring
[01:55] <omega_rr> hrm, herring is green on my xchat....
[01:55] <Ow3n> <g>
[01:56] <omega_> speaking of which, he kinda disappeared...
[01:56] <Ow3n> yeah. maybe you scared him off.
[01:56] <Ow3n> maybe he was trying to concele his id
[01:56] <omega_> hehehe
[01:57] <Ow3n> hey. i only just noticed that x-chat expands macros. e.g. 'u' expands to 'you'
[01:57] <omega_rr> yeah, that one can get annoying at times
[01:57] <Ow3n> and there was I thinking you just typed at light speed :)
[01:57] <omega_rr> I do
[01:57] <omega_rr> I haven't added any expansions
[01:58] <omega_rr> but I use tab nick completion heavily
[01:58] <Ow3n> Yeah. I have to admit it actually. you really do type quickly.
[01:58] <Ow3n> hey!!!
[01:58] <Ow3n> I should really read documentation some time!
[01:58] <Ow3n> omega_: this is really neat!
[01:59] <omega_rr> which?
[01:59] <omega_rr> tab completion?
[01:59] <Ow3n> Yeah. I could never figure out how people could ever be bothered to to type out Ow3n all the time.
[01:59] <omega_rr> btw, a project you might like that I want to do: wiki/Gbox
[02:00] <omega_rr> if there were no tab completion, you'd just have to guess who was talking to you all the time <g>
[02:00] <Ow3n> yeah. I saw you talk about Gbox yesterday.
[02:00] <omega_rr> check out the page, and see the NewGboxName node
[02:01] <Ow3n> Ashamed, I have to admit that I always used to hand yupe omega_: every time I aimed a comment at you
[02:01] <omega_rr> wow
[02:02] <omega_rr> thoughts on the propsed new name?
[02:02] <omega_rr> since the idea is still <24hrs old, we can get a jump on changing the name as many times as possible <g>
[02:02] <Ow3n> <g>
[02:02] <Ow3n> Hmmm...
[02:03] <Ow3n> How much do (or will) existing solutions cost?
[02:04] <omega_rr> you mean piecing the hardware together as outlined?
[02:04] <omega_rr> I figure $1000-$1500 depending no caps
[02:04] <omega_rr> er, on caps
[02:04] <Ow3n> Is anyone making them already?
[02:04] <omega_rr> no
[02:04] <omega_rr> I intend to do an incremental prototype (put a G400-TV or somesuch in an existing box, etc.)
[02:06] <Ow3n> I think many people hold the belief that the compiter is already to all-encompasing and that it tries to do too many things.
[02:06] <Ow3n> But I disagree.
[02:06] <Ow3n> Consumer's generally want small boxes that do everything.
[02:06] <omega_rr> the thing is that with convergence the concept of a VCR and a TV and a computer merge so as to make it irrelevant how it's actually implmented
[02:06] <Ow3n> People in the know want to do it themselves the harder, more expensive but in the long run better way.
[02:07] <omega_rr> eventually, I want to see a decent server in the basement with a fiber link receiving live TV, phone lines, ethernet, etc.
[02:07] <herring> Ow3n:  v5.6.0 built for i386-linux
[02:07] <omega_rr> and you have a ethernet-connected TV that *just* displays video
[02:07] <omega_rr> and ethernet-connected amp that *just* outputs audio to speakers
[02:07] <Ow3n> herring: Hmm. Me too. I guess that was a red herring.
[02:07] <omega_rr> and the central machine does the bulk of the work
[02:07] <Ow3n> duh. That was bad.
[02:07] <omega_rr> doh
[02:08] <Ow3n> Right. I see. Actually, I had a similar idea a while ago. But for sound studio e...
 
[truncated message content]