From: IRC <wt...@us...> - 2003-03-14 06:35:35
|
******************************************************************* [03:02] omega (~om...@om...) left irc: "[x]chat" [03:11] ct_ (~ct...@th...) left irc: Read error: 60 (Operation timed out) [03:13] foser (d0...@22...) left irc: Remote closed the connection [03:27] mrra (~user@63.66.160.74) joined #gstreamer. [03:36] dap (~da...@ip...) joined #gstreamer. [04:16] <Marsupilami23> ok, wake up I wanna talk about something stupid [04:22] <taaz> boo!!! [04:24] <Marsupilami23> :*) [04:25] <taaz> molex has alot of connectors available [04:26] <Marsupilami23> molex? [04:27] ct (~ct...@th...) joined #gstreamer. [04:40] Marsupilami23 (~Mar...@15...) left irc: "I don't wanna grow up, I'm a Toys R Us Kid. There's a million toys at Toys R Us that I can play with!" [04:43] ct (~ct...@th...) left irc: "Client exiting" [05:14] ct (~ct...@th...) joined #gstreamer. [05:49] chillywilly (da...@mk...) left irc: "leaving" [05:57] chillywilly (da...@mk...) joined #gstreamer. [06:20] ct (~ct...@th...) left irc: "Client exiting" [06:35] dap (~da...@ip...) left irc: "sawfish barfed on itself" [06:39] tjansen (~tj...@p5...) left irc: Read error: 110 (Connection timed out) [06:48] ct (~ct...@th...) joined #gstreamer. [06:59] thomasvs_ (~th...@12...) joined #gstreamer. [07:15] thomasvs (~thomas@81.240.81.230) left irc: Read error: 110 (Connection timed out) [07:21] <ct> thomasvs_: hey! [07:23] chillywilly (da...@mk...) left irc: Read error: 54 (Connection reset by peer) [07:27] Nick change: thomasvs_ -> thomasvs [07:32] <thomasvs> hey christopher [07:36] dap (~da...@ip...) joined #gstreamer. [07:38] <ct> thomasvs: how was the meeting last week? [07:45] thomasvs (~th...@12...) left irc: Read error: 60 (Operation timed out) [07:52] tjansen (~tjansen@pD9E21EE5.dip.t-dialin.net) joined #gstreamer. [08:09] chillywilly (da...@mk...) joined #gstreamer. [08:17] ct (~ct...@th...) left irc: "Client exiting" [08:39] ChristianHJW (~cwi...@p5...) left irc: Read error: 110 (Connection timed out) [08:46] thomasvs (~th...@ca...) joined #gstreamer. [08:57] chillywilly (da...@mk...) left irc: "lets see if X likes me..." [09:35] chillywilly (da...@mk...) joined #gstreamer. [09:45] wingo (~wi...@ma...) joined #gstreamer. [09:49] <thomasvs> yo wingo [09:52] <wingo> what up thomasvs [09:52] wingo (~wi...@ma...) left irc: "Client Exiting" [09:53] wingo (~wi...@ma...) joined #gstreamer. [09:54] <thomasvs> ah, the joy of wireless :) [10:02] <taaz> hey, it's a wingo [10:07] <thomasvs> damn damn damn [10:07] <thomasvs> anyone have an idea about a good alsa sound recorder app that can let me choose from devices in the system ? [10:08] <thomasvs> I NEED HELP ! [10:15] <sxpert_work> hello [10:15] <sxpert_work> my bank account went down the drain... [10:17] ChristianHJW (~cwi...@p5...) joined #gstreamer. [10:21] fleif (~le...@ad...) joined #gstreamer. [10:23] BBB (~BB...@ph...) joined #gstreamer. [10:24] <wingo> thomasvs: you mean choose graphically? [10:25] <wingo> and do you want a nice solution or a hacky solution? [10:27] <fleif> wingo: word ! [10:27] <fleif> are you developing ? [10:28] <wingo> hehe, fleif ;) [10:28] <wingo> naw, i'm updating debian [10:28] <wingo> today i only teach 3 periods (of 8) [10:29] <wingo> heard you had a fine frozen time in norway, eh :) [10:29] <fleif> yeah, the boarding was excellent :) [10:29] <fleif> but i'm not such a fan of ryanair / london stansted airport ... [10:29] <wingo> i am trying to learn python and scheme [10:29] <thomasvs> wingo: whichever [10:29] <wingo> ug, airports [10:30] <wingo> thomasvs: you could try jack and jackrec [10:30] <thomasvs> wingo: I have two hammerfalls and I just want to see if it's getting signal in at all [10:30] <thomasvs> wingo: doesn't jack need a fully configured .asoundrc ? [10:30] <wingo> jackd -d alsa -d myalsadevice .... [10:30] <thomasvs> ok, let's give that a try then [10:30] <BBB> fleif: I saw your question on gtk-devel, not really any helpful reply, right? :( [10:30] <wingo> for a hammerfall, possibly. i dunno about all that, yo [10:30] <fleif> BBB: no ... i think i'm goingto try implementing it myself as proof-of-concept and see how that works [10:31] <fleif> code talks louder than words :) [10:31] <thomasvs> wingo: the problem is, I don't find good documentation on the syntax for myalsadevice [10:31] <fleif> ... err something like that [10:31] <wingo> you mean in the asoundrc eg [10:31] <wingo> s/eg/eh [10:31] <wingo> hum, i dunno -- there are a bunch of examples out there, and if you can't find any i'd ask pbd [10:31] <BBB> fleif: since I'm not really a gtk techie I didn't reply onlist, but I guess you could just copy the gtk widget for the [hv]scale and implement an extra if() in the click handler for double clicks that pops up a new (borderless) window with the counter in it [10:32] <fleif> thomasvs: you might check out http://www.othertime.com/help/alsa.php, i've found it very helpful [10:32] <thomasvs> wingo: both :) afaict, the myalsadevice syntax is related to the non-existing .asoundrc [10:32] <wingo> or ask in #lad if anyone's around [10:32] <thomasvs> #lad's pretty much dead everytime [10:32] <BBB> you can also not duplicate any code at all and just do it manually, but that's a bit hacky (I think) [10:32] <thomasvs> but I'll manage [10:32] <fleif> BBB: yeah, i was thinking along those lines [10:32] <wingo> thomasvs: try hw:0 [10:32] <thomasvs> so jackrec has some way of choosing between the 26 input channels ? :) [10:32] <fleif> BBB: i think the manual approach would work better for proof of concept ... i'll write it in python anyway [10:32] <BBB> fleif: great! give me a note when it's finished, I'm willing to help testing it out and fixing it - I'd use it myself too, maybe :) [10:33] <BBB> hm, python? bad thing ;) [10:33] <wingo> that's the first device, no software "plug" layer [10:33] <wingo> jackd -d alsa -d hw:0 -p 1024 -r 48000 -n 2 -R [10:33] Action: fleif plays with pygtk and decides to complete stop writing in c :) [10:33] <BBB> heh, if pygst works, I'd see some use in that yes [10:33] <wingo> (i think -R is realtime, maybe that goes before the -d alsa...) [10:34] <fleif> BBB: yeah, pygst seems to work quite well [10:34] <fleif> i can't figure out how to seek though, but that's because i don't know how to do it in c either [10:34] <wingo> jack was working ok with the latest fixes and the no-cothread scheduler with gst, btw [10:34] <wingo> but not as good as alsaplayer (close though) [10:34] <wingo> probably do to nondeterminisms in the gst mainloop [10:37] <thomasvs> wingo: so, do we have a way of recording in gst from jackd ? [10:38] <thomasvs> hm, getting client segfaults [10:38] <thomasvs> and [10:38] <thomasvs> **** alsa_pcm: xrun of at least 128.487 msecs [10:38] <thomasvs> [10:38] Last message repeated 1 time(s). [10:38] <thomasvs> messages on the server [10:39] <wingo> thomasvs: simpler sol'n [10:39] <thomasvs> (using 0.51 btw) [10:40] <wingo> arecord [10:40] <wingo> (man arecord) [10:40] <wingo> use hw:0 [10:40] <wingo> but really sometime for two hammerfalls you might need asoundrc's... [10:40] <thomasvs> yeah, probably [10:40] <thomasvs> for now I just want to record from line in :) [10:41] Action: thomasvs considers going back to analogue domain [10:43] <thomasvs> wingo: have you tried puredata before ? [10:45] <BBB> fleif: with events - gst_pad_send_event(GstPad *, gst_event_seek_new(blabla)); [10:45] <fleif> BBB: excellent, thanks ! [10:47] <sxpert_work> BBB: hi there [10:52] <BBB> hey sxpert! [10:53] <BBB> how was a'dam? [10:54] <sxpert_work> BBB: nice.. too bad I didn't have 35 EUR ;-) [10:55] <sxpert_work> BBB: *in cash* [10:57] <BBB> 35? [10:57] <BBB> museum? [10:58] <sxpert_work> BBB: no [10:59] <BBB> then what? [11:00] wingo (~wi...@ma...) left irc: Read error: 110 (Connection timed out) [11:00] <sxpert_work> BBB: uh... well... [11:02] <BBB> ? [11:03] Action: BBB kicks the words out of sxpert [11:05] <sxpert_work> BBB: well, one of those girls behind a door with a red light above it ;-) [11:05] <BBB> d'oh [11:06] <BBB> you have those in france as well ;) [11:06] Action: BBB goes back to work now [11:06] <BBB> later! [11:06] Nick change: BBB -> BBB|work [11:07] <sxpert_work> BBB|work: no, that's illegal over here ;-) [11:17] <BBB|work> btw... would it be worthwhile to use some 'multiple display' mechanism in GstBuffers? [11:18] <BBB|work> (I still have to wait 20 minutes before my new sample is ready for use) [11:20] pb_ (~pb...@ds...) joined #gstreamer. [11:24] tjansen_ (~tjansen@80.146.166.42) joined #gstreamer. [11:27] tjansen_ (~tjansen@80.146.166.42) left irc: Remote closed the connection [11:51] Nick change: fleif -> fleif-food [12:02] foser (d0...@22...) joined #gstreamer. [12:05] <thomasvs> s/pdif is teh suck [12:09] <sxpert_work> thomasvs: yep [12:09] <sxpert_work> BBB|work: you have a POV component ? [12:11] yippi (~br...@fl...) joined #gstreamer. [12:13] <thomasvs> pov ? [12:17] <BBB|work> point of view? [12:17] <BBB|work> (what is a point of view component?) [12:17] Nick change: wtay-zZz -> wtay [12:17] <wtay> yo [12:20] <BBB|work> wtay! [12:20] <BBB|work> how was helsinki? [12:20] <wtay> cold [12:20] <BBB|work> no kidding :D [12:20] <wtay> michelle was sick and now I'm sick [12:20] <BBB|work> did you get anywhere near oslo during your trip? [12:20] <wtay> nope [12:21] <BBB|work> awh... hope you'll feel better soon... anyway, next time, try to go to mallorca if you want to miss a summit, mallorca is much nicer than helsinki ;) [12:21] <BBB|work> (and it's warmer, too) [12:22] <wtay> hm, yeah, maybe :) [12:22] <sxpert_work> BBB|work: no, Persistence of Vision (which would explain the 20 minutes per frame ;-) [12:23] <BBB|work> 20 minutes per frame? [12:23] <BBB|work> where did I say that? [12:24] <sxpert_work> wtay: so, what was your final trip ? helsinki, then where ? (we played "where in the world are Wim and Michelle" (aka Carmen San Diego) during the week) [12:24] <sxpert_work> BBB|work: <BBB|work> (I still have to wait 20 minutes before my new sample is ready for use) [12:24] <BBB|work> wtay: oh, and of course your comments on both my GstClock emails to gstreamer-devel are much appreciated... There's some rough edges that might need to be solved then, to prevent duplication of code in each src element, but we'll see about that [12:24] <BBB|work> sxpert_work: oh - at work ;) [12:24] <BBB|work> a chemical sample [12:24] <sxpert_work> BBB|work: ah, ok... [12:24] Action: BBB|work decides it's about time for lunch [12:24] <wtay> sxpert_work: belgium -> helsinki ->belgium [12:25] <wtay> BBB|work: I'll try [12:25] <sxpert_work> wtay: saw anything interesting in "not oslo" ? [12:25] <sxpert_work> BBB|work: thought you were doing some CGI frames [12:26] <wtay> sxpert_work: we had very good meals, walked around in the city [12:26] <BBB|work> sxpert_work: oh, no :) [12:27] <sxpert_work> wtay: ah, heh... you missed on the "swim in the meter-high snow to get to the cabin" part... [12:27] <BBB|work> who's going to do the gstreamer talk @ guadec and what will it be about? [12:27] <thomasvs> I have an idea for a talk, it's in cvs [12:27] <thomasvs> still hoping to get gst to a state to be able to give it though [12:28] <BBB|work> I was thinking of doing a higher level API overview (like gstplay) and describing application development (i.e. separation of elements, components/GUI (bonobo) and the actual main.c etc. [12:28] <BBB|work> since most people will now the lowlevel overview by now [12:28] <BBB|work> don't know if you can actually give a talk about that, but it'd be interesting, "something else" :) [12:29] <wtay> BBB|work: gstreamer allows 1 clock per scheduler, the timestamps are used to indicate where (in time) a buffer relates to 0 (when you start the pipeline) [12:30] abraar (~foo@AToulouse-105-1-23-81.abo.wanadoo.fr) got netsplit. [12:30] chrisime (~chr...@p5...) got netsplit. [12:30] md` (~ill...@p5...) got netsplit. [12:30] Anch|Away (~mgu...@12...) got netsplit. [12:30] chrisime (~chr...@p5...) returned to #gstreamer. [12:30] abraar (~foo@AToulouse-105-1-23-81.abo.wanadoo.fr) returned to #gstreamer. [12:30] Anch|Away (~mgu...@12...) returned to #gstreamer. [12:30] md` (~ill...@p5...) returned to #gstreamer. [12:33] <BBB|work> wtay: ok, I digged into this some more with company last night, he just suggested to let an audio source try to become master clock too. this'll work when (for example) recording to a file or so... if you have both an audio source as well as a sink, one of them becomes the master and the other has to resample or drop audio samples or set a different audio rate... in any case, video adapts to the master clock and drops/inserts frames according [12:33] <BBB|work> ly (vektor disagrees here, btw...) [12:33] <wtay> BBB|work: option B is correct, osssrc should be the clock provider, v4lsrc should sync, detect lag, compesate etc [12:33] <sxpert_work> wtay: hope you'll be there in Dublin/Barcelona and will not end up in Tokyo or something [12:33] <wtay> BBB|work: yes, osssink does things a little different when it is not the clock provider [12:34] <BBB|work> ok, so then osssrc would (ideally) become the master and osssink 'just works'? [12:34] <BBB|work> sounds interesting [12:34] <BBB|work> I'll try to get something done in the next few days/weeks :) [12:34] <wtay> BBB|work: it'll emit QoS events upstream when it cannot keep up [12:34] <wtay> BBB|work: an optinal resample element will try to adjust the rate to balance the different rates [12:35] <BBB|work> ok [12:35] <BBB|work> so osssrc ! resample ! osssink should (in theory) work? [12:35] <wtay> in theory, when it's implemented correctly, yes [12:35] <BBB|work> ok :) [12:36] <BBB|work> well, first off I'll only do video capture to disk anyway, these cases don't really apply there anyway [12:36] <BBB|work> so osssrc already does the master clock stuff? [12:36] <wtay> for multiplay buffers, I think you really mean to add a repeat field to a buffer to indicate that this buffer should be repeated N times [12:36] <BBB|work> then I only have to adapt v4l*src [12:36] <BBB|work> wtay: exactly [12:37] <wtay> problem is that this only makes sense to buffers that contain a single self-contained piece of data (video) [12:37] <BBB|work> true... [12:37] <wtay> doesn't really make sense to repeat an audio or mp3 frame [12:38] <BBB|work> brb, lunch time :) [12:38] <BBB|work> I'll file some bugzilla reports on this later this afternoon [12:39] <wtay> my feeling is that for all this discont detection stuff we need to use the offset field in the buffer but I don't know how exectly, ye [12:39] <wtay> yet [12:54] <sxpert_work> uh, the new _stable_ alsa is out [13:02] Nick change: wtay -> wtay-rest [13:07] Nick change: fleif-food -> fleif [13:12] <fleif> wtay-rest: do you already have a resample element in mind ? [13:47] chrisime_ (~chr...@p5...) joined #gstreamer. [13:52] chrisime (~chr...@p5...) left irc: Killed (NickServ (Ghost: chrisime_!~chr...@p5...)) [13:52] Nick change: chrisime_ -> chrisime [14:08] fleif (~le...@ad...) left irc: "leaving" [14:28] Vakor (ms...@c1...) left irc: Remote closed the connection [14:29] Vakor (ms...@c1...) joined #gstreamer. [15:09] ^iain^ (~ia...@us...) joined #gstreamer. [15:15] md` (~ill...@p5...) left irc: Read error: 110 (Connection timed out) [15:19] md` (~illuminat@pD9E47DD8.dip.t-dialin.net) joined #gstreamer. [15:22] ct (~ct...@13...) joined #gstreamer. [15:38] ct (~ct...@13...) left irc: "Client exiting" [15:51] thaytan (~ja...@ad...) joined #gstreamer. [16:01] ChristianHJW (~cwi...@p5...) left irc: Read error: 104 (Connection reset by peer) [17:06] BBB|work (~BB...@ph...) left irc: "Client exiting" [17:23] Anch|Away (~mgu...@12...) left irc: Read error: 110 (Connection timed out) [18:04] Anch|Away (~mgu...@12...) joined #gstreamer. [18:05] Nick change: Anch|Away -> Anch [18:05] Anch (~mgu...@12...) left #gstreamer. [18:06] Anch (~mgu...@12...) joined #gstreamer. [18:23] yippi (~br...@fl...) left irc: "Client exiting" [18:43] chillywilly (da...@mk...) left irc: "Lost terminal" [18:45] thaytan (~ja...@ad...) left irc: Read error: 113 (No route to host) [19:11] pb_ (~pb...@ds...) left irc: "Client Exiting" [19:18] thomasvs (~th...@ca...) left irc: Read error: 60 (Operation timed out) [19:19] mrra (~user@63.66.160.74) left irc: Remote closed the connection [19:25] chillywilly (~da...@mk...) joined #gstreamer. [19:26] apoc (~ap...@dy...) joined #gstreamer. [19:45] Uraeus (~csc...@x9...) joined #gstreamer. [19:47] <apoc> yo Uraeus [19:48] <Uraeus> hi apoc [19:49] <Uraeus> apoc: managed to get monkeyenc to accept raw audio instead of wav? [19:50] <apoc> Uraeus: I'll take a look at this tonight [19:56] mrra (~user@157.182.195.241) joined #gstreamer. [19:58] Limbo (~csc...@x9...) joined #gstreamer. [20:04] abraar (~foo@AToulouse-105-1-23-81.abo.wanadoo.fr) left irc: Read error: 110 (Connection timed out) [20:06] abraar (~foo@AToulouse-105-1-27-198.abo.wanadoo.fr) joined #gstreamer. [20:10] thomasvs (~th...@12...) joined #gstreamer. [20:11] md` (~illuminat@pD9E47DD8.dip.t-dialin.net) left irc: "Client exiting" [20:12] md` (~illuminat@pD9E47DD8.dip.t-dialin.net) joined #gstreamer. [20:13] md` (~illuminat@pD9E47DD8.dip.t-dialin.net) left irc: Client Quit [20:13] md` (~illuminat@pD9E47DD8.dip.t-dialin.net) joined #gstreamer. [20:15] Uraeus (~csc...@x9...) left irc: Read error: 110 (Connection timed out) [20:18] Limbo (~csc...@x9...) left irc: "Cheerio Cheerio bye bye" [20:29] apoc_ (~ap...@dy...) joined #gstreamer. [20:40] mrra (~user@157.182.195.241) left irc: Remote closed the connection [20:45] ChrisHJW (~chr...@p5...) joined #gstreamer. [20:46] apoc (~ap...@dy...) left irc: Read error: 110 (Connection timed out) [20:55] ChrisHJW (~chr...@p5...) left irc: [20:55] ChrisHJW (~chr...@p5...) joined #gstreamer. [20:57] Nick change: apoc_ -> apoc [21:24] CRPPNA (pwn...@20...) joined #gstreamer. [21:24] CRPPNA (pwn...@20...) left #gstreamer. [21:31] BBB (~BBB@213.160.215.2) joined #gstreamer. [21:33] <apoc> yo BBB [21:34] omega (~om...@om...) joined #gstreamer. [21:34] <omega> more interest from Intel, different group this time... [21:34] <omega> I assume [21:44] mrra (~user@157.182.195.241) joined #gstreamer. [21:45] Company (~Co...@p5...) joined #gstreamer. [21:52] <BBB> hey apoc! [21:52] ds (ds...@co...) left irc: Read error: 104 (Connection reset by peer) [21:52] <BBB> omega: are they gonna hire you? ;) [21:52] <omega> dunno [21:52] <BBB> nonono... you say 'yes' [21:53] <BBB> and then you'll sound selfconfident and they'll hire you and <blabla> [21:53] <omega> it's the guy who wrote the original monolithic scalable media player at OGI, before Quasar [21:53] ds-work (ds...@co...) joined #gstreamer. [21:56] Company (~Co...@p5...) left irc: Remote closed the connection [21:57] <BBB> does anyone know what audio settings to use to embed mp3 in avi? [21:57] <BBB> in avi_strf_auds and strh("auds") [22:02] ds-work (ds...@co...) left irc: Read error: 104 (Connection reset by peer) [22:05] sqtz (~sq...@21...) joined #gstreamer. [22:07] thaytan (jan@202.76.176.22) joined #gstreamer. [22:07] thaytan (jan@202.76.176.22) left irc: Remote closed the connection [22:08] Nick change: wtay-rest -> wtay [22:08] <omega> wtay: ok, so what was the story with Helsinki?? [22:10] <wtay> omega: oslo was 900 EURO per person, we found that too expensive. we didn't want to stay home and helsinki was in promotion for 270, so we went to helsinki hoping to get a cheaper flight to oslo from there [22:11] <omega> and once you got there? [22:11] chillywilly (~da...@mk...) left irc: "leaving" [22:11] <wtay> omega: we asked for the price to oslo, the cheapest flight was 450 per person [22:11] <omega> hmm, so now do you believe that flying is *not* the same as taking a bus? [22:12] <wtay> you know I'm not the person to schedule this long beforehand [22:12] <wtay> I'll do my best for dublin [22:14] <omega> so, have you gotten all the libatomic stuff working in the meantime? [22:15] sqtz (~sq...@21...) left irc: "Terminando cliente" [22:15] <wtay> omega: nope, I've been sick since monday.. still having a headache [22:18] <omega> ok, plan is to meet with Buck and the Intel guy tomorrow [22:23] <wtay> Intel? [22:24] <omega> see scrollback [22:25] Uraeus (~csc...@x9...) joined #gstreamer. [22:25] <omega> Uraeus: did you find the DV tapes I managed to leave with you? [22:25] <wtay> that gthread based cothread implementation is not bad at all [22:26] <omega> wtay: no, but I really don't want to shim that kind of thing in, I want the default/fallback scheduler to be written from scratch to be fully sane+correct [22:28] <wtay> basicgthread is 2.5 times slower on lat.c than basicomega [22:29] thaytan (jan@202.76.176.22) joined #gstreamer. [22:31] <wtay> less than 3% slower with opt [22:33] <Uraeus> omega: nope, where? [22:33] <Uraeus> omega: write it then :) [22:34] <wtay> omega: you want to write yet another scheduler? [22:35] <omega> yes, I think we need to start a new one somewhat from scratch [22:35] <omega> try to eliminate all the questions remaining in the current ones [22:36] <omega> Uraeus: sxpert gave them to you when we transfered my camera on Tuesday [22:36] <omega> afaik [22:36] <Uraeus> hmm, ok guess I need to get everything in order here then, so maybe I find them :) [22:37] <omega> they're 300NK, so don't go losing them [22:37] <Uraeus> heh :) [22:42] <chrisime> jo Uraeus :) [22:42] <Uraeus> hi chrisime [22:42] <Uraeus> chrisime: I noticed you started hacking on the bindings again :) [22:43] <chrisime> yep [22:44] <chrisime> it's more that martin and the other guy does [22:44] <chrisime> i hardly have time [22:44] <chrisime> another exam [22:44] <chrisime> in april [22:44] <chrisime> the cvs sucks these days [22:44] <chrisime> i have to double commit [22:44] <chrisime> to get my code in [22:44] <chrisime> Uraeus, i forgot the pw for the ML [22:51] <omega> ds-home: ping? [22:54] <Uraeus> wtay: http://bugzilla.gnome.org/show_bug.cgi?id=106047 [22:56] Company (~Co...@p5...) joined #gstreamer. [22:57] <Uraeus> Company: hi [22:57] <taaz> i like that idea in the queue bug+patch [22:57] <BBB> wtay: concerning the repeat field in GstBuffer - do you want to make this source backwards compatible? e.g. by making an element property 'GothroughBuffers' which (if unset) means that a repeat=N buffer is send to the element N times, whereas if it *is* set, the element will find out itself what to do with the repeat field [22:57] <BBB> wtay: that'd prevent all sorts of 'while (repeat >= 0) ...' crap in chain functions of all sorts of elements [22:57] <wtay> BBB: I'm not convinced a repeat field is needed [22:58] <taaz> on first view i think that repeat field idea is not a good idea [22:58] <BBB> how else do you want to do this? [22:58] <taaz> why not just create a repeater element or something? [22:58] <wtay> BBB: use the offset field to detect a discontinuitity [22:58] <taaz> i really didn't understand the reason for it though ;) [22:59] <Company> hi [22:59] <BBB> taaz: for elements that might want to send a buffer more than once... the repeat field can indicate this and make sure that the subsequent elements don't spend extra CPU cycles over the same buffer if that's not needed [22:59] <BBB> taaz: e.g. v4lsrc might duplicate a frame... currently, it means that buffer is sent twice to the next element (say, jpegenc), which means 2x frame encoding [22:59] <wtay> BBB: you could send a buffer with the same offset [23:00] <BBB> you really don't want to do all sort of comparing to previous buffers in chain functions imho [23:00] <wtay> BBB: offset didn't change, it's the same buffer, no need to reencode, just take previous encoded one [23:00] <Company> uhm [23:00] <BBB> that requires a cache, that's ugly [23:00] <BBB> I'm really not certain that's a good solution [23:00] <Company> buffers should be simple [23:00] <BBB> I'm not saying mine is ;) [23:01] <Company> the best buffer is just data and size [23:01] <BBB> Company: well, it doesn't become more difficult unless you use this property, right? [23:01] <BBB> and if you make it element-settable, elements don't need to care about it in their chain functions [23:01] <Company> since you want it as generic as possible and i don't think a repeat field would be useful [23:02] <wtay> BBB: can you restate the problem again.. [23:02] <BBB> ok [23:03] <BBB> there's some cases in which you want to use the same video data twice (or even more) [23:03] <BBB> currently, this means you push the same buffer twice over the src pad [23:03] <BBB> some elements, though, could use this knowledge and only process the same buffer once, and that'd save CPU cycles [23:04] <BBB> e.g. v4lsrc ! jpegenc ! fakesink [23:04] <wtay> why push the buffer N times? [23:05] <BBB> because the frame was indexed twice in an AVI file (multiple index entries can refer to the same data, that's allowed and is being used a lot), or because v4lsrc duplicated a frame, or ... [23:05] <wtay> why not push it once and put a timestamp of +N*frametime on the next buffer? [23:06] <BBB> erm, that sounds extremely hackty [23:06] <wtay> avidemux could notice that a) offset jumps, frames need to be duplicated to compesate for the gaps b) timestamp jumps c) less data passing [23:06] <wtay> gstreamer doesn't require contant framerate at all [23:07] <BBB> gstreamer doesn't, but avimux (for example) does... [23:07] <wtay> freeze-frame in DVD should be handled like this probably [23:07] <wtay> BBB: then avimux deals with it [23:07] <BBB> freeze frame is something else [23:08] <BBB> avimux can't deal with it [23:08] <BBB> the previous element might be a encoder that differs between keyframes and other frames [23:08] ds-work (ds...@co...) joined #gstreamer. [23:08] <BBB> and avimux is *not* allowed to mess up the order there by duplicating frames [23:08] <BBB> so unfortunately, that won't work... [23:09] <wtay> BBB: that problem is not solved with a repeat field either [23:09] <BBB> of course it is [23:10] <wtay> well, yes, but than the encoder still encodes multiple times [23:10] <wtay> s/than/then/ [23:10] <BBB> either the encoder or the scheduler (based on settings in the element done in the init function) looks at the repeat field and tells the chain function to process the frame N times [23:10] <BBB> wtay: depends on the encoder [23:10] <BBB> some encoders will process it N times [23:10] <BBB> others will process it once and copy the repeat field to the new buffer [23:10] <Company> i don't like that at all [23:11] <BBB> *then*, avimux is allowed to write it N times [23:11] <Company> for this little bit of performace we introduce that much of code? [23:11] <wtay> my problem with the repeat field is that the timestamp doesn't make sense anymore then [23:12] <BBB> hmm... [23:12] <wtay> and even a non keyframe encoder can look at gaps and fill in the blanks if it wants.. [23:12] <wtay> either by reencoding or pushing N times [23:13] <BBB> but then again, the encoder is not supposed to know whether the element following it wants constant framerate or not, right? [23:13] <wtay> BBB: that's solvable with a query [23:14] <wtay> now, this looks only usefull in the mjpeg case, right [23:15] <wtay> or for any keyframe only encoder [23:16] <Company> constant framerate is a caps property [23:16] <wtay> not currently [23:16] <Company> make it one [23:17] <wtay> not needed it yet [23:17] <Company> shouldn't be a problem to code it in, i think [23:17] <wtay> it isn't [23:18] cschalle_ (~csc...@x9...) joined #gstreamer. [23:18] <wtay> anyway for keyframe only encoders, avidemux can easily duplicate as the GST_BUFFER_KEY_UNIT flag is set.. [23:18] <wtay> avimux even [23:20] <wtay> for non keyframe encoders, reencoding is always needed and could therefore be done in the encoder (with a property? based on constant framerate caps?...) [23:21] <wtay> constant framerate caps property is not a bad idea for avimux so that the encoder knows it has to create a constant rate of frames (mjpeg sends missing intermediate frames, divx reencodes same input frame) [23:22] <BBB> I think checking for that in each element would be ten times as much (crap!) code in elements than my 'solution'... [23:22] <BBB> though mine isn't at all perfect either [23:23] <wtay> you're suggesting to handle the repeat in the scheduler? [23:24] <wtay> possibly with an element flag to indicate that the element can do the repeat itself? [23:25] <wtay> + with an extra field in GstBuffer (which will (theoretically) break ABI comp) [23:25] chillywilly (da...@mk...) joined #gstreamer. [23:25] <Company> yeah, let's make schedulers more difficult as they're the easiest part of gstreamer anyway </sarcasm> [23:25] <wtay> + with extra overhead for each push/pull to check for the repeat field? [23:28] <wtay> I thought avi even allowed an 'empty' index entry [23:29] <wtay> not sure what it does, though.. [23:29] <BBB> wtay: to allow for source compatibility, we could do element/scheduler interaction here, yes [23:30] <BBB> the element, if it supports the repeat field, sets gst_element_set_flag(element, I_AM_SMART_AND_UNDERSTAND_THE_REPEAT_FIELD); [23:30] <BBB> if this flag is set, the scheduler does nothing when calling the chain function [23:30] <BBB> else (default case), it sends the buffer (repeat_field_value)+1 times [23:30] <BBB> and the default repeat value is of course 0 [23:30] <BBB> or 1, depending on what you want it to do [23:31] <BBB> that's a three line no-brainer in the scheduler or where-ever the chain functions are called [23:31] <BBB> and it's source compatible with all plugins [23:31] <BBB> since by default, it's just pushed multiple times anyway [23:32] <BBB> so only the plugins that know wtf this is will actually use it [23:32] <wtay> who would set the repeat value? [23:32] <BBB> the element that pushes the buffer. and it's initialized to 0 in gst_buffer_new() [23:32] <wtay> yes, but who would set it to > 0, and when/how [23:32] Uraeus (~csc...@x9...) left irc: Read error: 110 (Connection timed out) [23:33] <BBB> the element pushing the buffer sets it to > 0 if it feels the need to push the same buffer more than once (as explained in the avi index/v4l case before) [23:34] <wtay> BBB: so, v4lsrc would buffer the last frame and mark it repeat 2 if it grabbed a new one and notices that it missed one? [23:35] <BBB> no [23:35] <BBB> it'd push the new one N times [23:35] <wtay> uhm [23:35] <BBB> actually, pushing the old one N times makes more sense... [23:35] <BBB> hmm... [23:35] <wtay> you need to buplicate the previous buffer, else you get an ugly jump [23:35] <BBB> darn :D [23:38] <wtay> and then you also assume in v4lsrc that the peer element requires a constant framerate... [23:42] <wtay> I feel you really need to delay the duplication to where it really is required, either avimux (can do that for buffers marked as KEY_UNIT) or a non-keyframe encoder (based on caps, element property or query on srcpad) [23:42] <wtay> that way, a muxer than can do non constant framerates can still be inserted in the pipeline without other ugly hacks [23:43] <wtay> s/than/that/ [23:44] <wtay> no API/ABI changes, no scheduler changes, just more intelligence in the plugins [23:46] <BBB> but if you assume that, then you could also say that v4lsrc shouldn't drop/insert frames at all, it should just change the framerate/timestamps? [23:46] <wtay> the downside is finding a way to query if a pad requires constant framerate [23:46] <wtay> BBB: I do [23:46] <BBB> i.e., if the source is supposed to give a static framerate (which is true in the case of v4lsrc/avidemux), shouldn't it 'just' do so? [23:47] <BBB> even though gstreamer can do it differently [23:47] cschalle_ (~csc...@x9...) left irc: "Client Exiting" [23:48] <wtay> BBB: IMO, v4lsrc should grab a frame, timestamp it, try to number the frames with an offset and try to mark dropped frames by making the offset discontinuous. The rest is up to the rest of the pipeline [23:50] <wtay> it can of course use all means to try to minimize dropped frames, like using a thread, queue, ringbuffer, whatever [23:50] Nick change: Anch -> Anch|Away [23:51] <wtay> _but_, when a frame is dropped, the rest of the pipeline should decide what happens [23:51] <wtay> it could very well be that the system is just overloaded and dupplicating frames is going to make it even worse in some situations [23:52] <wtay> or maybe I just want to grab one frame every 5 minutes.. [23:53] <ds-work> or, the user may have hit ctrl-Z [23:53] <ds-work> or have suspended the machine [23:55] apoc (~ap...@dy...) left irc: Remote closed the connection [23:58] <wtay> Company: I fixed opt so it can use the gthread based cothreads, it works great and isn't slow at all (3% slower on lat.c, lots of overhead entering/leaving iterate though) [23:59] <Company> wtay: nice - now i just want to know if it's portable :) [00:00] --- Fri Mar 14 2003 [00:00] <wtay> Company: doesn't look very complicated.. [00:00] <wtay> and since it's all lockstep execution there shouldn't be any race conditions [00:01] <Company> wtay: Do we still have some archs with cothread problems? [00:02] <wtay> Company: is there a libc besides debian x86 where it works, is a better question :) [00:02] ds-work (ds...@co...) left irc: "reboot() returned -EFIRE: Athlon on fire" [00:03] <wtay> even an mpeg pipeline plays fine with optgthread [00:04] <wtay> with an ugly assertion at EOS though... [00:05] <wtay> ** ERROR **: file gthread-cothreads.h: line 111 (do_cothread_context_destroy): assertion failed: (g_thread_self() != context->main->thread) [00:05] <wtay> I think the assertion is not needed [00:05] <Company> hm [00:06] <Company> you need to make sure to not destroy the main thread [00:06] <Company> so you end up with the same thread you started with [00:07] <wtay> then it should be: [00:07] <wtay> g_assert (g_thread_self() == context->main->thread); [00:07] <wtay> instead of [00:07] <wtay> g_assert (g_thread_self() != context->main->thread); [00:07] <Company> right [00:08] <wtay> yes, same checks in the other cothread context free implementations [00:08] <Company> i always do g_assert and g_return_if_fail the wrong way [00:09] <Company> and apparently gst-launch doesn't destroy the context [00:09] <wtay> oh [00:09] <wtay> well, I'm running this mpeg pipeline from -launch [00:10] <wtay> doesn't happens every time.. [00:10] <Company> hm [00:10] <wtay> ./gst-launch --gst-scheduler=optgthread -v { fakesrc num_buffers=4 ! fakesink } [00:10] <wtay> this triggers it [00:11] <wtay> but not this: [00:11] <wtay> ./gst-launch --gst-scheduler=optgthread -v fakesrc num_buffers=4 ! fakesink [00:11] <Company> yeah [00:11] <Company> probably because only threads destroy their contexts, but not the main pipeline [00:11] <Company> with -launch at least [00:12] <^iain^> yo [00:12] <wtay> that's a bug.. [00:12] <Company> right [00:12] <Company> put it into bugzilla or fix it :) [00:13] <ChrisHJW> the problem with the h.264 NALUs is, we have to spend 4 of the spare 6 bits from matroska's block header to support them all correctly, and we still dont know if the current spec draft for it will stay as it is, or if they will change that again, add more NALUs and we are borked with the way we are planning to support NALU implementation currently :( [00:13] <ChrisHJW> oh [00:13] <Company> wrong channel? :) [00:13] <ChrisHJW> sorry, wrong window :) [00:13] <wtay> Company: hmm.. it's really a bug... strange [00:14] <wtay> darn, gstpipeline.c line 156 [00:15] <Company> hehe [00:16] <Company> we found that one in oslo, too [00:17] <wtay> but, with the refcouting changes on the scheduler, we might simply do the reset in the dispose function as this one will always run in cothread 0 [00:19] <Company> sure? [00:19] <Company> does the scheduler ref its parent when iterating? [00:20] <wtay> iterate holds a refcount to the bin, when you unref in a callback inside iterate it'll only take effect after iterate ends (and in cothread 0 again) [00:20] <wtay> gst_bin_iterate refs itself.. [00:21] ChrisHJW (~chr...@p5...) left irc: [00:21] <Company> right [00:21] Action: wtay tries [00:21] <Company> that'll work [00:22] <Company> try it with basicgthread, too [00:23] Nick change: Anch|Away -> Anch [00:23] BBB (~BBB@213.160.215.2) left irc: "Client exiting" [00:23] Anch (~mgu...@12...) left #gstreamer. [00:24] Action: wtay gets the same error, so that's good [00:26] <wtay> Company: uhm, you might want to investigate the segfault when reversing the g_assert condition.. [00:27] <wtay> ah, a g_slist_next in the while loop would help.. [00:30] <Company> wtay: nope, not g_slist_next in the while loop [00:30] <wtay> I did g_slist_delete_link now [00:31] <Company> wtay: line 123: to_die->context->cothreads = g_slist_remove (to_die->context->cothreads, to_die); [00:31] <wtay> yes, indeed [00:35] <wtay> err [00:39] <Company> ok, works here now [00:40] <wtay> the various g_slist_remove calls don't use the return value (the new list head) [00:40] <Company> right [00:41] <wtay> ok, fixing that makes it work too here [00:41] <Company> that's one of my most common errors [00:42] <Company> and the mutex needs to be unlocked before it's freed [00:44] <wtay> context->cothreads is always NULL here by the time the pipeline is diposed [00:44] <Company> wtay: right [00:45] <Company> wtay: the scheduler frees the cothreads before disposing the context [00:45] <Company> the basic one does, at least [00:45] <wtay> opt too, it's a bin thing [00:45] <wtay> the bin removes all elements from itself before disposing itseld [00:45] <wtay> itself [00:46] <wtay> then the scheduler cleans up the cothread contexts [00:47] <wtay> wow 11 threads in an mpeg -launch line [00:50] <Company> hehe [00:51] <wtay> time -launch --gst-scheduler=basicgthread fakesrc num_buffers=4000 ! 40 * identity ! fakesink [00:51] ChrisHJW (~chr...@p5...) joined #gstreamer. [00:51] <wtay> real 0m10.727s [00:51] <wtay> user 0m8.274s [00:51] <wtay> sys 0m2.260s [00:51] <wtay> time -launch --gst-scheduler=optgthread fakesrc num_buffers=4000 ! 40 * identity ! fakesink [00:51] <wtay> real 0m6.384s [00:51] <wtay> user 0m6.159s [00:51] <wtay> sys 0m0.117s [00:52] Action: wtay wonders how NGTL/NPTL performs [00:52] <wtay> time for bed, cya [00:53] Nick change: wtay -> wtay-zZz [00:53] <Company> gnight [00:53] <Company> wtay-zZz: have you commited your fixes? [00:58] <wtay-zZz> Company: nope, want me to? [00:59] <wtay-zZz> I think you have the same fixes [01:02] <Company> wtay-zZz: i just want to sy<nc out checkouts [01:03] <Company> and i only fixed my gthread-cothreads.h [01:05] <Company> i'm gonna commit just that file so you gotta merge that then [01:06] <Company> gnight [01:06] Company (~Co...@p5...) left irc: "ALL GLORY TO THE HYPNO-TOAD" [01:13] chillywilly (da...@mk...) left irc: "leaving" [01:17] Nick change: thomasvs -> thomasvz [01:21] chillywilly (da...@mk...) joined #gstreamer. [01:22] ds-work (ds...@co...) joined #gstreamer. [01:23] <ds-work> moo [01:23] <ds-work> I didn't realize how many annoying pop-ups there are loose on the web [01:23] <ds-work> until I started using galeon-snapshot [01:24] <^iain^> does it not block them anymore? [01:24] <ds-work> it didn't copy my old settings [01:24] <^iain^> Epiphany seems to do "quite" a good job at it [01:24] <ds-work> so I eventually had to disable it [01:24] <^iain^> but there's no options to turn off javascript, or anything like that [01:27] ds-work (ds...@co...) left irc: Client Quit [01:34] camh (~ca...@xi...) joined #gstreamer. [01:46] <ChrisHJW> yet [01:47] <ChrisHJW> again .. sorry :( [01:49] ChrisHJW (~chr...@p5...) left irc: [02:40] mrra (~user@157.182.195.241) left irc: Remote closed the connection |