IRC Logs

*******************************************************************
[03:00] jimmy_dean ([email protected]) left irc: "Carrier Signal Lost"
[03:07] ct_ ([email protected]) left irc: Read error: 110 (Connection timed out)
[03:26] sxpert ([email protected]) left irc: Read error: 110 (Connection timed out)
[03:26] sxpert ([email protected]) joined #gstreamer.
[03:27] mxpxpod ([email protected]) joined #gstreamer.
[03:27] <mxpxpod> thomasvs: I figured it out
[03:27] <mxpxpod> I just emulated what rb does
[03:35] AlexCONRAD ([email protected]) got netsplit.
[03:35] mathrick|sleep ([email protected]) got netsplit.
[03:35] taaz ([email protected]) got netsplit.
[03:35] Misirlou ([email protected]) got netsplit.
[03:36] taaz ([email protected]) returned to #gstreamer.
[03:36] AlexCONRAD ([email protected]) returned to #gstreamer.
[03:36] mathrick|sleep ([email protected]) returned to #gstreamer.
[03:36] Misirlou ([email protected]) joined #gstreamer.
[03:40] thaytan ([email protected]) left irc: Read error: 54 (Connection reset by peer)
[03:44] <thaytoo> bye thaytan
[03:46] ct__ ([email protected]) left irc: Client Quit
[03:58] taaz_ ([email protected]) joined #gstreamer.
[03:58] taaz_ ([email protected]) left irc: Remote closed the connection
[03:58] taaz ([email protected]) left irc: "No windows for this server"
[03:59] taaz ([email protected]) joined #gstreamer.
[04:01] <taaz> should structure _n_fields return guint vs gint?  or be renamed to _size like g_hash_table has or _length like g_list or...
[04:02] <taaz> i'm still confused as to best way to access it's data without knowing the field names
[04:02] <taaz> guess i'll just hack something together and hope it doesn't suck ;)
[04:12] <ds-work> use gst_structure_foreach
[04:13] <taaz> yeah i know about that, it's just a pain to do python wrappers for callback-based functions
[04:13] Action: ds-work removed masssink
[04:16] <taaz> is gst-rotten better as a top level module vs in the sandbox?
[04:17] <taaz> i guess it doesn't matter
[04:17] <ds-work> I'd prefer it in the sandbox
[04:17] <ds-work> to me, sandbox is for stuff that isn't expected to work
[04:17] <ds-work> toplevel is for actual projects
[04:18] <taaz> gotcha
[04:26] Action: taaz still doesn't like data/buffer/event code
[04:27] <taaz> should GstData be a boxed type too?
[04:27] jcsston` ([email protected]) joined #gstreamer.
[04:28] <taaz> some py bindings warnings about chain func and so on assuming buffers vs data
[04:29] Nick change: harshy -> harshyBusy
[04:30] <taaz> or is the "appropriate" hack to check in C land if it's a buffer or event and create the correct boxed type there before passing to python handler?
[04:30] <taaz> this all seems rather messy
[04:30] jcsston ([email protected]) left irc: Nick collision from services.
[04:30] Nick change: jcsston` -> jcsston
[04:32] <taaz> it's very non-OO.  switching code paths based on type check... bleh
[04:32] <taaz> am i missing how to do this?
[04:32] <taaz> i think py code would still have to check the type too
[04:35] <mxpxpod> taaz: what are you working on?
[04:36] <taaz> distracting myself from real work
[04:36] <mxpxpod> haha
[04:36] <taaz> python bindings
[04:37] <taaz> there's poor support in there for doing buffer processing in python
[04:37] <mxpxpod> ah
[04:37] <taaz> which involves callbacks from C into py
[04:37] <taaz> which used to be GstBuffers but are now GstData
[04:38] <mxpxpod> I've been working on gstmm for a few days now
[04:38] <taaz> and i'm just whining about how i don't like the current code ;)
[04:38] <taaz> that's certainly easier than non-C-based bindings
[04:38] <mxpxpod> the current Gst::Object doesn't like spider
[04:39] <taaz> and i'll bet your thread handling code is easier too ;)
[04:39] <mxpxpod> not sure
[04:39] <mxpxpod> I don't think I've gotten that far ;)
[04:39] <mxpxpod> brb
[04:39] Action: mxpxpod goes to grab Stroustrup
[04:39] <taaz> the python stuff is horribly difficult to grok imho
[04:39] <taaz> python threading stuff that is
[04:40] <mxpxpod> I'm trying to figure out how to handle variable argument lists
[04:40] <mxpxpod> :D
[04:41] <mxpxpod> I've never done it in c++
[04:43] <taaz> so is gstidentity.c written properly?  it's _chain func just casts GstData to GstBuffer and does buffer things on it.  does that fail via segfault if it's not a buffer?
[04:46] <taaz> i guess all the plugins seem to do that
[04:47] <taaz> it looks wrong
[04:48] <mxpxpod> hmm, how do I pass a variable list (...) from one function to another
[04:53] harshyBusy ([email protected]) left irc: "I quit for now"
[04:55] <taaz> mxpxpod: just pass the va_list
[04:55] <taaz> which of course requires a function that accepts a va_list
[04:56] <mxpxpod> taaz: yeah, that's the problem
[04:56] <taaz> hopefully there are va_list versions for most ... functions
[04:56] <taaz> what func?
[04:57] <mxpxpod> gst_element_link_many
[04:59] <taaz> that's a convenience function anyway
[04:59] <mxpxpod> yeah, I know
[04:59] <mxpxpod> I guess I could implement it in c++ ;)
[05:00] <taaz> or suggest a patch for the valist version
[05:01] <mxpxpod> hmm, I guess I could do that ;)
[05:07] <taaz> it's just a simple loop though...
[05:07] <mxpxpod> yeah, I know
[05:07] <taaz> well, sort of
[06:02] <taaz> should structure_foreach pass self to the func?
[06:09] sub_pop ([email protected]) joined #gstreamer.
[06:10] Rotty ([email protected]) left irc: Remote closed the connection
[06:27] sub_pop ([email protected]) left irc: "Client exiting"
[06:47] Underdog ([email protected]) joined #gstreamer.
[06:50] harshy ([email protected]) joined #gstreamer.
[06:52] thaytoo ([email protected]) left irc: "home"
[07:12] sub_pop ([email protected]) joined #gstreamer.
[07:33] ChrisHJW ([email protected]) joined #gstreamer.
[07:51] steveb__ ([email protected]) left irc: Remote closed the connection
[08:00] Nick change: mathrick|sleep -> mathrick|Uni
[08:15] ChrisHJW ([email protected]) left irc: 
[08:23] foser_ ([email protected]) joined #gstreamer.
[08:23] foser_ ([email protected]) left irc: Client Quit
[08:37] sub_pop ([email protected]) left irc: "Client exiting"
[08:38] kmaraas ([email protected]) left irc: "Leaving"
[08:48] somex1 ([email protected]) left irc: "Download Gaim: http://gaim.sourceforge.net/"
[08:49] sub_pop ([email protected]) joined #gstreamer.
[08:53] thaytan ([email protected]) joined #gstreamer.
[08:53] jcsston ([email protected]) left irc: Read error: 110 (Connection timed out)
[09:06] sub_pop ([email protected]) left irc: "Client exiting"
[09:12] Company ([email protected]) joined #gstreamer.
[09:33] thaytan ([email protected]) left irc: Read error: 113 (No route to host)
[09:34] thaytan ([email protected]) joined #gstreamer.
[09:42] Company ([email protected]) left irc: Remote closed the connection
[09:46] AlexCONRAD ([email protected]) left irc: Client Quit
[09:46] KoRnouille ([email protected]) joined #gstreamer.
[09:49] <KoRnouille> hello
[09:50] <KoRnouille> thomasvs: should I send you the failing make output on your mail ? (failed because of mad)
[09:51] <KoRnouille> i guess I will...
[09:55] <KoRnouille> mail sent.
[10:13] thomasvs ([email protected]) left irc: Read error: 60 (Operation timed out)
[10:17] dolphy ([email protected]) joined #gstreamer.
[10:20] wheels ([email protected]) left irc: "work"
[10:21] steve_b ([email protected]) joined #gstreamer.
[10:21] thaytan ([email protected]) left irc: Remote closed the connection
[10:22] thaytan ([email protected]) joined #gstreamer.
[10:23] Action: KoRnouille wonders why when he videocrops an mpeg file the video is all green
[10:27] jdahlin ([email protected]) joined #gstreamer.
[10:28] <dolphy> morning
[10:30] <KoRnouille> morning dolphy
[10:30] <KoRnouille> :)
[10:30] <KoRnouille> dolphy, any idea why my video gets green ?
[10:30] <jdahlin> morning
[10:31] <dolphy> KoRnouille: are you using 0.7 ?
[10:31] <KoRnouille> yes !! :)
[10:31] <KoRnouille> finally, I got it to work
[10:34] <dolphy> good
[10:38] <KoRnouille> (with all the plugins by the way)
[10:38] <KoRnouille> well, all I need... not juste the core... lol
[10:40] thomasvs ([email protected]) joined #gstreamer.
[10:48] <thomasvs> KoRnouille: I don't know what to say about mad - I see no reason why it would fail.  we already checked if your mad.h header has the symbol, and it does
[10:48] <KoRnouille> thomasvs: humm...
[10:50] Jara[zZ] ([email protected]) left irc: Remote closed the connection
[10:51] <dolphy> thomasvs: yesterday i started to think about adding tag informations coming from decoders
[10:51] <dolphy> thomasvs: to inform about video/audio codecs used in a pipeline
[10:51] <dolphy> thomasvs: you have anything started or ideas on that ?
[10:53] <thomasvs> there's not much to think about that - the demuxer should just fire off a tag with the codec name
[10:53] <thomasvs> the flags are there in the core for that
[10:53] <thomasvs> so everything is ready for you to do that
[10:53] Jara[zZ] ([email protected]) joined #gstreamer.
[10:53] <dolphy> the decoder you mean
[10:53] <dolphy> not the demuxer
[10:54] <thomasvs> yeah, depending on who has the info
[11:19] <thaytan> rah, dudez
[11:20] smoke ([email protected]) joined #gstreamer.
[11:21] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[11:23] dolphy ([email protected]) joined #gstreamer.
[11:26] <thomasvs> thaytan: so, does it work again for you ?
[11:27] <dolphy> thomasvs: would be nice if we could do a 0.7.5 release :)
[11:33] <taaz> whee, got structure and taglist foreach working.  gstplay python app can print out tag keys at least.  no values yet though ;)
[11:33] Action: taaz zzz
[11:33] <thomasvs> dolphy: yeah, I agree - but I'm still concerned about clocking
[11:34] <thomasvs> taaz: give some work to jdahlin :)
[11:34] <dolphy> thomasvs: but i can't get gst-totem packages until we have a nice stable release of gst
[11:34] <jdahlin> hmm, maybe I should check out gst-python
[11:35] <taaz> jdahlin: fix player.py to not segfault or puke or print warnings/errors at random ;)
[11:51] <KoRnouille> gst-totem... that's what you told me about yesterday thomasvs for displaying full screen ?
[11:53] <thomasvs> KoRnouille: totem is a media player, it has a gst backend
[11:53] <thomasvs> dolphy: hm, yeah
[11:54] <thomasvs> dolphy: so, what are you saying - you want one today ?
[11:57] <dolphy> thomasvs: no i don't want one today
[11:57] <dolphy> thomasvs: but i m trying to get people to package gst-totem
[11:57] <dolphy> thomasvs: and that's a bit tough without any release
[11:58] <thomasvs> hehe
[11:58] <thomasvs> well, I was hoping to focus on other stuff today, I feel swamped enough already
[12:00] <thaytan> thomasvs: .f.d.o? yes, thank you :)
[12:00] <thaytan> which means I should try and figure out how to cut a release of gst-editor
[12:04] <thomasvs> thaytan: yeah, I'd love a release
[12:05] <thaytan> apparently I'm the maintainer 
[12:05] <thaytan> I only discovered that last weekend :)
[12:09] <thomasvs> haha
[12:09] <thomasvs> on the new site ?
[12:09] <thomasvs> feel free to change YOUR PERSONAL PROJECT PAGE ! :)
[12:10] <thaytan> is that done with commits?
[12:10] Shoragan ([email protected]) joined #gstreamer.
[12:12] <thomasvs> thaytan: yep
[12:12] <thaytan> ok, reading www/HACKING
[12:12] <thomasvs> thaytan: check out the module, change, run make to see if it works locally, then commit
[12:13] tlg ([email protected]) joined #gstreamer.
[12:17] <thaytan> am I supposed to be able to log in to pdx.fd.o?
[12:21] <thaytan> get it
[12:21] <thaytan> got it
[12:23] <thomasvs> thaytan: you don't need to log in to pdx to change the site
[12:24] Action: thomasvs is worried about what thaytan is doing
[12:25] <thaytan> data-get rsyncs from pdx
[12:25] <thaytan> (I might as well have a complete copy)
[12:25] <thomasvs> thaytan: ah, well. maybe
[12:26] <thomasvs> thaytan: depends if you want to do maintenance on the contents of data
[12:26] <thomasvs> thaytan: it's a huge amount of stuff
[12:26] <thomasvs> (650 mb right now :()
[12:26] <thaytan> phwoard
[12:26] <thaytan> that is a lot!
[12:27] <thaytan> I might stop that then :)
[12:29] <thaytan> brb
[12:29] thaytan ([email protected]) left irc: "See y'all"
[12:34] thaytan ([email protected]) joined #gstreamer.
[12:35] thaytan ([email protected]) left irc: Remote closed the connection
[12:37] thaytan ([email protected]) joined #gstreamer.
[12:37] <KoRnouille> mpegdemux can be used for mpeg1 and 2 ?
[12:37] <thaytan> yep
[12:40] <KoRnouille> I don't understand how to use videoscale : gst-inspect videoscale > there are no "Element Properties" like height, width
[12:44] <thomasvs> KoRnouille: it doesn't need properties for that, since the height and width are part of the caps
[12:44] <thomasvs> KoRnouille: so they get decided by the elements around it
[12:44] <KoRnouille> aaah...
[12:45] <KoRnouille> so what should I use to resize ?
[12:45] <thomasvs> what do you want to resize ?
[12:45] <thomasvs> what areyou doing specifically ?
[12:47] <KoRnouille> resize a video that's 352x288 and double it
[12:47] <KoRnouille> or resize at pixels
[12:47] <KoRnouille> resize 640x480
[12:47] <KoRnouille> I though this would work : videoscale method=3 width=640 height=480
[12:47] <thaytan> on gst-launch command line?
[12:47] <KoRnouille> yes
[12:48] <KoRnouille> gst-launch-0.7 filesrc location=$video ! mpegdemux ! { queue ! mpeg2dec ! videoscale method=3 width=640 height=480 ! sdlvideosink }
[12:48] <thaytan> gst-launch videotestsrc ! video/x-raw-yuv,width=352,height=288 ! videoscale ! video/x-raw-yuv,width=640,height=480 ! sdlvideosink 
[12:48] <thaytan> for example
[12:48] <KoRnouille> aaah
[12:49] <KoRnouille> ill try playing with that
[12:49] <thaytan> that's called 'filtered caps'
[12:49] <KoRnouille> ill try to remember
[12:50] <thaytan> no worries
[12:50] <KoRnouille> shoudl I do that inside the {} ? after the mpeg2dec ?
[12:52] <KoRnouille> okay, I've found out
[12:52] <KoRnouille> by the way, that's best to use between sdlvideosink // xvimagesink // xvideosink ?
[12:53] <thomasvs> KoRnouille: xvimagesink is the best supported atm
[12:53] <jdahlin> if your video card supports the xv extension
[12:53] <KoRnouille> okay thomasvs
[12:53] <KoRnouille> nvidia geforce
[12:54] <dolphy> if xvimagesink doesn't work use ximagesink
[12:55] thaytan ([email protected]) left irc: Read error: 60 (Operation timed out)
[12:55] <KoRnouille> darn, I can't play mpeg2
[12:55] <KoRnouille> works fine with mpeg1
[12:55] <KoRnouille> but not mpeg2
[12:56] <dolphy> what's happening ?
[12:56] <KoRnouille> I get a black window
[12:56] <KoRnouille> wait
[12:56] <KoRnouille> getting the error (running between 2 computers)
[12:57] <KoRnouille> ERROR: from element /pipeline0/thread0/mpeg2dec0: Internal GStreamer error: pad problem.  File a bug.
[12:57] <KoRnouille> Additional debug info:
[12:57] <KoRnouille> gstpad.c(2260): gst_pad_set_explicit_caps: /pipeline0/thread0/mpeg2dec0:
[12:57] <KoRnouille> failed to negotiate (try_set_caps returned REFUSED)
[12:57] <KoRnouille> ERROR: from element /pipeline0/thread0/mpeg2dec0: Internal GStreamer error: negotiation problem.  File a bug.
[12:57] <KoRnouille> it's a 720x576 PAL mpeg2 file @ 4mb/s
[12:57] <dolphy> what pipeline ?
[12:58] <KoRnouille> gst-launch-0.7 filesrc location=$video ! mpegdemux ! { queue ! mpeg2dec ! video/x-raw-yuv,width=352,height=288 ! videoscale ! video/x-raw-yuv,width=640,height=480 ! xvimagesink }
[12:58] <KoRnouille> oops
[12:58] <KoRnouille>  video/x-raw-yuv,width=352,height=288 ???
[12:59] <dolphy> lol
[12:59] <KoRnouille> in fact
[12:59] <KoRnouille> I get no error now
[12:59] <KoRnouille> but I still get a black screen
[12:59] <dolphy> gst-launch-0.7 filesrc location=$video ! mpegdemux ! { queue ! mpeg2dec ! ffcolorspace ! videoscale ! video/x-raw-yuv,width=640,height=480 ! xvimagesink }
[13:00] <KoRnouille> I don't need the input size ?
[13:00] <KoRnouille> i still get a black screen adding ffcolorspace
[13:01] <dolphy> and the error ?
[13:01] <KoRnouille> no error
[13:01] <KoRnouille> running... but black
[13:01] <KoRnouille> well, I get that black screen, but it never finishes...
[13:02] <thomasvs> KoRnouille: what is $video in your case ?
[13:02] <thomasvs> KoRnouille: can you paste your exact command line you use ?
[13:02] <KoRnouille> ./pub.mpg
[13:03] <KoRnouille> gst-launch-0.7 filesrc location=$video ! mpegdemux ! { queue ! mpeg2dec ! ffcolorspace ! video/x-raw-yuv,width=720,height=576 ! videoscale ! video/x-raw-yuv,width=640,height=480 ! xvimagesink }
[13:06] <KoRnouille> removing the video/x-raw-yuv,width=720,height=576 works to
[13:07] ensonic ([email protected]) joined #gstreamer.
[13:08] <ensonic> holla amigos
[13:09] Action: KoRnouille is trying to stretch his video at video/x-raw-yuv,width=1280,height=960 for full screen display (using xinerama with 4 PCI cards), but that won't work... it stays on 1 screen only
[13:10] Action: KoRnouille is going out for lunch... 'ill be back in an hour
[13:14] <thomasvs> KoRnouille: if you want to stretch over four pci cards, you need to make sure all cards have an xv port
[13:14] <thomasvs> KoRnouille: chances are, that won't work
[13:15] thaytan ([email protected]) joined #gstreamer.
[13:15] <thaytan> hrmn.
[13:15] <thaytan> hopefully this machine will be a little more stable with its new fan
[13:39] sublett ([email protected]) joined #gstreamer.
[13:48] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[13:50] dolphy ([email protected]) joined #gstreamer.
[14:15] thaytan ([email protected]) left irc: Read error: 113 (No route to host)
[14:16] thaytan ([email protected]) joined #gstreamer.
[14:16] natyaht ([email protected]) joined #gstreamer.
[14:16] thaytan ([email protected]) left irc: Client Quit
[14:17] Nick change: natyaht -> thaytan
[14:21] <KoRnouille> thomasvs: how can I check that ? all my cards are similar : nVidia GeForce 2 MX 400 PCI. The video works on 1. Should work on all, right ?
[14:26] <thomasvs> KoRnouille: what exactly are you seeing ? do you see one screen where you see 1/4 of the video, and three blue screens ?
[14:26] <thomasvs> describe it a little
[14:27] <KoRnouille> I have setup xinerama so I have 1 desktop splited in 4 screens cubic style
[14:27] <KoRnouille> ##
[14:28] Last message repeated 1 time(s).
[14:28] <KoRnouille> when I do  :
[14:28] <KoRnouille> gst-launch-0.7 filesrc location=$video ! mpegdemux ! { queue ! mpeg2dec ! videoscale method=3 ! video/x-raw-yuv,width=120,height=140 ! xvimagesink }
[14:28] <KoRnouille> I get the top left screen displaying the video (not with mpeg2, only mpeg1)
[14:28] <KoRnouille> and all other screens, I just see the desktop
[14:29] <KoRnouille> it's displaying top left in a window (I can see the menu names, and all)
[14:29] Action: KoRnouille will brb
[14:30] <KoRnouille> I mean by "menu name" the title of the window
[14:33] <thomasvs> have you tried resizing the window ?
[14:33] <thomasvs> gst-launch is just a test app, it doesn't know anything about fullscreen and stuff like that
[14:37] <KoRnouille> when the window opens, it's maximized. So I have to unmaximized it to be able to resize it... and I can drag it on all screens
[14:37] <thomasvs> ok, and ?
[14:38] <thomasvs> what happens if you resize it ?
[14:38] <thomasvs> (the maximize on only one screen is a bug/feature of your xinerama setup, has nothing to do with gst-launch)
[14:47] markey ([email protected]) joined #gstreamer.
[14:50] markey ([email protected]) left irc: Client Quit
[14:52] <ensonic> can please anyone fix the gdk_pixbuf plugin failure on make install (I can only fix it temporary but commenting out the $(mkdir_p) $(DESTDIR)$(loaderdir) line)
[14:55] <KoRnouille> thomasvs: when I resize it manually, the mpeg1 shows okay on all screens.
[15:00] <ensonic> GDK_PIXBUF_CONF_DIR and GDK_PIXBUF_LOADER_DIR are both '', I hve not manually selected the plugin to be built
[15:06] <thomasvs> ensonic: it is built automatically if you have the libs, and you need to disable it yourself if you don't want it
[15:07] <thomasvs> ensonic: what exactly is the problem ?
[15:08] <thomasvs> ensonic: from configure.ac:
[15:08] <thomasvs>    GDK_PIXBUF_LOADER_DIR=${libdir}/gtk-2.0/\$GTK_VERSION/loaders
[15:08] <thomasvs>      GDK_PIXBUF_CONF_DIR=${sysconfdir}/gtk-2.0
[15:08] <thomasvs> ensonic: did you build with special flags or something ?
[15:08] <thomasvs> ensonic: because the defaults make it contain at least something
[15:11] <ensonic> thomasvs: no special flags, that is the problem - I daily update from cvs and now it it rebuilding the Makefiles and so on
[15:11] <ensonic> thomasvs: shoehow the build process has choosen to build gdk_pixbuf, but has not set the defaults
[15:12] Action: ensonic should probably rerun the autogen stuff
[15:18] <thomasvs> ensonic: that's always step one if the build fails due to makefile stuff, yeah
[15:19] <ensonic> thomasvs: thats always the thing to avoid here ;-)
[15:32] <KoRnouille> aaaah
[15:32] <KoRnouille> I just understood how to do it !
[15:32] <KoRnouille> but I need programming skillz
[15:32] <KoRnouille> I need to use that live_client.c application
[15:33] <KoRnouille> it's going to take the video, and resize it full screen with no borders...
[15:33] <KoRnouille> but I start it, it's buggy
[15:33] <KoRnouille> I get stuff like :
[15:33] <KoRnouille> (live_client:16734): GLib-GObject-WARNING **: gobject.c:882: object class `GstXVideoSink' has no property named `toplevel'
[15:34] <KoRnouille> I guess it's meant to be used with 0.6 only
[15:34] <KoRnouille> that 0.7 breaks everything
[15:34] <KoRnouille> is my analyzing right ?
[15:35] <dolphy> well the apis have changed
[15:35] <thomasvs> KoRnouille: yeah, the api changes
[15:35] <dolphy> you would need to rework a little the live_client.c
[15:35] <thomasvs> KoRnouille: the live_client example is meant to work against 0.6
[15:35] <dolphy> to make it work with 0.7.x
[15:36] <KoRnouille> yes, I understand the mecanic now...
[15:36] <KoRnouille> I thought I still had to use command line
[15:36] <KoRnouille> but after xinerama it setup, I need that live_client to get the job done...
[15:37] <KoRnouille> so that live_client replaces my command lines I guess, huh ?
[15:37] <KoRnouille> I know how to program a little python
[15:37] <KoRnouille> do you think I could get the job done under python ?
[15:37] <thomasvs> KoRnouille: you might, yeah, but it's hard to say.  the python bindings are still in cvs
[15:38] <KoRnouille> but in python, I've only done some scripting more than programming...
[15:38] <KoRnouille> I don't even know how API works
[15:38] <KoRnouille> libs, and all...
[15:38] <thomasvs> KoRnouille: you should discuss with zeenix to make the example work with 0.7
[15:39] <KoRnouille> apparently, dolphy didn't like the way zeenix writes programms
[15:39] <KoRnouille> :)
[15:44] <KoRnouille> do I have to read what you call the "API Reference" to understand how it works ?
[15:48] <thomasvs> KoRnouille: you can understand live_client just by reading it and then referring back to the stable API docs (for 0.6), yeah
[15:48] <thomasvs> to migrate it to 0.7 you need to figure out how to do the same things using the 0.7 API
[15:48] <KoRnouille> okay... :s
[15:49] <dolphy> videocrop does not take x,y,width,height anymore
[15:49] <KoRnouille> so everything that with Gst* is part of the API, right ? gtk_* i don't need to touch I guess
[15:49] <dolphy> it takes top bottom left right
[15:50] <KoRnouille> yeah dolphy, I figured that out (when playing with command line)
[15:50] <KoRnouille> colorspace is now ffcolorspace ?
[15:50] <thomasvs> not exactly, but consider it like that, yeah
[15:50] <dolphy> why do you want to crop ?
[15:50] <dolphy> what's the goal ?
[15:53] <KoRnouille> I wanna do the same as the videowall stuff
[15:53] <KoRnouille> but I might want to give arguments on the command line for it to be more flexible
[15:54] <KoRnouille> do something like : live_client --crop=X,Y --host=ip
[15:56] <dolphy> libtool gcc `pkg-config --cflags --libs gstreamer-0.7 gstreamer-interfaces-0.7 gnome-desktop-2.0` -o live_client live_client.c
[15:56] <dolphy> KoRnouille: check your mails
[16:02] <ensonic> thomasvs: I rerun autogen (HEAD cvs), gdkpixbugsrc is among the plugins to be build; further I run grep "GDK_PIXBUF" config.log and the defs are still empty :-(
[16:03] Action: ensonic found another bug
[16:06] <KoRnouille> !! dolphy !!
[16:06] <KoRnouille> thanks
[16:07] <KoRnouille> checking...
[16:07] <KoRnouille> /tmp/ccibp8jb.o(.text+0x24): In function `videowindow_realized':
[16:07] <KoRnouille> : undefined reference to `gst_x_overlay_get_type'
[16:07] <KoRnouille> /tmp/ccibp8jb.o(.text+0x3c): In function `videowindow_realized':
[16:07] <KoRnouille> : undefined reference to `gst_x_overlay_set_xwindow_id'
[16:07] <KoRnouille> collect2: ld returned 1 exit status
[16:07] <dolphy> libtool gcc `pkg-config --cflags --libs gstreamer-0.7 gstreamer-interfaces-0.7 gnome-desktop-2.0` -o live_client live_client.c
[16:08] <KoRnouille> ok, sorry
[16:08] <KoRnouille> the server has the same problems ? or that affects only the client ?
[16:09] <KoRnouille> (process:18978): GLib-GObject-WARNING **: gobject.c:882: object class `GstV4lSrc' has no property named `width'
[16:09] <KoRnouille> ** (process:18978): CRITICAL **: file live_server.c: line 34 (main): assertion `GST_IS_ELEMENT (mpg_encoder)' failed
[16:09] <KoRnouille> that's for the server
[16:11] <KoRnouille> something is not clear for me on the videowall howto :
[16:11] <KoRnouille> The bottom-right client:
[16:11] <KoRnouille> gst-launch udpsrc ! mpegdemux video_%02d! { queue ! mpeg2dec ! 
[16:11] <KoRnouille> videocrop x=160 y=120 width=160 height=120 ! videoscale width=640 
[16:11] <KoRnouille> height=480 ! colorspace ! xvideo_sink } 
[16:11] <KoRnouille> Here is a sample command-line for the server:
[16:12] <KoRnouille> gst-launch filesrc location=anympegfile.mpeg ! mpegparse ! udpsink host=192.168.1.255 
[16:12] <dolphy> try the client with that server command line
[16:12] <dolphy> might work
[16:12] <KoRnouille> so the live_server.c replaces this command line ?
[16:13] <KoRnouille> and the live_client.c replaces the "bottom-right client" for example ?
[16:13] <KoRnouille> I would need to have on each PC a compiled version of live_client with the right cropping settings, right ?
[16:13] <thomasvs> ensonic: well, I don't know what to say - it's obviously there in configure.ac
[16:14] <dolphy> KoRnouille: you start to understand
[16:14] <dolphy> KoRnouille: each pc should run a live_client
[16:15] <jdahlin> is there a big difference between udp and tcp for streaming clients?
[16:15] <thomasvs> jdahlin: hehe :) i'll give you a book
[16:15] markey ([email protected]) joined #gstreamer.
[16:15] <jdahlin> thomasvs: I know in theory that it's faster, but what about "real world" applications?
[16:16] <ensonic> thomasvs: I know and I though today I could learn something new about gst and not the configureation mgt :-(
[16:16] <thomasvs> basically, it's a tradeoff between persistent connections/more overhead vs faster processing
[16:16] <KoRnouille> but because the cropping settings are hardcoded in his program, I would need to recompile 4 copies of live_client with respectivly the right cropping stuff
[16:16] <thomasvs> ensonic: well, as long as no one gives us access to a solaris machine so we can help work on problems there, there's not much we can do about that
[16:16] <thomasvs> ensonic: and it's not that hard for you to disable gdkpixbuf if you don't want it
[16:16] <dolphy> KoRnouille: well yeah
[16:16] <dolphy> KoRnouille: but should not be a big deal to make it command line parameters
[16:17] Action: ensonic is reading the spider sources over and over and wonders how this can work at all
[16:17] <KoRnouille> damnit ! I wish I knew programming... i'd make so nice programs :D
[16:17] <thomasvs> KoRnouille: we all wish we could program :)
[16:17] <dolphy> KoRnouille: well i m sorry dude but i won't make more than what i did :)
[16:17] <ensonic> thomasvs: I actually have enabled it in the hope that it sets sensible defaults, as disabling does not work
[16:17] <dolphy> KoRnouille: you ll have to handle the rest
[16:19] <KoRnouille> yeah dolphy, I wasn't counting on you. I'll try to figure out how this works with my tiny python programming skillz and knowledge. Thank you so much for helping me out. It's very kind of you.
[16:21] <dolphy> np
[16:22] <KoRnouille> mpeg2dec : decoding error... :/
[16:25] <KoRnouille> gst.h is the "main door" to access the whole API ?
[16:25] <thomasvs> KoRnouille: have you read the manual ?
[16:26] <KoRnouille> nop. not yet. I was just asking while I was reading that #include <gst/gst.h> line...
[16:27] <thomasvs> hm, if you want to program using gst you really should read the manual first
[16:27] ibsteveog ([email protected]) joined #gstreamer.
[16:27] <KoRnouille> yeah, I know thomasvs
[16:28] <ensonic> KoRnouille: read the developer manual (do not start with the api stuff) and be aware that this is not up-to-date :-)
[16:29] mxpxpod ([email protected]) left irc: "Guns kill people as much as spoons made Rosie O'Donnell fat.."
[16:36] <KoRnouille> ensonic: argh... not up-to-date... never mind, I'll have an idea
[16:37] <ensonic> KoRnouille: still read it as the most concepts described there are not deprecated
[16:37] <KoRnouille> ok
[16:45] Rotty ([email protected]) joined #gstreamer.
[16:47] <KoRnouille> ensonic: Application Development Manual (Read this first) ??
[16:48] <ensonic> KoRnouille: exactly, that covers a lot of the main concepts behind gst
[16:48] <KoRnouille> what's "HEAD" ?
[16:48] <ensonic> KoRnouille: the pwg is for those who want to write plugins ;-)
[16:48] <KoRnouille> I shall read only devel 0.7.4 i guess
[16:48] <ensonic> KoRnouille: its the most recent version
[16:49] <ensonic> and it differs not a lot from 0.7.4 as docs are not updated/completed a lot
[16:49] <KoRnouille> ok
[16:50] <KoRnouille> "Since GStreamer uses GLib 2.0, the reader is assumed to understand the basics of the GObject object model" ... darn...
[16:50] <KoRnouille> lol
[16:50] <ensonic> KoRnouille: just read ahead ...
[16:51] <KoRnouille> yeah, yeah...
[16:51] <KoRnouille> hehe
[16:51] <ensonic> KoRnouille: since GLib is only available for computers, the reader is assumed to understand the basics of ...
[16:52] <KoRnouille> ;)
[16:53] <KoRnouille> thanks to you all for telling me witch way to go...
[16:53] <dolphy> go south... always...
[16:55] sxpert_work ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[16:58] sxpert_work ([email protected]) joined #gstreamer.
[16:59] <KoRnouille> "This tutorial assumes a good understanding of C, and how to create C programs." I guess I'll have to take C lessons. Anyone wants a disciple ? ;)
[17:06] <dolphy> KoRnouille: buy the Kernigan & Richie C book
[17:09] <KoRnouille> o'reilly ?
[17:09] <KoRnouille> that's how you learned dolphy ?
[17:10] Nick change: mathrick|Uni -> mathrick
[17:10] <mathrick> re
[17:10] <mathrick> dolphy: s/Richie/Ritchie/, Richie is friend of mine ;)
[17:10] <KoRnouille> could I meet him ?
[17:10] <ensonic> there are enough tutorials for c on the web for free
[17:10] <mathrick> KoRnouille: well, you'll have to travel a little bit :)
[17:11] <KoRnouille> where is he from ?
[17:11] <mathrick> KoRnouille: from Poland, same as me, he lives about 10km from here
[17:11] Action: ensonic belives that studying GObject is a good way to learn C, if one understands that, one will understand everything ....
[17:11] <KoRnouille> aaah poland. I had my girlfriend out there...
[17:12] <KoRnouille> that's a 2 hours plane. :)
[17:12] <mathrick> KoRnouille: really, don't even look at anything else than K&R book, you won't find anything better
[17:12] <KoRnouille> really ?
[17:13] <mathrick> KoRnouille: yep, it's the programming best book known to man :)
[17:13] <KoRnouille> everybody told me o'reilly had good ones... anyway, maybe it's published on o'reilley
[17:13] Action: mathrick fanboys K&R
[17:13] <KoRnouille> but can you really become a programer from books ? Or di you need to learn at school ?
[17:13] <mathrick> KoRnouille: don't know, I can only give you name of publishing house that did polish edition :)
[17:14] <mathrick> KoRnouille: you can, if you practice enough
[17:14] <KoRnouille> ok mathrick
[17:14] <sublett> KoRnouille: http://cm.bell-labs.com/cm/cs/cbook/index.html
[17:16] <KoRnouille> thanks
[17:17] <ensonic> KoRnouille: developing is the only way to learn it and the more you practice to more you will laugh about the code you wrote years ago :-)
[17:18] <KoRnouille> I guess so... i'm already laughing about my scipting bash code I wrote 1 year ago (1 year ago, I had my 1st linux installation)
[17:18] dilinger ([email protected]) left irc: "Terminated with extreme prejudice - dircproxy 1.0.5"
[17:20] <KoRnouille> mathrick: would your friend send me a free copy dedicated in french ? ;p
[17:20] <KoRnouille> j/k
[17:21] <mathrick> KoRnouille: ahh, no, he's not the guy who wrote it :)
[17:21] <KoRnouille> huh ?
[17:21] <KoRnouille> wrote it in french you mean
[17:21] <KoRnouille> ;)
[17:21] dilinger ([email protected]) joined #gstreamer.
[17:22] <dolphy> mathrick: ok :)
[17:23] <bitshifter> KoRnouille: there's also "The GNU C Programming Tutorial" online somewhere, which isn't too bad either IMHO
[17:23] <mathrick> KoRnouille: hrmpf, you lost me. Ritchie is co-author of K&R, and Richie is my friend
[17:23] <KoRnouille> ok mathrick
[17:24] <KoRnouille> ok, well, I read about C a little. Doing these hello world programs
[17:24] <KoRnouille> I understand the concept of doubles, int, etc... (woahh !)
[17:27] <mathrick> KoRnouille: and K&R will help you put it all together into what's called programming skills :)
[17:28] <KoRnouille> okay, they explain you how to structure your programs and all I guesS... not just the syntax
[17:29] <mathrick> KoRnouille: for beginner to intermediate, there's really no book that could even get near K&R in terms of comprehensibilty and ease of understanding
[17:29] <KoRnouille> like, having folders called "include", "libs", 
[17:29] <KoRnouille> ok mathrick, I'll have a look on amazon
[17:29] <mathrick> KoRnouille: yep, although for many years K&R was only syntax reference for C
[17:29] <KoRnouille> does C changes a lot ?
[17:30] <mathrick> KoRnouille: yep, all that too. Actually my first contact with Unix concepts was through K&R :)
[17:30] <mathrick> KoRnouille: it did quite a bit some years ago, but it's reflected in newer editions
[17:32] <KoRnouille> hummf, it's not available on amazon.fr
[17:32] <KoRnouille> :/
[17:32] <KoRnouille> aah there is... (stupid search engine)
[17:32] <mathrick> KoRnouille: what I can't advise you is if you should get french or english version of the book. I personally read it in polish, but it was translated brilliantly, don't know about french edition
[17:33] <KoRnouille> http://images-eu.amazon.com/images/P/2100051164.08.LZZZZZZZ.jpg :)
[17:35] <KoRnouille> they actually created the C language ?
[17:35] <KoRnouille> (K&R) ?
[17:36] <mathrick> KoRnouille: yep
[17:36] <ensonic> thomasvs: when manually enabling the GDK_PIXBUF the options are set properly
[17:36] <mathrick> KoRnouille: humm, polish edition cover was a bit more reserved :)
[17:40] ain ([email protected]) joined #gstreamer.
[17:40] <mathrick> KoRnouille: http://www.wnt.com.pl/wnt/ksiazki.nsf/uid/030128142007CPROS5J8HN5/$FILE/Kernighan%20J4%99zyk%20Ansi%20C.jpg
[17:41] <KoRnouille> that didn't work for me
[17:41] <mathrick> KoRnouille: is the last part of link red?
[17:41] <KoRnouille> yeah
[17:42] <mathrick> it get's interpreted as color code then, which trashes url
[17:45] <thomasvs> ensonic: ok, I'm going to make a small change then, can you test it for me ?
[17:46] <KoRnouille> bough the book
[17:47] <mathrick> KoRnouille: congrats :)
[17:47] jcsston ([email protected]) joined #gstreamer.
[17:47] <KoRnouille> :)
[17:47] <mathrick> hi jcsston
[17:47] <jcsston> lo mathrick
[17:47] <mathrick> how's it going with Gst/Win32 ?
[17:50] <jcsston> mathrick: nothing new recently, the last problem I ran into was constructing  a pipeline that would do something (besides a simple file copy). besides that I have not made any progress
[17:50] <thomasvs> jcsston: file copy works already ?
[17:50] <KoRnouille> going home
[17:50] <thomasvs> jcsston: then something like mp3 or ogg decoding should work too
[17:51] <KoRnouille> see ya tomorrow
[17:51] Action: KoRnouille is away
[17:51] Action: thomasvs is already surprised copy works
[17:52] markey ([email protected]) left irc: "bbl"
[17:56] Action: mathrick is always scared by length of thomasvs' blog entries
[17:57] <thomasvs> mathrick: yeah, I try to do it more and shorter, but ...
[17:57] <mathrick> thomasvs: I know, I have the same problem here :)
[17:58] Action: mathrick always tries to write things short and dense, and always ends up with gargantual beasts
[18:14] <ensonic> thomasvs: yes, of course
[18:16] jcsston` ([email protected]) joined #gstreamer.
[18:16] jcsston ([email protected]) left irc: Read error: 110 (Connection timed out)
[18:17] yippi ([email protected]) joined #gstreamer.
[18:23] _Jara[zZ] ([email protected]) joined #gstreamer.
[18:26] <ensonic> thomasvs: uhm, now it is actually trying to build the gdk_pixbuf stuff and that fails with a lot of *strange* warnings
[18:28] <thomasvs> ensonic: I haven't changed anything yet :)
[18:29] <ensonic> thomasvs: yes I know, I've just enabled to build it and so the defs are snsible, but now it tries to build it and I get warning such as undefined "GST_CAPS_NEW"
[18:29] <thomasvs> that must be something else wrong
[18:29] <thomasvs> ensonic: paste privately please
[18:30] edulix ([email protected]) joined #gstreamer.
[18:32] Jara[zZ] ([email protected]) left irc: Read error: 110 (Connection timed out)
[18:32] Nick change: _Jara[zZ] -> Jara[zZ]
[18:33] <thomasvs> ensonic: let's back up a little first
[18:34] edulix_ ([email protected]) joined #gstreamer.
[18:34] edulix_ ([email protected]) left irc: Client Quit
[18:34] <thomasvs> a) there are two things in the gdk_pixbuf dir; one is an element using gdkpixbuf to load stuff to gst; the other is a gdk_pixbuf loader that uses gstreamer to load pixbufs for gtk
[18:35] <thomasvs> b) the first is built if you have the right deps, unless you turn it off
[18:35] <thomasvs> c) the second is not built, even if you have the right deps, unless you turn it on
[18:35] <thomasvs> d) your original problem was what exactly ?
[18:41] <ensonic> thomasvs: when I dont enable it, it was executing the install-loaderLTLIBRARIES: target in the Makefile and in there it calls $(mkdir_p) with an empty path
[18:41] <ensonic> thomasvs: I was not able to find out how that target was generated from looking at Makefile.am
[18:41] edulix ([email protected]) left irc: Client Quit
[18:42] <mathrick> ensonic: btw, http://bugzilla.gnome.org/show_bug.cgi?id=120996
[18:43] <mathrick> ensonic: I think I'll close it now it's been removed
[18:45] kmaraas ([email protected]) joined #gstreamer.
[18:45] spyder482 ([email protected]) joined #gstreamer.
[18:46] <ensonic> mathrick: oh yes
[18:46] <thomasvs> ensonic: ok, so I'm regenerating now to inspect my Makefile, give me a few minutes
[18:47] jcsston` ([email protected]) left irc: Read error: 110 (Connection timed out)
[18:47] <ensonic> mathrick: as replacement a new section with spides should be opened 
[18:47] <mathrick> ensonic: isn't there one already?
[18:47] Action: ensonic stays tuned
[18:47] pb_ ([email protected]) joined #gstreamer.
[18:47] Action: mathrick thinks he read it once
[18:47] <ensonic> mathrick: uhm no
[18:48] <mathrick> ensonic: hmm, lemme see
[18:48] <ensonic> mathrick: oh there is one
[18:48] <ensonic> mathrick: but just from the gst-lauch perspective
[18:48] tromey ([email protected]) left irc: "ciao"
[18:50] <ensonic> mathrick: so maybe the chapters "using autoplugging","using the gstauthoplugcache" should be removed and the "another approach to ..." should be go directly to the "autoplugging page"
[18:50] <mathrick> ensonic: yeah, autoplugging should be killed
[18:51] <mathrick> ensonic: i think I was mistaken, it's still there
[18:51] <mathrick> ensonic: s/autoplugging/autoplugcache/
[18:51] <ensonic> mathrick: I have written a page for the clock chapter (see bugzilla 133057), could you please consider to commit this (its better than the empty page)
[18:51] Jara[zZ] ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[18:51] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[18:52] <mathrick> ensonic: i don't have cvs commit rights, ask thomasvs
[18:52] Jara[zZ] ([email protected]) joined #gstreamer.
[18:54] <thomasvs> ensonic: ok, so on a run of autogen without --enable-gdk-pixbuf-loader ...
[18:54] <thomasvs> ... what does grep GDK Makefile in the toplevel dir say ?
[18:55] <ensonic> thomasvs: it is still running :-(
[18:55] <thomasvs> ok
[18:55] <ensonic> while it runs, would you agree to submit the clock chapter I wrote (bugzilla 133057) for the manual
[18:55] <mathrick> ensonic: I don't think there's much to be added to spider section, it doesn't need anything special besides insterting it into pipeline. I think that just needs to be said explicitly in manual
[18:56] <thomasvs> I don't have time atm, need to get going to belgium in less than an hour
[18:56] <thomasvs> ensonic: I want to resolve the current problem first
[19:00] <ensonic> mathrick: exactly, we should just get ri of the other section and rearrage
[19:00] <ensonic> thomasvs: agreed, I'll hold back my issues until then
[19:00] <ensonic> autogen is nearly ready
[19:02] <ensonic> ready
[19:05] _Jara[zZ] ([email protected]) joined #gstreamer.
[19:10] Jara[zZ] ([email protected]) left irc: Read error: 110 (Connection timed out)
[19:11] <ensonic> ds-work: can you please review bugzilla 134863 (dev-manual changes for double dparams)
[19:16] _Jara[zZ] ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[19:16] apoc ([email protected]) joined #gstreamer.
[19:16] Jara[zZ] ([email protected]) joined #gstreamer.
[19:16] jcsston ([email protected]) joined #gstreamer.
[19:19] invisiblegod ([email protected]) joined #gstreamer.
[19:20] <invisiblegod> does gstreamer-plugins rpm for redhat 9.0 works on fedora's?
[19:20] pb_ ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[19:20] markey ([email protected]) joined #gstreamer.
[19:21] ChrisHJW ([email protected]) joined #gstreamer.
[19:23] <ensonic> ds-work: alive?
[19:26] pb_ ([email protected]) joined #gstreamer.
[19:30] kwm ([email protected]) joined #gstreamer.
[19:34] Uraeus ([email protected]) joined #gstreamer.
[19:34] <Uraeus> hello
[19:34] <jdahlin> hello Mr Schaller
[19:37] <Uraeus> hei jdahlin, so how is your tan coming along?
[19:37] <jdahlin> Uraeus: better than ever
[19:38] <Uraeus> hmm, some guys have all the luck
[19:39] <Uraeus> apoc: did I tell you I played the Shrek2 trailer in gst-player?
[19:39] <thomasvs> ladida
[19:39] <thomasvs> later guys
[19:39] <Uraeus> see ya thomasvs
[19:42] kwm ([email protected]) left irc: Remote closed the connection
[19:42] <ensonic> ciao
[19:43] ensonic ([email protected]) left #gstreamer.
[19:43] <apoc> hi Uraeus
[19:44] <apoc> yes i read that on planet.gnomedesktop.org :)
[19:46] <apoc> Uraeus: I'm going to commit the new monkeysaudio plugin 
[19:46] jdahlin ([email protected]) left irc: "Klienten avslutas"
[19:47] <apoc> Uraeus: there is still a problem with the encoder. But I wonder if we shouldn't remove it like teuf's shn plugin ?
[19:48] pb_ ([email protected]) left irc: "brb"
[19:49] kwm ([email protected]) joined #gstreamer.
[20:01] kwm ([email protected]) left irc: Remote closed the connection
[20:02] jcsston ([email protected]) left irc: Read error: 110 (Connection timed out)
[20:03] thomasvs ([email protected]) left irc: No route to host
[20:12] <taaz> got tag list values printing out now too
[20:12] <taaz> tag list api is funny
[20:13] <taaz> probably should nix the type specific api stuff and just use gvalue api.  or am i missing why you'd want all that code?
[20:16] invisiblegod ([email protected]) left irc: "Leaving"
[20:24] ibsteveog ([email protected]) left irc: "quitting"
[20:26] sublett ([email protected]) left irc: Read error: 113 (No route to host)
[20:28] mathrick ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[20:29] mathrick ([email protected]) joined #gstreamer.
[20:29] thomasvs ([email protected]) joined #gstreamer.
[20:31] pb_ (~pb@2002:5160:45ef:0:240:95ff:fe30:aa84) joined #gstreamer.
[20:34] apoc_ ([email protected]) joined #gstreamer.
[20:36] <Uraeus> apoc, apoc_: the shn plugin isn't removed afaik, and I don't think we should remove the MA plugin either
[20:37] <apoc_> Uraeus: just the encoder 
[20:38] <Uraeus> ah, hmm yeah I guess there is no reason for us to promote encoding in a small and non-free format
[20:38] <apoc_> Uraeus: there is no shn encoder
[20:40] jcsston ([email protected]) joined #gstreamer.
[20:42] wheels ([email protected]) joined #gstreamer.
[20:43] <taaz> ** (process:8976): WARNING **: opt: unlink elements in same group: implement me
[20:43] <taaz> GThread-ERROR **: file gthread-posix.c: line 160 (): error 'Device or resource busy' during 'pthread_mutex_destroy ((pthread_mutex_t *) mutex)'
[20:43] <taaz> aborting...
[20:43] <taaz> what would cause such things?
[20:44] <taaz> i'm assuming python+threads but i don't know what to do about it
[20:45] <taaz> (process:9373): GLib-GObject-CRITICAL **: file gclosure.c: line 421 (g_closure_invoke): assertion `closure->marshal || closure->meta_marshal' failed
[20:45] <taaz> more random badness
[20:46] <taaz> maximum bitrate: 4294967295
[20:46] <taaz> nominal bitrate: 128000
[20:46] <taaz> minimum bitrate: 4294967295
[20:46] <taaz> hmm...
[20:47] <spyder482> not what you expected?
[20:47] <spyder482> :)
[20:47] <thomasvs> taaz: I'd wager they were -1, the max and min
[20:48] <taaz> welll... i just did gvalue -> pyobject and that's what popped out
[20:48] <taaz> maybe something's set as unsigned vs signed
[20:49] <taaz> yeah, ogginfo says those are not set
[20:50] Zeenix ([email protected]) joined #gstreamer.
[20:51] <KoRnouille> hello Zeenix
[20:51] apoc ([email protected]) left irc: Read error: 110 (Connection timed out)
[20:51] <KoRnouille> :)
[20:51] <Zeenix> hi
[20:51] <KoRnouille> staying late tonight
[20:53] <KoRnouille> trying to get you videowall project to work
[20:54] <KoRnouille> thomasvs, u there ?
[20:59] <mathrick> KoRnouille: last time I heard, thomasvs was heading to belgium, don't think he's here :)
[20:59] <KoRnouille> aaah ok
[20:59] <KoRnouille> :)
[20:59] <KoRnouille> I had a question about pads (yeah, Im reading the manual)
[20:59] mxpxpod ([email protected]) joined #gstreamer.
[21:00] <KoRnouille> "elements accept data on their sink pads, and send data out on their source pads"
[21:00] <ds-work> --> ds-work ([email protected]) has joined #gstreamer
[21:00] <KoRnouille> I though it was the other way around
[21:00] <KoRnouille> :/
[21:01] Company ([email protected]) joined #gstreamer.
[21:02] <KoRnouille> well...
[21:02] <KoRnouille> Im trying to analyse the command line
[21:02] <mxpxpod> ds-work: hey!
[21:02] <KoRnouille> when an element has a "sink" in it's name, does it mean it can only be the last part of the pipe ?
[21:03] <mathrick> KoRnouille: yep
[21:03] <mathrick> KoRnouille: and "sinkpad" means data can sink into it - hence the name
[21:03] <KoRnouille> ok... so it does receive data on it's sink...
[21:03] <mxpxpod> mathrick: question:
[21:03] <mathrick> mxpxpod: shoot
[21:03] <mxpxpod> what exactly is the fakesink?
[21:04] <mxpxpod> mathrick: I know that rb uses it to read in the whole file really quickly and get the size of it
[21:04] <mathrick> mxpxpod: it's element that accepts any kind of data (it has ANY caps on sinkpad) and has some additional features like handoff signal
[21:04] <KoRnouille> I thought because it was the last part of the chain (xvimagesink), it would ouput from it's sink, to Xvideo (so data going out)
[21:05] <mxpxpod> mathrick: hmm, I think I'm going to have to make a special class for it
[21:05] <mathrick> mxpxpod: hmm, what for?
[21:05] jcsston ([email protected]) left irc: Read error: 110 (Connection timed out)
[21:05] <mxpxpod> mathrick: so I can have the signal-handoff signal
[21:05] <KoRnouille> but the xvimage element in the pipe really repesents X it's self.
[21:05] <mxpxpod> s/have/connect to/
[21:05] <KoRnouille> right ?
[21:06] <mathrick> mxpxpod: eek? could you clarify?
[21:07] <mxpxpod> mathrick: the fakesink registers it's own signal-handoff signal... that isn't in the Element class, so I can't connect to the signal-handoff signal using just an Element c++ class
[21:07] Action: ds-work needs to remember to add bug numbers to the changelog
[21:08] <mxpxpod> mathrick: make sense?
[21:08] <mathrick> mxpxpod: hmm, no, i don't think that's the way to do this
[21:08] <mathrick> mxpxpod: signals should be wrapped in general way
[21:09] <mxpxpod> mathrick: should I include the signal-handoff signal in the Element class?
[21:09] <mxpxpod> mathrick: each signal is a method of the class in gtkmm
[21:10] <mathrick> mxpxpod: no, there should be a way to do this using GObject, at least I think so
[21:10] <mathrick> mxpxpod: it has probably something to do with closures and marshallers, they were created for that
[21:11] <mxpxpod> mathrick: right, but in order to make it so I don't have to connect to the signal using g_signal_connect, I think I'm going to have to make a child class
[21:12] <mathrick> mxpxpod: hmm, it looks incredibly hackish, making separate binding for each element
[21:12] <mxpxpod> mathrick: I know, but I think it's the only way... I'll have to email the gstmm list and make sure
[21:13] <mathrick> mxpxpod: yeah, I'm not bindings guru myself, you should find someone better qualified for that, taaz for example
[21:13] <mxpxpod> mathrick: heh, ok
[21:17] <Company> yeeeeeeeeeeeha
[21:18] Action: Company listens to QDM2 audio with GStreamer
[21:20] ploum ([email protected]) joined #gstreamer.
[21:20] <Company> via the xine win32 wrappers no less
[21:20] <Company> so i'm using 3 wrappers at once and it still works ;)
[21:21] <mathrick> Company: heh :)
[21:21] <mathrick> Company: you're wrapping plugins only, not xine-lib itself?
[21:21] ploum ([email protected]) left irc: Client Quit
[21:23] jcsston ([email protected]) joined #gstreamer.
[21:23] <Company> mathrick: i need xine-lib to wrap the plugins
[21:23] <Company> mathrick: but i'm wrapping the plugins only
[21:24] <mxpxpod> are most sinks and such subclasses?
[21:24] <mathrick> Company: hmm, so you're calling xine-lib in your wrapper? didn't find a way to do it otherwise?
[21:25] <KoRnouille> <mathrick> KoRnouille: and "sinkpad" means data can sink into it - hence the name
[21:25] thomasvs ([email protected]) left irc: Read error: 110 (Connection timed out)
[21:25] <KoRnouille> as im not a very good english speaker, I don't know this word. :)
[21:26] <Company> mathrick: yes, why would i want to work around xine-lib anyway?
[21:26] thomasvs ([email protected]) joined #gstreamer.
[21:27] <mathrick> KoRnouille: sink is something you have in your bathtub for example, it's the hole water gets in :)
[21:27] <KoRnouille> aaaah !
[21:27] <KoRnouille> :)
[21:27] <KoRnouille> gstreamer is just like plumming... :)
[21:27] <KoRnouille> pipes, flow, etc...
[21:27] <mathrick> Company: well, we're interested in plugins only, not in services offered by xine-lib
[21:28] teuf ([email protected]) joined #gstreamer.
[21:28] <teuf> hi
[21:28] <Company> mathrick: not really
[21:28] <mathrick> KoRnouille: yeah, it's the naming scheme origin I think :)
[21:28] <mathrick> yo teuf
[21:28] <Company> mathrick: xine offers plugin management stuff and the generic setup
[21:29] <mathrick> Company: what do you mean by these?
[21:29] <Company> mathrick: xine knows which plugins it has installed for example - so i just ask xine instead of writing my own scanning/loading for xine libs
[21:30] <mathrick> KoRnouille: it's plum_b_ing btw :P
[21:30] <Company> mathrick: xine knows how to setup a xine_stream_t, so i let xine do it
[21:30] <sxpert> mathrick: not plumming ?
[21:30] <mathrick> Company: hmm, ok, and how do you manage to convince xine not to load-demux-decode for example? it's hardcoded to do so
[21:31] <mathrick> sxpert: no
[21:31] edulix ([email protected]) joined #gstreamer.
[21:31] <sxpert> mathrick: hehe
[21:31] <mathrick> Quick definitions (plumming)
[21:31] <mathrick> # (n.) The operation of finding, by means of a mine dial, the place where to sink an air shaft, or to bring an adit to the work, or to find which way the lode inclines.
[21:31] <edulix> hi people, where's the juk guy? I've seen him there other times :P
[21:31] <mathrick> :)
[21:31] <mathrick> edulix: wheels
[21:32] <Company> mathrick: i don't call xine processing functions
[21:32] <jcsston> Could someone give me a gst-lanuch command-line that decompresses a mp3 to a PCM wav file? My current problem in the Gst/Win32 port is I cannot get a useful pipeline to construct, I don't know if I'm running gst-lanuch wrong or something is wrong in the port.
[21:32] <Company> mathrick: or to be more precise: i hijack the part of the processing that I need...
[21:33] <mathrick> Company: ic, and how did you get around plugins happily messing around with internals?
[21:34] <thomasvs> jcsston: filesrc location=... ! mad ! wavenc ! filesink location=....
[21:35] <edulix> mathrick: yeah you're right. wheels or someone, am I the only one with probs accessing to the Juk's homepage ?  (http://www.slackorama.net/oss/juk/)
[21:35] <Company> mathrick: i provided my own "internals" and hope they don't mess around with internals i didn't think of :/
[21:35] <mathrick> Company: ah, heh :)
[21:35] <wheels> edulix: it's moved to http://developer.kde.org/~wheeler/juk/
[21:35] <wheels> erm
[21:36] <wheels> edulix: http://developer.kde.org/~wheeler/juk.html
[21:37] <edulix> wheels: oh thanks for the link. I think that people should be noticed, for example in the gentoo's sysem it still appear the old site 
[21:37] <wheels> edulix: Well, ideally I'll get the domain back, but I had some problems with my old registrar.
[21:38] <edulix> oh I see :)
[21:38] <edulix> so, should I report the new place to the gentoo people, shouldn't I ?
[21:39] <wheels> edulix: sure
[21:39] <wheels> edulix: but the download location hasn't changed
[21:39] <edulix> okey, I'll report it ;)
[21:40] <jcsston> thomasvs: thanks, it's crashing differently now :)
[21:40] ath_ ([email protected]) joined #gstreamer.
[21:41] <ath_> hi
[21:42] <edulix> welcome!
[21:43] Kaetzchen ([email protected]) joined #gstreamer.
[21:43] sublett ([email protected]) joined #gstreamer.
[21:44] <ath_> i'm writing a small app based on gstreamer-0.7
[21:44] alley_cat ([email protected]) left irc: Nick collision from services.
[21:44] Nick change: Kaetzchen -> alley_cat
[21:44] <ath_> and i have a question
[21:45] <ath_> i'm using a simple pipeline like this
[21:45] <ath_> filesrc ! spider ! my_own_sink
[21:45] <ath_> for audio only
[21:46] <ath_> how can I query the exact position of the stream
[21:47] <ath_> with sample-level accuracy?
[21:47] <Company> gst_pad_query (sinkpad, GST_QUERY_POSITION, &format, &result);
[21:47] <ath_> well, I've tried it
[21:47] <Company> gst_element_query (sinkelement, GST_QUERY_POSITION, &format, &result);
[21:47] <Company> the last one should work better
[21:47] <ath_> my_own_sink is a slighly modified fakesink
[21:48] <Company> though i'm not sure POSTION queries work correctly in all decoders yet
[21:48] <ath_> which passes audio data to the main application
[21:48] jimmy_dean ([email protected]) joined #gstreamer.
[21:48] <mathrick> yo jimmy_dean
[21:48] <Company> you could just look at the timestamp of the buffer yyou get from fakesink
[21:48] <jimmy_dean> hey mathrick
[21:49] <jimmy_dean> what's up?
[21:49] <ath_> if i call gst_element_query every time the sink receives data
[21:49] <mathrick> jimmy_dean: nothing in particular, fighting with cvs to CL conversion now :)
[21:50] <ath_> the position remains the same for 5-6 different buffers :(
[21:50] <mathrick> btw, does anyone know a way to pull email addresses out of CVS? sf.net CVS I might add
[21:50] <jimmy_dean> mathrick: ok, cool
[21:50] <Company> ath_: how about just using GST_BUFFER_TIMESTAMP ?
[21:50] <jimmy_dean> mathrick: I haven't been able to touch the equalizer idea since we last talked...school has kept me busy as usual
[21:50] <ath_> well, i'll try it
[21:50] <ath_> thanks
[21:51] <mathrick> jimmy_dean: yeah, that's life...
[21:51] <jimmy_dean> mathrick: yeah, unfortunately...it's got me frustrated though...I really really want to see that get into gstreamer
[21:51] <jimmy_dean> :)
[21:52] <mathrick> jimmy_dean: I myself am trying my best to overcome that and other difficulties and actually work some :)
[21:52] <jimmy_dean> mathrick: excellent...what are you working on?
[21:52] <mathrick> jimmy_dean: so far, there is some progress, not so big i'd wish it were, but something's there
[21:53] <mathrick> jimmy_dean: MMS library and plugin
[21:53] <jimmy_dean> mathrick: ok, so progress is steady but slow?
[21:53] <mathrick> jimmy_dean: yeah, sorta
[21:53] <mathrick> jimmy_dean: still fighting with stupid initial issues, no real code work yet
[21:54] <mathrick> jimmy_dean: cleaning it up, killing xine deps, setting project tree
[21:54] <jimmy_dean> mathrick: excellent...killing xine deps is the best part...can't wait to be free of xine...it's nice but gstreamer is better
[21:56] <jcsston> thomasvs: I don't have the MAD plugin compiled, however changing the command-line some I encoded a PCM WAV to MP3 with the mpegaudio plugin :)
[21:56] <mathrick> jimmy_dean: no, it's boring :) replacing headers, adding stubs, reworking xine specific calls - that kind of deps
[21:56] <mathrick> jcsston: yay, rocks :)
[21:56] <jimmy_dean> mathrick: yeah, but it's necessary work :)
[21:57] <mxpxpod> what is GstInterface a child of?
[21:57] <mathrick> jimmy_dean: and actually, I'm not intending to kill xine completely, I hope they'll switch over to using libified version after it's finished :)
[21:57] <KoRnouille> i'm writing my 1st C lines
[21:57] <KoRnouille> :)
[21:57] <KoRnouille> compiling okay... but I get an error
[21:58] <KoRnouille> I'm trying to print the gstreamer version
[21:58] <jimmy_dean> mathrick: ahh ok
[21:58] <KoRnouille> don't laught : g_print (GST_VERSION_MAJOR);
[21:58] <mathrick> jimmy_dean: although, I'm sure hoping to make gst more attractive :)
[21:58] <mathrick> KoRnouille: ahh, heard of printf ?
[21:58] <KoRnouille> i tried printf
[21:59] <mathrick> KoRnouille: GST_VERSION_* macros are ints, you can't print them right away
[21:59] <jimmy_dean> mathrick: indeed
[21:59] <KoRnouille> ints = integers
[21:59] <KoRnouille> print a number
[22:00] <KoRnouille> I have to put this into a int variable ? and then print the variable ?
[22:00] <mathrick> KoRnouille: yep, you need to do g_print("%d\n", GST_VERSION_MAJOR); do get something useful
[22:00] <KoRnouille> I guess im off topic there
[22:00] <KoRnouille> this is about C, not gstreamer
[22:00] <mathrick> KoRnouille: no, GST_VERSION_MAJOR itself is of type int
[22:01] bluejay ([email protected]) joined #gstreamer.
[22:01] somex1 ([email protected]) joined #gstreamer.
[22:02] edulix ([email protected]) left irc: Client Quit
[22:02] <mathrick> KoRnouille: its value is 0, which is number
[22:02] <KoRnouille> g_print ("%d.%d.%d\n", GST_VERSION_MAJOR, GST_VERSION_MINOR, GST_VERSION_MICRO);
[22:03] <KoRnouille> prints 0.7.4
[22:03] <mathrick> KoRnouille: yeah, that will give you full version
[22:03] Action: KoRnouille is proud
[22:03] <KoRnouille> lol
[22:03] <mathrick> KoRnouille: good work :)
[22:03] <KoRnouille> :P
[22:03] <KoRnouille> okay... going back into my pipes and tubes...
[22:04] <mathrick> thomasvs: btw, in belgium yet?
[22:04] <KoRnouille> so there, basicly, I've been using gstreamer API ?
[22:05] <mathrick> KoRnouille: hmm, I don't think it's much of API yet, but yes, basically you did
[22:05] Action: mathrick wonders if version defines are API
[22:07] Action: KoRnouille should get's mathrick's recommended C book pretty soon
[22:07] <KoRnouille> python is simplier
[22:08] <mathrick> KoRnouille: s/get's/get/, just to nitpick a little :)
[22:08] sublett ([email protected]) left irc: Read error: 113 (No route to host)
[22:08] <mathrick> KoRnouille: yes and no
[22:08] <KoRnouille> what's the diff between g_print and printf ?
[22:09] <mathrick> KoRnouille: it surely is simpler as it gives you much less details to worry about, but it has bit different area of applicability
[22:09] <mathrick> KoRnouille: g_print is basically #defined to be printf
[22:09] <KoRnouille> g_* are defined function of gstreamer, right ? (would function be the right word ?)
[22:09] jcsston` ([email protected]) joined #gstreamer.
[22:10] <ath_> g_* are defined functions of Glib
[22:10] <mathrick> KoRnouille: no, yes
[22:10] <ath_> on which GStreamer is built
[22:10] <KoRnouille> aah.
[22:10] <KoRnouille> now im getting confused...
[22:12] <mathrick> KoRnouille: hmm, i was wrong, g_print isn't #defined to printf, although by default it behaves the same
[22:12] <KoRnouille> for g_print to work, wouldn't I need something like #include <glib.h> ?
[22:12] <mathrick> KoRnouille: yep
[22:12] <KoRnouille> that's what is confusing me right now
[22:13] <ath_> glib.h is #included in gst.h
[22:13] <KoRnouille> aaah, right...
[22:13] Action: KoRnouille looks into gst.h to see how it's done.
[22:14] <KoRnouille> #include <glib.h>
[22:14] <KoRnouille> woow cool !
[22:14] <KoRnouille> so what I said a little eariler wasn't completly false... :)
[22:15] <mathrick> KoRnouille: to confuse you more, actually you could use it even without #include <glib.h>, but that's kinda hacky
[22:16] <KoRnouille> yeah ?
[22:17] sjoerd ([email protected]) left irc: Read error: 110 (Connection timed out)
[22:18] <mathrick> KoRnouille: yeah, compiler would then assume default declaration for unknown function, which is int foo(...); that would be correct enough in this case, and then resolve the symbol at the linking time
[22:18] <KoRnouille> okay, I'll check that out later
[22:18] <mathrick> KoRnouille: what you need necessarily is -l<correct lib>, you achiever that by adding `pkg-config --libs glib-2.0`
[22:18] <KoRnouille> vi /usr/include/glib-2.0/glib/gmessages.h contains the g_print declaration, right ?
[22:19] <mathrick> KoRnouille: emacs /usr/include/glib-2.0/glib/gmessages.h, yes :P
[22:19] <KoRnouille> :/ i know like... 5 commands in vi.
[22:19] jcsston ([email protected]) left irc: Nick collision from services.
[22:19] <KoRnouille> man vi I guess...
[22:19] Nick change: jcsston` -> jcsston
[22:19] <mathrick> KoRnouille: info emacs :)
[22:20] <mathrick> KoRnouille: it's not essential to know about that implicit declarations, but useful
[22:20] <mathrick> KoRnouille: you'll learn things like that in the process
[22:21] <KoRnouille> mathrick: yeah, I guess so. That's what API is there for. You read the API manual. If it says that g_print if to print, you just go for it and print... no need to know how it's done... you supposed it's written correctly to do what it's meant to do.
[22:21] <KoRnouille> s/if to print/is to print/
[22:22] sub_pop ([email protected]) joined #gstreamer.
[22:23] <mathrick> KoRnouille: hmm, not really, I meant things like that not #include'ing <glib.h>, which are consequences of some C intricacies
[22:23] <KoRnouille> i was answering your <mathrick> KoRnouille: it's not essential to know about that implicit declarations, but useful
[22:24] sublett ([email protected]) joined #gstreamer.
[22:24] <mathrick> KoRnouille: yeah, that's C thing, not GLib's
[22:24] <KoRnouille> true.
[22:25] <mathrick> Company: do you feel like CVS guru? ;)
[22:25] <KoRnouille> when I'll know how all this works, I'll write a plugin (dvbsink) to be able to read a file and output on the TV out the DVB cards.
[22:26] <mxpxpod> is spider an element?
[22:26] <Company> mathrick: i'm a code guru (if at all), we have another guru for administrative things (thomasvs)
[22:26] <mathrick> KoRnouille: cool, but you don't need to know everything, just good portion is enough :)
[22:26] <Company> mxpxpod: yes
[22:26] ChrisHJW ([email protected]) left irc: Read error: 60 (Operation timed out)
[22:26] <mathrick> Company: yeah, I know, but hes AWOL apparently
[22:26] <KoRnouille> yeah. Well, I'll have to read about the DVB API also...
[22:26] <mathrick> s/hes/he's/
[22:26] <mxpxpod> Company: hmm, ok... when I make a spider Gst::Element, I get warnings about a non-floating object
[22:26] sjoerd ([email protected]) joined #gstreamer.
[22:27] <KoRnouille> Company: are you one of the gstreamer leader ?
[22:27] <KoRnouille> mathrick: what about you ?
[22:27] <Company> mxpxpod: it's a bit special in that it's a bin, but i have no clue about bindings stuff...
[22:28] <Company> KoRnouille: kind of, yeah
[22:28] <mxpxpod> Company: ok, I'll have to ask the list... thanks, though
[22:28] <mathrick> KoRnouille: no, I'm rather dev wannabe :)
[22:28] <Company> mathrick is one of our work slaves
[22:28] <mathrick> hehe :)
[22:28] <KoRnouille> mathrick: ok
[22:28] <KoRnouille> lol Company
[22:31] <bluejay> Company: as of a few days ago, tagged transcoding was broken
[22:32] <KoRnouille> having "GstElementFactory *factory;
[22:32] <KoRnouille> " is smiliar to the python code "from GstElementFactory import *" ?
[22:32] <bluejay> Company: Someone here told me to tell you; if they already did, sorry
[22:38] <KoRnouille> to have gst-python to work with 0.7.x, can I use the tarball ? or should I use cvs ?
[22:40] <mathrick> KoRnouille: no, it's rather typo and " get in there mistakenly
[22:41] <KoRnouille> well, the other " is gone on the \n
[22:42] <mathrick> KoRnouille: where is that?
[22:43] <KoRnouille> I copied / paste the code from the html in between double quotes "" and at the end of the html code, it grabbed a \n
[22:43] Misirlou ([email protected]) left irc: "asdf"
[22:44] <KoRnouille> i meant to say : <KoRnouille> having "GstElementFactory *factory;" is smiliar to the python code "from GstElementFactory import *" ?
[22:44] <mathrick> KoRnouille: ahh, I get it now
[22:44] <KoRnouille> :P
[22:44] <mathrick> KoRnouille: no, it's something different
[22:45] <mathrick> KoRnouille: it's declaration of variable, something you never do in python
[22:45] Action: mathrick advises KoRnouille to get K&R ASAP, it will be of really good use :)
[22:45] <KoRnouille> yeah... :)
[22:45] <mathrick> KoRnouille: your nick is even similar to K&R :)
[22:46] <KoRnouille> ?
[22:46] <KoRnouille> right
[22:46] <KoRnouille> lol
[22:46] <KoRnouille> my "R" is supposed to be reversed mirrored
[22:46] <KoRnouille> it's a band
[22:46] <KoRnouille> hard rock band
[22:46] <KoRnouille> lol
[22:47] <KoRnouille> and I added the "ouille" witch makes it sound really stupid and frenchy
[22:47] <KoRnouille> http://www.korn.com/images/splash2/kornenter.jpg
[22:47] <mathrick> ah, KoRN, they aren't so "hard" rockers :)
[22:48] <KoRnouille>     KoRn
[22:48] <mathrick> KoRnouille: and s/witch/which/ unless you really meant witch :P
[22:48] <mathrick> hmm, right, KoRn
[22:48] <KoRnouille> is witch the magic lady ?
[22:48] <mathrick> yep
[22:48] <KoRnouille> ok, sorry
[22:49] <mathrick> KoRnouille: don't apologize, it's nothing offensive :)
[22:49] <KoRnouille> mathrick: ur right. This makes me weak.
[22:50] Misirlou ([email protected]) joined #gstreamer.
[22:50] <mathrick> lo Misirlou
[22:50] <KoRnouille> mathrick: i guess my mother really teached me to say magic words always, always... (thank you, sorry, you're welcome)
[22:50] <teuf> is there some way to "follow" an event as it flows through a pipeline for debugging purpose ?
[22:50] <Misirlou> hi mathrick
[22:51] <KoRnouille> teuf: i guess you'll just have to put some g_print everywhere...
[22:51] <teuf> KoRnouille: if you can tell me where "everywhere" is, that's already a first step :)
[22:52] <KoRnouille> teuf: let me read more of the manual, and i'll tell you... :D
[22:52] <mathrick> teuf: maybe some very ugly hacks with signal emission?
[22:53] <teuf> mathrick: gstreamer events are handled using glib event system ?
[22:53] <teuf> glib event == glib signal
[22:53] <KoRnouille> teuf: i'd suggest everytime you buffer things to pass from a src to a sink... i'd read this : http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/manual/html/chapter-buffers-api.html :D
[22:53] <mathrick> teuf: yeah, that's the question...
[22:54] <KoRnouille> well, tell me if Im wrong about that buffer thing...
[22:54] <KoRnouille> buffers are used to move the flow around, right ?
[22:54] <mathrick> KoRnouille: yeah
[22:55] <bitshifter> teuf: what about using --gst-debug-level=5 and   2>&1 | grep -i event  ?
[22:55] <Company> teuf: in a debugger you can break on gst_pad_send_event
[22:56] <KoRnouille> okay, I'll let the others give the solution... ;p
[22:56] <Company> teuf: and it might be a good idea to invent a debugging category just for this - somebody might want to file an enhancement request bug ;)
[22:56] <Company> teuf: (assuming you meant upstream events)
[22:57] <teuf> Company: I'm trying to figure out what happens to tags during transcoding
[22:59] <Company> teuf: ah
[22:59] Action: Company will have a look now, xine is too much fishing in dark waters
[22:59] thaytan ([email protected]) left irc: Read error: 113 (No route to host)
[22:59] <teuf> is there any way to know which kind of event I got from gst_pad_send_event ?
[22:59] jcsston ([email protected]) left irc: Read error: 110 (Connection timed out)
[22:59] <Company> gst_pad_send_event is upstream
[23:00] <teuf> what do you mean exactly by "upstream" ? that it is from the element which sends the event, not the one which receives it ?
[23:01] <Company> upstream are events from sink to source
[23:01] <Company> tag events flow downstream just like buffers
[23:02] <teuf> ah ok
[23:03] ath_ ([email protected]) left irc: Read error: 110 (Connection timed out)
[23:03] ChrisHJW ([email protected]) joined #gstreamer.
[23:04] kwm ([email protected]) joined #gstreamer.
[23:05] thaytan ([email protected]) joined #gstreamer.
[23:10] sublett ([email protected]) left irc: Read error: 113 (No route to host)
[23:13] teuf ([email protected]) left irc: "Client exiting"
[23:19] #gstreamer: mode change '+o Company' by ChanServ!ChanServ@services.
[23:19] thaytan ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[23:21] #gstreamer: mode change '-o Company' by [email protected]
[23:23] thaytan ([email protected]) joined #gstreamer.
[23:25] paper_ ([email protected]) joined #gstreamer.
[23:31] sjoerd ([email protected]) left irc: Remote closed the connection
[23:39] <KoRnouille> well, I'm gone now... enought reading for today
[23:40] <KoRnouille> 23:40 now... time to go back home. lol
[23:40] <KoRnouille> see ya tomorrow all !
[23:40] Action: KoRnouille is gone *
[23:42] sjoerd ([email protected]) joined #gstreamer.
[23:45] <Zeenix> hm.. the vlc people are also using live.com, maybe we should too
[23:45] <Company> live.com ?
[23:46] <Zeenix> Company: live.com provides an RTP/RTSP implementation
[23:46] <Company> aah
[23:46] <Company> we'll use the element someone writes :)
[23:48] <Zeenix> Company: and that someone must be someone who have no problems with C++
[23:49] Uraeus ([email protected]) left irc: "Client exiting"
[23:50] Action: mathrick wonders how's aeyakovyenko's RTP work going
[23:51] <Company> you can remember that name?
[23:51] <Company> thomasvs: ping?
[23:53] <mathrick> Company: yep, remember i'm slavic :) It's just an Ukrainian name with added intials, piece of cake really :P
[23:53] <Zeenix> mathrick: i thought ramon was working on it
[23:54] <mathrick> Zeenix: he has competition it seems :)
[23:55] <Company> the first one to write a working version wins
[23:55] <mxpxpod> working? what about "good"
[23:55] <Company> the one writing a good version can than overtake the first
[23:55] <mxpxpod> haha
[23:55] <Company> or we'll just include both
[23:56] sjoerd ([email protected]) left irc: Read error: 113 (No route to host)
[23:56] <Company> hm, if i'd wrap xine audio sinks, we'd have solaris support
[23:56] <Zeenix> Company: that would be cool
[23:56] <Company> and windows, too
[23:57] <thaytan> GPL only tho
[23:57] <Company> xine wrapped only, too ;)
[23:57] sjoerd ([email protected]) joined #gstreamer.
[23:58] <Company> wrapping xine doesn't work reliably anyway because of those symbol clashes
[00:00] --- Fri Feb 20 2004
[00:04] ChrisHJW ([email protected]) left irc: Read error: 60 (Operation timed out)
[00:07] ChrisHJW ([email protected]) joined #gstreamer.
[00:08] markey ([email protected]) left irc: "nite"
[00:10] Zeenix ([email protected]) left irc: "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of 
[00:15] yippi ([email protected]) left irc: "Client exiting"
[00:15] kwm ([email protected]) left irc: "Leaving"
[00:17] <Company> thaytan: FYI: http://article.gmane.org/gmane.comp.video.xine.devel/7844
[00:26] <Misirlou> Guys, any sense of a timeline for the 0.8.x release?
[00:30] ChrisHJW ([email protected]) left irc: Client Quit
[00:39] mxpxpod ([email protected]) left irc: "Leaving"
[00:47] <Company> 0.8.0 with gnome 2.6
[00:47] <Company> we'll figure out the rest after that ;)
[00:47] <wheels> Holy shit -- (a) a reasonable email from Neil, (b) he's advocating GStreamer.
[00:50] <Company> did you call the ambulance? did you save it? ;)
[00:52] <sxpert> hahaha Q: "How do I know I have a 64 bit version of windows ?" A: "Your wallet's empty"
[00:54] <wheels> (For those that haven't been watching -- "the GStreamer question" finally hit the KDE lists with some degree of force today.)
[00:56] <dilinger> wheels: the question being whether to use it or not?  if someone wrote a c++ wrapper for it, would they be happy?
[00:56] <wheels> dilinger: there already are Qt bindings
[00:57] foser ([email protected]) left irc: "[ I want to believe ]"
[00:57] <mathrick> wheels: link?
[00:57] <wheels> dilinger: the outstanding questions are around (a) the accesibility of the API for KDE developers interested in working on extensions and (b) the Glib requirement.
[00:58] <wheels> mathrick: Well, it's been scattered across kde-core-devel and moved to kde-multimedia -- give me a sec and I'll see if I can find a  good starting point.
[00:58] Action: Company wonders if parrot will kill off .net
[00:59] <Company> the name is certainly much better
[00:59] <ds-work> wheels: what list?
[00:59] <wheels> The thread has been about what to do about MM in KDE 4, but GStreamer has been the only framework really mentioned other than aRts...
[00:59] <ain> lalala
[00:59] <wheels> ds-work: [00:58:25] <wheels> mathrick: Well, it's been scattered across kde-core-devel and moved to kde-multimedia -- give me a sec and I'll see if I can find a  good starting point.
[01:00] <ds-work> there's only one free MM framework
[01:00] <ds-work> unless arts does video
[01:00] <mathrick> ds-work: by some very hackish means it does
[01:00] <wheels> After moving to kde-multimedia:
[01:01] <wheels> http://lists.kde.org/?t=107721265800001&r=1&w=2
[01:01] Last message repeated 1 time(s).
[01:01] <wheels> http://lists.kde.org/?l=kde-multimedia&m=107721463029557&w=2
[01:01] <Company> it depends on what you call "framework" and what you call "free"
[01:01] <wheels> And what you call usable.  :-)
[01:02] <wheels> I mean there are about a dozen projects that would claim to be an OSS media framework.
[01:02] <ds-work> hrm, actually, Helix is "free", but isn't something anyone would want to use as a dependency
[01:02] <ain> > 1. Play Event Sound
[01:02] <ain> > The most important issue is to start playing the event-sound as quickly as
[01:02] <ain> > possible, to give the user better feedback.
[01:02] <ain> Opening /dev/dsp and feeding the data into it should be fast enough, no ?
[01:02] <wheels> This is the thread that turned into the discussion on core-devel: http://lists.kde.org/?t=107696925400003&r=1&w=2
[01:03] Action: ain shudders
[01:03] <ds-work> ffmpeg is sort of a media framework, too, I suppose
[01:03] <Company> mplayer is some sort of framework, too
[01:03] <wheels> ain: Yeah, Alex is a good guy, but he's pretty clueless on some of this stuff and he doesn't do any multimedia development for KDE.
[01:04] <ain> wheels: ahh, the joys of open source projects
[01:05] Action: mathrick dislikes kde-lists web archives interface
[01:05] <ain> "I don't know what I'm talking about, but I'm going to anyway"
[01:05] <wheels> mathrick: yeah, it sucks
[01:05] <wheels> ain: Well, it's more like "aRts sucks -- let's go back to doing things the XMMS way!"
[01:06] <wheels> Here was my most recent post on the topic -- http://lists.kde.org/?l=kde-multimedia&m=107723068110360&w=2
[01:07] <wheels> ain: But also the thing that isn't clear reading from the outside is whose opinions matter.  Like really the decision will be mostly made by ~5 people I would guess.
[01:07] <Company> the framework to first present a imovie competitor wins big
[01:08] Action: wheels kicks iTunes -- apparently still uses ID3v2.4...
[01:08] <wheels> err, ID3v2.2
[01:10] <Company> ds-work: any idea about this:
[01:10] <Company> <^IcE-bOy^> ERROR: Caught a segmentation fault while loading plugin file:
[01:10] <Company> <^IcE-bOy^> /home/javi/garnome/lib/gstreamer-0.7/libgsttextoverlay.so
[01:10] <Company> <^IcE-bOy^>  
[01:10] <Company> <^IcE-bOy^> Please either:
[01:10] <Company> <^IcE-bOy^> - remove it and restart.
[01:10] <Company> <^IcE-bOy^> - run with --gst-disable-segtrap and debug.
[01:11] <wheels> But yeah, this whole thing is kind of playing out the way that I hoped it would.  The debate didn't happen until we're actually in-range of KDE 4 and GStreamer already has some mindshare and recognition in KDE circles.
[01:11] <wheels> (Had the same topic come up 6-12 months ago things would have been quite different.)
[01:12] sxpert ([email protected]) got netsplit.
[01:12] sxpert ([email protected]) returned to #gstreamer.
[01:12] <ds-work> Company: no clue.
[01:13] <ain> well, we can all be thankful that MAS hasn't been mentioned yet
[01:14] <Company> is anyone working on MAS?
[01:14] <ds-work> don't say anything about MAS being C++
[01:15] Action: ds-work considers orphaning the MAS debian packages
[01:16] <wheels> ain: Well, it's been mentioned, but just in passing.  Leon was at the last KDE meeting trying to build up support, but it didn't go very far...
[01:17] <wheels> ain: The two guys working on aRts were initially interested, but Stefan isn't active at all anymore and Matthias doesn't expect MAS to go anywhere.  I didn't like the guy from the beginning.
[01:17] <wheels> (His first question to me was where I work rather than what I work on.)
[01:17] <wheels> (i.e. he cared more about fund raising than development...)
[01:19] <ain> yeah, they're all about getting that cash
[01:20] <Company> ds-work: #define GST_VALUE_HOLDS_CAPS(x)         (G_VALUE_HOLDS(x, GST_TYPE_CAPS))
[01:20] Rotty ([email protected]) left irc: Remote closed the connection
[01:20] <Company> ds-work: that's correct, isn't it?
[01:20] BBB ([email protected]) joined #gstreamer.
[01:21] Action: BBB waves
[01:21] <mathrick> yo BBB
[01:21] <ds-work> Company: I think so, yes
[01:21] <Company> k, i'll commit that then
[01:21] Action: ds-work likes cash
[01:22] <BBB> I hate moneyhandling in the US
[01:22] <mathrick> BBB: judging from your host adress, you keep using the same terminal for net access, don't you? :)
[01:22] <BBB> I hate it I hate it I hate it
[01:22] <BBB> mathrick: no, I just internet from the lab here
[01:22] pmfp ([email protected]) joined #gstreamer.
[01:23] <pmfp> just wanted to say that gstreamer rocks :)
[01:23] <BBB> so I get myself a creditcard, order something online... they just called me: "sorry sir, we cnnot ship to you because your creditcard is not a US card so we cannot validate its amount of money left"
[01:23] <BBB> DAMN!
[01:23] <BBB> I hate toi go
[01:23] <BBB> bt
[01:23] <BBB> bye
[01:23] <BBB> seeyou tomorrow
[01:23] BBB ([email protected]) left #gstreamer.
[01:24] <mathrick> pmfp: that's nice to hear :)
[01:24] <mathrick> damn, that Guillaume Laurent guy is crazy
[01:25] <Company> who's that?
[01:25] <mathrick> As I said, have whatever media framework you like as an possible independant 
[01:25] <mathrick> backend. Don't rely on it directly, it will never be reliable enough.
[01:25] <mathrick> and few posts earlier he said that /dev/dsp is good enough for anything
[01:26] <wheels> mathrick: Actually he's not crazy -- I usually respect him quite a bit.
[01:26] <wheels> mathrick: I think he's wrong here, but he's both a smart guy and an active multimedia developer.
[01:26] <mathrick> wheels: heh, I don't mean really crazy, just his MM ideas in these few posts
[01:27] <wheels> mathrick: (He's actually the maintainer of Rosegarden IIRC)
[01:27] <mathrick> but unless he considers /dev/dsp a "framework", I can't really comprehend his point
[01:27] <pmfp> how do you see what options various plugins have (such as lame)?
[01:27] <pmfp> any docs for that...?)
[01:27] <mathrick> wheels: ahh, that one!
[01:27] <mathrick> pmfp: gst-inspect [plugin-name]
[01:28] Action: mathrick has read his Qt vs. Gtk-- essays quite a lot recently
[01:28] <wheels> mathrick: Well, there's been a lot of confusion over semantics there which is something that I've been trying to clear up.  People are basically mixing the terms "multimedia library", "framework", "backend", "sound server" and "devices" freely without any appropriate meanings.
[01:28] <pmfp> mathrick: bah, I was crusing around gst-inspect-gui, shouldn't trust those bells and whistles!
[01:28] <pmfp> mathrick: cli works fine though, thanks
[01:29] <wheels> mathrick: Yeah, and even on those -- like you have to admit that while he's opinionated he's not exactly dim.
[01:29] <mathrick> pmfp: np, and cli is 10x more usable than gui in case of gst-inspect :)
[01:30] <mathrick> wheels: well, I've never said he's dim, just horribly mistaken on that single case
[01:30] <wheels> mathrick: Well, I guess naturally we would have differing opinions there.  :-)
[01:31] <pmfp> would you recommend using GStreamers threads instead of POSIX? the application will do parallell encodings
[01:32] <mathrick> wheels: it's nothing unusual for really smart people to take strange standpoint in matters you would expect them to behave exactly in opposite, it just happens ;)
[01:32] <mathrick> pmfp: it's differen thing
[01:33] <mathrick> pmfp: GStreamer cothreads aren't user usable threads, it's just internal detail abstracting common scheduling tasks
[01:33] <mathrick> pmfp: in fact, some of cothreads implementations are built on posix threads
[01:33] <pmfp> mathrick: got ya
[01:34] <ds-work> er, not really
[01:34] <ds-work> we have one cothreads implementation
[01:35] <ds-work> cothreads are way to stuff multiple execution contexts into one thread
[01:35] <ds-work> one _real_ thread
[01:35] <mathrick> ds-work: hmm, I thought there were more of them
[01:35] <ds-work> it doesn't really matter where the thread comes from
[01:35] <ds-work> at least, theoretically
[01:35] <ds-work> there used to be another cothreads implementation, but it never actually worked
[01:36] <mathrick> ds-work: and all that gthread vs. opt things, isn't it about cothreads basically?
[01:36] <ds-work> not really
[01:37] <Company> there's no gthread vs opt
[01:37] <ds-work> schedulers need to handle lots of execution contexts
[01:37] <Company> there's opt vs basic and gthread vs omega vs none at all
[01:38] <mathrick> arrgh, I guess i didn't really get it last time :\
[01:38] <Company> there's 2 sschedulers, opt and basic
[01:38] <mathrick> ds-work: ok, and don't they do that using cothreads?
[01:38] <ds-work> schedulers can 1) attempt to minimize the number of contexts they use (opt)
[01:38] <Company> both need to put multiple execution contexts into their thread
[01:38] <ds-work> or 2) stuff a bunch of contexts into a single thread (basicomega)
[01:39] thaytan ([email protected]) left irc: Read error: 54 (Connection reset by peer)
[01:39] <Company> optomega does that, too ;)
[01:39] <ds-work> right
[01:40] <ds-work> so 1) and 2) are orthogonal, really
[01:40] Shoragan ([email protected]) left irc: "Leaving"
[01:40] <pmfp> "ok"
[01:40] <Company> btw: i think with NPTL gthread is faster than omega
[01:40] <pmfp> I think I'll just go with the "old" and proven then :)
[01:41] <mathrick> ds-work: ok, and when cothreads come into play?
[01:41] <pmfp> (i.e. I'm to stupid at 01:42 AM after lots of travelling to grasp all you said)
[01:42] <ds-work> mathrick: cothreads are what stuffs multiple contexts into a single thread
[01:42] <ds-work> mathrick: otherwise, you use a separate thread for each context
[01:42] <pmfp> anyhoo, thanks for a great work
[01:42] <pmfp> buh-bye
[01:42] <Company> bye
[01:42] <mathrick> pmfp: no, it's not that. It's just too funky to understand it, believe me :)
[01:42] <Company> and sorry for confuisng you :)
[01:42] <pmfp> mathrick: hehe, you wish
[01:43] <ds-work> actually, it's not that hard, once you realize that we use "thread" to mean about 7 different things
[01:43] pmfp ([email protected]) left irc: "Leaving"
[01:43] <mathrick> basically, when I use blabla ! { queue ! foo }, do {} create cothread, normal thread, or "it depends" ?
[01:44] <Company> mathrick: normal thread
[01:44] <mathrick> hmm, ok
[01:44] <Company> mathrick: and that normal thread creates a scheduler which creates cothreads (or not, depending on the scheduler)
[01:44] jcsston ([email protected]) joined #gstreamer.
[01:45] <mathrick> Company: ahh, and now, for every elem inside that normal thread, scheduler needs to have context, which can or can not mean cothread ?
[01:46] <Company> mathrick: correct
[01:46] <mathrick> k, now what are these other things called "thread" ?
[01:47] <ds-work> GstThread
[01:47] <ds-work> which is just a Bin that iterates itself
[01:48] <mathrick> ds-work: GstThread == {} ?
[01:48] <ds-work> yes
[01:48] <Company> it's a bin that does what's necessary if you want to put parts of your pipeline into another thread
[01:50] <ds-work> we don't use pthreads directly anymore, do we?
[01:51] <Company> we use gthreads
[01:51] <ds-work> I suppose we could remove the pthread check in configure.ac then
[01:51] <Company> yeah
[01:51] <Company> do we have that?
[01:52] <ds-work> dnl test if we have pthread_attr_setstack; if not use the older calls
[01:52] thaytan ([email protected]) joined #gstreamer.
[01:52] <mathrick> k, what about other thread meanings? so far I can count about 3
[01:53] <ds-work> cothreads, pthreads, threads, GThread, GstThread
[01:53] <Company> cothreads has 4 meanings
[01:53] <ds-work> wingo-cothreads vs. omega-cothreads (not important anymore)
[01:53] <Company> cothreads, gst cothreads, gthread cothreads, opt cothread emulation
[01:54] <Company> (and wingo cothreads, which are removed)
[01:54] smoke ([email protected]) got netsplit.
[01:54] <ds-work> hrm, we don't use posix_memalign(), either
[01:54] <mathrick> Company: could you elaborate more on each of these cothreads?
[01:55] <Company> mathrick: gst cothreads are the gstreamer implementation of cothreads
[01:56] <Company> mathrick: gthread cothreads are a cothreads implementation that uses real gthreads
[01:56] <Company> mathrick: opt uses some workarounds to not need cothreads
[01:57] <mathrick> Company: why does it do that in the first place? Aren't cothreads already supposed to serve purpose of choosing real vs. emulated threads?
[01:58] <mathrick> it == opt
[01:58] <ds-work> why do we have GstMemChunk?
[01:58] <ds-work> why not use GMemChunk?
[01:58] <Company> because GMemChunk is slow
[01:58] <Company> see tests/ somewhere
[01:58] <ds-work> why don't we fix GMemChunk?
[01:58] <Company> ask wtay
[01:58] <Company> -EDUNNO
[01:59] <mathrick> Company: -EDUNNO is @ me ?
[01:59] <Company> mathrick: no, @ ds
[02:00] smoke ([email protected]) got lost in the net-split.
[02:00] <mathrick> Company: so, which one is @ me ?
[02:00] <Company> mathrick: this: not needing cothreads is 1) faster and 2) more portable
[02:01] <taaz> ds-work: i think the resoning in the past was that GstMemChunk needed atomic operators which glib didn't have.  So it couldn't be put in glib at the time.  Does glib have portable atomic ops now?
[02:01] <mathrick> Company: doh! I thought cothreads were created to be faster and more portable
[02:01] <ds-work> taaz: not yet
[02:01] Action: mathrick begins too lose his understanding of cothreads purpose
[02:01] <mathrick> s/too/to/
[02:02] <Company> mathrick: loopsrc ! loopsink
[02:02] <Company> mathrick: what do you to when loopsrc calls gst_pad_push?
[02:02] <ds-work> cothreads (omega/ds-cothreads) used to be very fast compared to lots of threads
[02:02] <mathrick> Company: switch to loopsink?
[02:03] <ds-work> use an implicit queue?
[02:03] <Company> mathrick: and the "switch" is what cothreads try to answer :)
[02:03] <Company> an implicit queue breaks a lot of things as we know already...
[02:03] jcsston ([email protected]) left irc: "VDubMOD watchout TCME is coming!"
[02:04] <mathrick> Company: ok, but why the hell opt works around them?
[02:04] <Company> mathrick: because it's faster and more portable
[02:04] <mathrick> Company: it's doing the same work (being faster / more portable) in 2 places simultanously
[02:04] Action: ds-work wishes GStreamer wasn't designed to pander to broken libraries
[02:05] pmfp ([email protected]) joined #gstreamer.
[02:05] <Company> ds-work: it's not
[02:05] <ds-work> mathrick: basicscheduler uses 1 cothread per element
[02:05] <ds-work> sinesrc ! identity ! fakesink only needs one context
[02:06] <ds-work> since it doesn't have any loop-based elements (essentially)
[02:06] <Company> ds-work: it's good at exposing bugs everywhere because it's the only thing that links all of them into one app
[02:07] <mathrick> ds-work: ok, and will basicscheduler use 1 or 3 contexts ?
[02:07] <Company> 3
[02:08] <ds-work> some of GStreamer's early design was to cater to libraries that went into infinite loops and occasionally called a callback function to deliver a new frame of data
[02:08] <ds-work> including the abomination known as gst_element_yield()
[02:09] <Company> we still have elements that use _yield...
[02:09] <Company> or _interrupt
[02:09] <Company> i never really got the difference
[02:10] <ds-work> speed and mikmod
[02:11] <ds-work> both of which are broken
[02:11] <Company> spider uses interrupt
[02:12] <ds-work> interrupt returns the recommendation of the scheduler
[02:12] <ds-work> yield actually reschedules the element, similar to gst_pad_push()
[02:13] <mathrick> Returns :TRUE if the element should exit its chain/loop/get function ASAP, depending on the scheduler implementation. <-- exit a loopfunc?
[02:14] <Company> a loopfunc is not supposed to run infinitely
[02:14] <ds-work> good loop functions only move one buffer per iteration
[02:14] <Company> it's called that way because the scheduler does while (TRUE) loopfunc;
[02:14] <ds-work> either in or out (or both)
[02:15] <mathrick> hmm, k
[02:15] <Company> bad loopfuncs must set the GST_ELEMENT_INFINITE_LOOP flag (or how it's called)
[02:15] Action: ds-work wishes we'd only use "good" loop functions
[02:16] pmfp ([email protected]) left irc: Remote closed the connection
[02:17] <mathrick> Company: is bad loop the infinite one, or any moving more than one buffer
[02:17] <mathrick> ds-work: btw, isn't the very reason of loopfuncs to be able to move more than one?
[02:18] <Company> mathrick: it's for loopfunctions that don't know the "iteration" concept or can't handle it for some reason, which is normally equal to infinite loops
[02:19] <ds-work> mathrick: nothing stops that ability
[02:19] <mathrick> ds-work: I don't get that
[02:19] <ds-work> mathrick: you can store buffers between iterations
[02:21] <mathrick> ds-work: to be clear, iteration here is whole pipeline iteration (as in gst_bin_iterate())?
[02:22] <ds-work> not necessarily
[02:22] <ds-work> one element iteration
[02:23] <mathrick> ds-work: that means single while (TRUE) loopfunc() run?
[02:23] <ds-work> yes
[02:24] Action: ds-work muses the consequences of implementing chain functions via loop functions
[02:24] <mathrick> huh? isn't chainfunction just handed a buffer?
[02:25] <ds-work> you could quite simply write a loop function that pulls from a sink pad and calls the chain function
[02:26] <mathrick> is it possible to have both chain and loop func?
[02:26] <ds-work> yes, but that's really dumb
[02:27] <ds-work> some of the core elements have the ability to switch between chain and loop functions
[02:27] <mathrick> will chain function ever be called in that situation?
[02:27] <ds-work> which should be removed
[02:27] <ds-work> don't know.  I'd expect the schedulers to do something stupid out of general principle
[02:27] <Company> i want to improve this stuff in 0.9
[02:28] <ds-work> i want to see this stuff improved in 0.9
[02:28] <Company> so an element can implement 3 behaviours: loop, push or pull
[02:28] <Company> and the scheduler is free to chose
[02:28] pb_ (~pb@2002:5160:45ef:0:240:95ff:fe30:aa84) left irc: "Client exiting"
[02:28] <mathrick> hmpf, I think I got enough crack for today, time to sleep ;)
[02:29] <ds-work> why would a scheduler ever choose a loop function?
[02:29] <Company> it wouldn't
[02:29] Nick change: mathrick -> mathrick|sleep
[02:29] <Company> it would only chose it if the other options aren't available
[02:30] <Company> but if you formulate it this way anyone is free to mess with loopfunctions ;)
[02:31] <Company> i especially want to have one thing in 0.9: _every_ function of an element is called from the same cothread
[02:31] <Company> including link, getcaps and change_state
[02:32] <ds-work> um, what if it's an infinite loop element?
[02:33] <ds-work> or that one special element which will not be named that iterates exactly 4 times to parse an entire movie file
[02:33] <Company> so?
[02:34] <ds-work> the cothread will always have an active state running
[02:34] <ds-work> you'll never be able to use the cothread to call any other function
[02:34] <Company> yeah, but you can just call the link function from there
[02:34] <ds-work> how?
[02:34] <Company> sure you will
[02:35] <Company> once you have control (like in gst_pad_push)
[02:35] <Company> you can call a function in there
[02:36] <ds-work> so elements can change state while you're calling gst_pad_push().  That doesn't seem safe
[02:36] <Company> well, in that case you need to be more careful
[02:36] <ds-work> see my comments about pandering to broken libraries
[02:36] <ds-work> same thing goes for broken plugins
[02:37] <Company> it should at least be possible (it doesn't need to be nice though)
[02:37] <Company> like wait until the loop function exits and discard all buffers
[02:38] <Company> though there's not really a reason to allow infinite loops anymore
[02:38] <ds-work> exactly
[02:38] <Company> we don't need it anywhere
[02:39] <ds-work> I think we should force a minimum standard of behavior from plugins so that it is easier to write the core
[02:39] paper_ ([email protected]) left irc: "Byeeez"
[02:40] <ds-work> It would be lots of fun to support all kinds of crappy random behavior from plugins, but I also want to see gstreamer-1.0 before 2010
[02:40] <Company> yeah
[02:40] <Company> if that's something that's not needed and just exists because of crappy coding
[02:40] thomasvs ([email protected]) left irc: Read error: 110 (Connection timed out)
[02:41] <Company> modplug doesn't need it, speed doesn't and asfdemux is just a mess anyway
[02:41] thomasvs ([email protected]) joined #gstreamer.
[02:41] ain ([email protected]) left irc: "leaving"
[02:42] <ds-work> essentially all of the libraries that we use for serious work can be made into well-behaved plugins
[02:42] <ds-work> and the ones that can't, I no longer care about
[02:42] <Company> agreed
[02:43] <ds-work> I'd rather spend my time fixing crappy libraries than writing workarounds in GStreamer
[02:43] Action: ds-work realized he's ranting
[02:49] <taaz> just wait until people starting thinking it's gstreamers fault when media stream exploits appear for libs gst uses
[02:50] <taaz> anyone want to do a security audit of gst and all the libs gst links with? ;)
[02:50] <Company> that's fluendos job
[02:51] <Company> we'll see very fast which libs work and which ones don't if we'll ever get exploits written for us - and the ones that don't will then be thrown out
[02:51] <Company> currently writing exploits for Hurd would probably hit more people...


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click