From: Daniel Caujolle-B. <seg...@cl...> - 2002-12-29 23:44:47
|
Hi, Well, i just added video post plugin support, which works quite well. It even support on-fly rewiring. So i've done similar thing for audio post stuff, but it seems there's a problem at rewiring time, it made the video jumpy few seconds, then crash and burn. Cheers. -- 73's de Daniel, F1RMB. -=- Daniel Caujolle-Bert -=- seg...@cl... -=- -=- f1...@f1... (AMPR NET) -=- |
From: Michael R. <mr...@us...> - 2002-12-30 11:34:22
|
Hi Daniel, > Well, i just added video post plugin support, which works quite > well. It even support on-fly rewiring. So i've done similar thing for > audio post stuff, but it seems there's a problem at rewiring time, it > made the video jumpy few seconds, then crash and burn. What exactly did you try to rewire? (I believe the goom post plugin should not register itself in the video out, because there is no video decoder the output might want to call back. But I want to hear what you tried, first.) Michael -- panic("Foooooooood fight!"); 2.2.16 /usr/src/linux/drivers/scsi/aha1542.c |
From: Daniel Caujolle-B. <seg...@cl...> - 2002-12-30 11:55:47
|
Michael Roitzsch wrote: > Hi Daniel, > > >> Well, i just added video post plugin support, which works quite >>well. It even support on-fly rewiring. So i've done similar thing for >>audio post stuff, but it seems there's a problem at rewiring time, it >>made the video jumpy few seconds, then crash and burn. > > > What exactly did you try to rewire? > (I believe the goom post plugin should not register itself in the video > out, because there is no video decoder the output might want to call > back. But I want to hear what you tried, first.) > Changing post plugin on the fly, like you can do with the video post plugin invert (you can turn on/off). To reproduce, enable goom, start any mp3, and in setup window, reselect goom (i can tell you also i tried to just rewire to audio port only, without rewire to the new post plugin after, with the same result), and see how xine-ui crash. Cheers. -- 73's de Daniel, F1RMB. -=- Daniel Caujolle-Bert -=- seg...@cl... -=- -=- f1...@f1... (AMPR NET) -=- |
From: Michael R. <mr...@us...> - 2002-12-30 14:05:25
|
Hi Daniel, > >> Well, i just added video post plugin support, which works quite > >>well. It even support on-fly rewiring. So i've done similar thing > >> for audio post stuff, but it seems there's a problem at rewiring > >> time, it made the video jumpy few seconds, then crash and burn. > > > > What exactly did you try to rewire? > > (I believe the goom post plugin should not register itself in the > > video out, because there is no video decoder the output might want > > to call back. But I want to hear what you tried, first.) > > Changing post plugin on the fly, like you can do with the video post > plugin invert (you can turn on/off). To reproduce, enable goom, start > any mp3, and in setup window, reselect goom (i can tell you also i > tried to just rewire to audio port only, without rewire to the new > post plugin after, with the same result), and see how xine-ui crash. Ahh, I see some races: All the rewiring (and post plugin disposal) is done in the frontend's thread context, but the actual dataflow is decoder thread. This leads to problems when rewiring on the fly during playback. We need a nice mutex solution here. I have thought about some, but all had some drawbacks. Suggestions would be welcome. Michael -- "C combines all the power of assembly language with all the ease of use of assembly language" - trad |
From: Daniel Caujolle-B. <seg...@cl...> - 2002-12-30 14:20:18
|
Hi Michael, Michael Roitzsch wrote: > Hi Daniel, > > >>>> Well, i just added video post plugin support, which works quite >>>>well. It even support on-fly rewiring. So i've done similar thing >>>>for audio post stuff, but it seems there's a problem at rewiring >>>>time, it made the video jumpy few seconds, then crash and burn. >>> >> >> Changing post plugin on the fly, like you can do with the video post >>plugin invert (you can turn on/off). To reproduce, enable goom, start >>any mp3, and in setup window, reselect goom (i can tell you also i >>tried to just rewire to audio port only, without rewire to the new >>post plugin after, with the same result), and see how xine-ui crash. > > > Ahh, I see some races: > All the rewiring (and post plugin disposal) is done in the frontend's > thread context, but the actual dataflow is decoder thread. This leads > to problems when rewiring on the fly during playback. I also made a try with just rewiring, no dispose, no new post_init, just the rewire, and it crashed too. This problem doesn't happen with video post plugin, the change happen few frame after the change, it's fine for me. Cheers. -- 73's de Daniel, F1RMB. -=- Daniel Caujolle-Bert -=- seg...@cl... -=- -=- f1...@f1... (AMPR NET) -=- |
From: Michael R. <mr...@us...> - 2002-12-30 15:45:23
|
Hi Daniel, > > Ahh, I see some races: > > All the rewiring (and post plugin disposal) is done in the > > frontend's thread context, but the actual dataflow is decoder > > thread. This leads to problems when rewiring on the fly during > > playback. > > I also made a try with just rewiring, no dispose, no new post_init, > just the rewire, and it crashed too. This problem doesn't happen with > video post plugin, the change happen few frame after the change, it's > fine for me. But still the rewiring includes close()ing and re-open()ing the audio out plugin, which (in contrast to the video out) does some stuff apart from just (un)registering the stream there. If you want, you can try, if (in addition to skipping the dispose) commenting out these close() and open() operations in xine_stream_rewire_audio() helps. (For the special case of xine-ui/goom, they are not necessary anyway, because the same output is close()d and re-open()ed.) Michael -- printk("CPU[%d]: Sending penguins to jail...",smp_processor_id()); 2.4.8 arch/sparc64/kernel/smp.c |
From: Miguel F. <mi...@ce...> - 2003-01-02 13:23:59
|
Hi Michael, Hi Daniel, On Mon, 2002-12-30 at 12:05, Michael Roitzsch wrote: > Ahh, I see some races: > All the rewiring (and post plugin disposal) is done in the frontend's > thread context, but the actual dataflow is decoder thread. This leads > to problems when rewiring on the fly during playback. > > We need a nice mutex solution here. I have thought about some, but all > had some drawbacks. Suggestions would be welcome. i would suggest that we forbid on-the-fly rewiring for now: rewiring should only be allowed if stream is at "stopped" state. of course, we might change that in the future if we find a clean way to avoid the race. i just think we have other more interesting priorities... regards, Miguel |
From: Michael R. <mr...@us...> - 2003-01-02 13:47:45
|
Hi Miguel, Hi Daniel, > > Ahh, I see some races: > > All the rewiring (and post plugin disposal) is done in the > > frontend's thread context, but the actual dataflow is decoder > > thread. This leads to problems when rewiring on the fly during > > playback. > > > > We need a nice mutex solution here. I have thought about some, but > > all had some drawbacks. Suggestions would be welcome. > > i would suggest that we forbid on-the-fly rewiring for now: rewiring > should only be allowed if stream is at "stopped" state. > > of course, we might change that in the future if we find a clean way > to avoid the race. i just think we have other more interesting > priorities... Agreed. I can live with that limitation for now. Daniel, is that ok for you? Michael -- "UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a boot partition virus." -Peter H. Coffin |
From: Daniel Caujolle-B. <seg...@cl...> - 2003-01-02 13:50:31
|
Hi Michael, hi Miguel, Michael Roitzsch wrote: > Hi Miguel, Hi Daniel, > > >>>Ahh, I see some races: >>>All the rewiring (and post plugin disposal) is done in the >>>frontend's thread context, but the actual dataflow is decoder >>>thread. This leads to problems when rewiring on the fly during >>>playback. >>> >>>We need a nice mutex solution here. I have thought about some, but >>>all had some drawbacks. Suggestions would be welcome. >> >>i would suggest that we forbid on-the-fly rewiring for now: rewiring >>should only be allowed if stream is at "stopped" state. >> >>of course, we might change that in the future if we find a clean way >>to avoid the race. i just think we have other more interesting >>priorities... > > > Agreed. I can live with that limitation for now. > Daniel, is that ok for you? Of course. At least, it's clear, and first: safe. Cheers. -- 73's de Daniel, F1RMB. -=- Daniel Caujolle-Bert -=- seg...@cl... -=- -=- f1...@f1... (AMPR NET) -=- |