From: <bar...@t-...> - 2002-09-28 19:20:15
|
hi folks, as you might know i'm currently cleaning up xine's event mechanism. this means i have to understand the event types and how they're used - i just came across the close_caption event i think it can be removed since it is only used to call the cc spu decoder from libmpeg2, but it is not necessary to (ab)use the event mechanism for this, i think libspucc can just be turned into a libmpeg2 subdir and called directly. cheers, guenter -- "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart |
From: Miguel F. <mi...@ce...> - 2002-09-28 20:02:28
|
Hi Guenter, On Sat, 2002-09-28 at 16:20, Guenter Bartsch wrote: > hi folks, > > as you might know i'm currently cleaning up xine's event mechanism. this > means i have to understand the event types and how they're used - i just > came across the close_caption event > > i think it can be removed since it is only used to call the cc spu > decoder from libmpeg2, but it is not necessary to (ab)use the event > mechanism for this, i think libspucc can just be turned into a libmpeg2 > subdir and called directly. Just to make sure we are not limiting possibilities here: what if a new input/demux plugin (eg: v4l like) can separate cc data from tv signal (line 21 i guess) and send it as BUF_SPU_CC? Perhaps now that we have the new plugin loader mechanism it might get fixed by letting libmpeg2 to register both mpeg2 and cc decoders. regards, Miguel |
From: <bar...@t-...> - 2002-09-28 20:16:59
|
hallo miguel, > > as you might know i'm currently cleaning up xine's event mechanism. this > > means i have to understand the event types and how they're used - i just > > came across the close_caption event > > > > i think it can be removed since it is only used to call the cc spu > > decoder from libmpeg2, but it is not necessary to (ab)use the event > > mechanism for this, i think libspucc can just be turned into a libmpeg2 > > subdir and called directly. > > Just to make sure we are not limiting possibilities here: what if a new > input/demux plugin (eg: v4l like) can separate cc data from tv signal > (line 21 i guess) and send it as BUF_SPU_CC? > > Perhaps now that we have the new plugin loader mechanism it might get > fixed by letting libmpeg2 to register both mpeg2 and cc decoders. anyway, see my follow-up posting i noted that more modules are using the "old", synced event mechanism for cross-module interaction. i don't think this is the best way of handling thing, but don't want to get into this too deeply and focus on the public api for now (in fact i had first forgotten events completely and then when daniel reminded me of this i had simply copied all event stuff blindly to the public xine header - so it's definitely time to think this through and find a clean solution. i've just posted a first proposal of a cleaner interface on this mailing list, maybe you'd like to have a look?) cheers, guenter -- "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart |
From: Christian V. <cv...@gr...> - 2002-09-28 20:17:40
|
On Sat, Sep 28, 2002 at 04:52:37PM -0300, Miguel Freitas wrote: > > i think it can be removed since it is only used to call the cc spu > > decoder from libmpeg2, but it is not necessary to (ab)use the event > > mechanism for this, i think libspucc can just be turned into a libmpeg2 > > subdir and called directly. > > Just to make sure we are not limiting possibilities here: what if a new > input/demux plugin (eg: v4l like) can separate cc data from tv signal > (line 21 i guess) and send it as BUF_SPU_CC? Hi Guenter, hi Miguel, we had this discussion before (around January), and I have to agree with Miguel. The CC decoder is not specific to libmpeg-2, and a TV input plugin that generates CC buffers is perfectly feasible. I also agree that using the event mechanism is a hack. It would be better to find a cleaner way to pass on CC data via the buffer meachnisms. I just don't think that the decoder should be tied to libmpeg2. Regards - Christian |
From: <bar...@t-...> - 2002-09-28 20:34:41
|
hi christian, > > > i think it can be removed since it is only used to call the cc spu > > > decoder from libmpeg2, but it is not necessary to (ab)use the event > > > mechanism for this, i think libspucc can just be turned into a libmpeg2 > > > subdir and called directly. > > > > Just to make sure we are not limiting possibilities here: what if a new > > input/demux plugin (eg: v4l like) can separate cc data from tv signal > > (line 21 i guess) and send it as BUF_SPU_CC? > > we had this discussion before (around January), and I have to agree > with Miguel. The CC decoder is not specific to libmpeg-2, and a TV input > plugin that generates CC buffers is perfectly feasible. i see - the sync event mechanism will stay in xine, but it will no longer be visible for frontends. i hope this way deadlocks and other side-effects can be kept under control. thanks for your work and comments, guenter -- Q: How many existentialists does it take to screw in a lightbulb? A: Two. One to screw it in and one to observe how the lightbulb itself symbolizes a single incandescent beacon of subjective reality in a netherworld of endless absurdity reaching out toward a maudlin cosmos of nothingness. |