From: Mike M. <mel...@pc...> - 2002-05-27 03:41:24
|
Hi, Okay, so I still do not have the first demuxer working. But that did not stop me from writing two more demuxers. It seems silly. However, in the course of writing the other two, I noticed and fixed a variety of problems between all 3. The 3 demuxers in question are the same 3 that I wrote for MPlayer, namely: FLI, FILM, and RoQ. Note that the A/V decoders corresponding to 2 of them (FLI and RoQ) do not yet exist for xine yet. I am working on that, too. So the upshot of all this is that I have spent the weekend writing, porting, and adapting several *thousand* lines of code for xine, *none* of which work correctly...:) (Or at least have not been tested because the demuxed packets do not seem to be reaching the decoders.) The only reason I maintain optimism is because I know that after I work past a few of my own misunderstandings, all of these modules *will* work. I guess my question is: Do you want me to start dumping this code on the list even though it does not umm...what is the word..."work" just yet? Thanks... -- -Mike Melanson |
From: <bar...@t-...> - 2002-05-27 16:22:41
|
Hi Mike, On Sun, 26 May 2002, Mike Melanson wrote: > I guess my question is: Do you want me to start dumping this code > on the list even though it does not umm...what is the word..."work" just > yet? not just on the list, I'd suggest adding it to the CVS (try to make sure it doesn't brake anything), I think many of your problems can be fixed quickly by other developers who are more familiar with the xine code (just like setting "content" to "mem" in bufs) - so this could save you a lot of time and you can focus on the real issues :) keep up the good work, guenter -- time is a funny concept |
From: Gabucino <gab...@mp...> - 2002-05-28 16:41:43
|
> So the upshot of all this is that I have spent the weekend=20 > writing, porting, and adapting several *thousand* lines of code for xine, > *none* of which work correctly...:) I (really) wonder why you left MPlayer, for you are already experienced in = it. --=20 Gabucino <Pontscho> (4k - s packetbe csak a furdoruham fer el:) |
From: Mike M. <mel...@pc...> - 2002-05-28 17:03:19
|
On Tue, 28 May 2002, Gabucino wrote: > I (really) wonder why you left MPlayer, Ask A'rpi... > for you are already experienced in it. Believe me, I was not thrilled about having to redo 4+ months of work either, as well as having to face the xine learning curve. > > > Why not develop MPlayer's demuxer? Is it going unmaintained now? > > Only if no one else maintains it...:) > Now, that's what I call avifileism. I do not see how this could possibly pose a problem to the #1 Freshmeat project...:) Besides, MPlayer's RoQ file demuxer works just fine (if a little slow to load on your system). The video decoder is what does not work correctly. xine's decoder works a bit better, probably because I did not write it this time...:) -- -Mike Melanson |
From: Arpi <ar...@th...> - 2002-05-28 17:52:00
|
Hi, > > I (really) wonder why you left MPlayer, > > Ask A'rpi... could you please explain? i've asked the very same question few weeks ago, and you didn't answer, except 'i can't work with you'. i'm also interested in the answer... of course you're free to leave mplayer and join xine, but if you do it because of me, please, at least tell me why, ok? i hope it wasn't because of my reaction of your removal of 16bpp support from the rle codec. sorry, you did break one of the main mplayer cvs rules: do not remove features. and in the case of rle, it was very sensitive, as our only sponsor requires that fuckin' rle support... if you leave a project just because of this, eh, so do it, it's better then > > for you are already experienced in it. > > Believe me, I was not thrilled about having to redo 4+ months of > work either, as well as having to face the xine learning curve. i've seen your xine demuxers, eh, imho learning mplayer demuxer layer is nothing compared to the xine one :) > > > > Why not develop MPlayer's demuxer? Is it going unmaintained now? > > > Only if no one else maintains it...:) > > Now, that's what I call avifileism. :) yep, avifile and mplayerxp are good example of 'hobby project' :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu |
From: Mike M. <mel...@pc...> - 2002-05-28 18:41:47
|
On Tue, 28 May 2002, Arpi wrote: > i've asked the very same question few weeks ago, and you didn't answer, > except 'i can't work with you'. i'm also interested in the answer... Do I need any other reason? > of course you're free to leave mplayer and join xine, but if you do it > because of me, please, at least tell me why, ok? How about your lack of anything remotely resembling diplomacy? Your general "scream insults first, ask questions later" policy? > i hope it wasn't because of my reaction of your removal of 16bpp support > from the rle codec. sorry, you did break one of the main mplayer cvs > rules: do not remove features. and in the case of rle, it was very I did not break RLE support. As soon as another module got fixed, my RLE code worked. > sensitive, as our only sponsor requires that fuckin' rle support... So does the sponsor use only the latest CVS copy? Previous versions of MPlayer work fine with MSRLE, so if that is the only feature he cares about, he should be okay. > i've seen your xine demuxers, eh, imho learning mplayer demuxer layer is > nothing compared to the xine one :) I do not think you are qualified to make that assertion...:) You are the one who came up with the MPlayer demuxer layer in the first place. Of course it makes perfect sense to you. As someone who has had to figure out both, I can certify that xine's architecture is much easier to deal with. And if I have questions, the xine developers will answer in a courteous and coherent fashion. > yep, avifile and mplayerxp are good example of 'hobby project' :) I know you take MPlayer way more seriously than you should, so this may come as a surprise to you: Most open source projects are hobby projects. -- -Mike Melanson |
From: Gabucino <gab...@mp...> - 2002-05-28 19:22:05
|
> > i've asked the very same question few weeks ago, and you didn't answer, > > except 'i can't work with you'. i'm also interested in the answer... > Do I need any other reason? Heh. You get _nothing_ from arpi, compared to the hammering I get from him = :/ --=20 Gabucino <Pontscho> (4k - s packetbe csak a furdoruham fer el:) |
From: Arpi <ar...@th...> - 2002-05-28 19:44:03
|
Hi, > > of course you're free to leave mplayer and join xine, but if you do it > > because of me, please, at least tell me why, ok? > > How about your lack of anything remotely resembling diplomacy? Sorry, I don't have time to write 3 pages of polite explanation why did you do something wrong, when i can write all down in a single line... yep, unpolite. but who cares (except you, of course) ? imho we are hardcore hackers, not politicans. most of us like short, fast answers instead of long explanation of one-line things. but there are exceptions... > Your general "scream insults first, ask questions later" policy? It has stronger, faster, quicker effect than diplomacy :) Of course it has its price, too... :( > > i've seen your xine demuxers, eh, imho learning mplayer demuxer layer is > > nothing compared to the xine one :) > > I do not think you are qualified to make that assertion...:) You > are the one who came up with the MPlayer demuxer layer in the first place. > Of course it makes perfect sense to you. As someone who has had to figure > out both, I can certify that xine's architecture is much easier to deal > with. And if I have questions, the xine developers will answer in a > courteous and coherent fashion. great! > > yep, avifile and mplayerxp are good example of 'hobby project' :) > > I know you take MPlayer way more seriously than you should, so yes, this is very true. and i don't really know why, but i feel it is much more than a hobby project. > this may come as a surprise to you: Most open source projects are hobby > projects. i know. but quoting myself: "but there are exceptions" :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu |
From: Mike M. <mel...@pc...> - 2002-05-28 20:32:16
|
On Tue, 28 May 2002, Arpi wrote: > Sorry, I don't have time to write 3 pages of polite explanation why did > you do something wrong, when i can write all down in a single line... > yep, unpolite. but who cares (except you, of course) ? [sigh]...oh boy...did you know that there is a middle ground between 3-page expositions and rude dismissals? Ostensibly not, but explore the possibility. > imho we are hardcore hackers, not politicans. > most of us like short, fast answers instead of long explanation of > one-line things. but there are exceptions... Okay xine team, here we have it: The secret of success from the leader of the #1 FM project. From here on out, I want everyone on this list to treat each other with the utmost disdain. I know it stinks, but it is our only chance if we ever want xine to catch up to MPlayer. :) Or should we invoke the principle that "correlation != causation"? > > with. And if I have questions, the xine developers will answer in a > > courteous and coherent fashion. > > great! Eh? Try to remember you are arguing the case against xine here...:) > i know. > but quoting myself: "but there are exceptions" :) I just realized that MPlayer could accurately be described as one big exception. For example, it is absolutely inexplicable that it works at all considering all the nested scopes. [shudder] But try to remember what I mentioned above about correlation not necessarily equaling causation. MPlayer is successful, very much so. But I do not think it is valid to claim that it is "because" the team leader is abhorrently rude or "because" the code is atrocious aesthetically. -- -Mike Melanson |
From: <bar...@t-...> - 2002-05-29 00:59:44
|
hi folks, On Tue, 28 May 2002, Mike Melanson wrote: > > imho we are hardcore hackers, not politicans. > > most of us like short, fast answers instead of long explanation of > > one-line things. but there are exceptions... > > Okay xine team, here we have it: The secret of success from the > leader of the #1 FM project. From here on out, I want everyone on this > list to treat each other with the utmost disdain. I know it stinks, but it > is our only chance if we ever want xine to catch up to MPlayer. :)) actually i never quite understand the whole "mplayer against xine" thingy. i always thought and i still think that both projects can peacefully co-exist and benefit from one another. i think its nice to see the different aproaches and emphasis of the two projects. the situation gives us the opportunity to implement different ideas, in different ways on the two platforms (and let's not forget there are other projects in this field as well, thinking of videolan or gstreamer for example). since i now see both projects are covered the gpl it is even no problem to port code from one project to the other without too much discussion (of course giving credit to the original authors is always important - for example when you port mms or avi subtitle support to one project or the other ;)). so at least my aproach to this whole "a is better than b" issue is still: lets focus on the future and improve the software, so we will soon have software that is _much_ better than a _and_ b in their current states. in the end, we and all the users will benefit from that. keep up the good work - mplayer as well as xine, guenter of course, a little bit of competition is always nice to have ;> -- time is a funny concept |
From: Arpi <ar...@th...> - 2002-05-29 12:57:08
|
Hi, > > Okay xine team, here we have it: The secret of success from the > > leader of the #1 FM project. From here on out, I want everyone on this > > list to treat each other with the utmost disdain. I know it stinks, but it > > is our only chance if we ever want xine to catch up to MPlayer. > > :)) actually i never quite understand the whole "mplayer against xine" > thingy. i always thought and i still think that both projects can > peacefully co-exist and benefit from one another. i think its nice to see > the different aproaches and emphasis of the two projects. the situation > gives us the opportunity to implement different ideas, in different ways > on the two platforms (and let's not forget there are other projects in and i (we?) fully agree with you. it is not a bloody game. not even a competition, but both we and you want to make the best player out there, and it creates something like a competition... anyway i'm happy with it - remember when 2 years ago we started. i don't know when was xine first release, and it was the name from the first day or it changed like mplayer from mpg12play. but, more or less, we started at the same time, and more or less, we reached the same functionality. of course there are differences, but without them we couldn't make the difference between xine and mplayer :) and, 2 years ago, there was no usable mpeg (not talking about divx) player. and now, we has a wide range of players... some of them even beat windows players in speed and/or functionality... > this field as well, thinking of videolan or gstreamer for example). since isn't gstreamer just a wrapper over avifile and libmpeg3 ? imho, the currently existing and worth-to-mention players are: xine, avifile/aviplay, ogle and videolan. (and mplayer, maybe :)) i don't know people using xanim, gstreamer or xmps for watching movies... > i now see both projects are covered the gpl it is even no problem to port > code from one project to the other without too much discussion (of course yes. next step is some common API to make it easier :) > so at least my aproach to this whole "a is better than b" issue is still: a is better than b, but there is mplayer, it's better than a and b :)))) this has no sense - all player has its features and missing features. > of course, a little bit of competition is always nice to have ;> agree A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu |
From: <bar...@t-...> - 2002-06-04 18:18:50
|
hi arpi, ...trying to clean up my inbox, hope my response times will improve :)) > anyway i'm happy with it - remember when 2 years ago we started. > i don't know when was xine first release, and it was the name from the > first day or it changed like mplayer from mpg12play. xine went public in august 2000 and i think the first release was in september 2000. the name was always "xine" although i had no idea it was the short-form for "christine" in us - the name has a completely different background. > > this field as well, thinking of videolan or gstreamer for example). since > > isn't gstreamer just a wrapper over avifile and libmpeg3 ? gstreamer is a wrapper, but over a lot more that avifile and libmpeg3. it is a multimedia streaming framework. > > i now see both projects are covered the gpl it is even no problem to port > > code from one project to the other without too much discussion (of course > > yes. next step is some common API to make it easier :) again, I'm not sure if this is possible. xine's demuxers have some thread-stuff in them and its not easy to move that to a different abstraction layer. also this would require for some developers to get into the others project to understand the different architectures and find common ground here. cheers, guenter -- time is a funny concept |
From: <bar...@t-...> - 2002-05-29 00:50:42
|
hi mike, hi list, On Tue, 28 May 2002, Mike Melanson wrote: > > i've seen your xine demuxers, eh, imho learning mplayer demuxer layer is > > nothing compared to the xine one :) > > I do not think you are qualified to make that assertion...:) You > are the one who came up with the MPlayer demuxer layer in the first place. > Of course it makes perfect sense to you. As someone who has had to figure > out both, I can certify that xine's architecture is much easier to deal > with. And if I have questions, the xine developers will answer in a > courteous and coherent fashion. wow - i always wondered how somebody who knows both architectures thinks about this, nice to hear that :) anyway, for quite some time now i'm wondering if there's a way to improve xine's demuxers. the point is that most demuxers have nearly the same code, so it'd be pretty nice if that common code could be moved into a seperate module (yeah, i know, i'm not exactly the one who's the first to shout "seperate common code!", but in the demuxer case it's a bit heavy). the only problem that kept from doing it: i have know idea who to get that done. maybe some kind of "master demuxer" that takes some kind of struct of function pointers (a "demuxer driver" similar to video output drivers?) which are called to handle the specifics of a certain format but handles stuff like creating the demux thread, sending init/control buffers ... just an idea, of course :) keep up the good work, guenter -- time is a funny concept |
From: Mike M. <mel...@pc...> - 2002-05-29 03:11:42
|
On Wed, 29 May 2002, Guenter Bartsch wrote: > anyway, for quite some time now i'm wondering if there's a way to improve > xine's demuxers. the point is that most demuxers have nearly the same > code, so it'd be pretty nice if that common code could be moved into a > seperate module (yeah, i know, i'm not exactly the one who's the first to > shout "seperate common code!", but in the demuxer case it's a bit heavy). > the only problem that kept from doing it: i have know idea who to get that > done. maybe some kind of "master demuxer" that takes some kind of struct > of function pointers (a "demuxer driver" similar to video output drivers?) > which are called to handle the specifics of a certain format but handles > stuff like creating the demux thread, sending init/control buffers ... I don't know if I follow this idea. Demuxers have a common job: Break an input stream down into packets. But they all do it in different ways. Just like all video decoders have all the same job: Take a chunk of compressed data and decompress it to a video frame. But they all get there in completely different ways. I have written 3 xine demuxers so far (1 hasn't been committed yet) and they are all completely different. One fetches an index table from the file and demuxes based on that. One fetches a header and then traverses the frames in order in the file without building a table in advance. And the third is different still. What parts of the demuxer subsystem are common enough to combine? Thanks... -- -Mike Melanson |
From: Arpi <ar...@th...> - 2002-05-29 09:55:44
|
Hi, > > anyway, for quite some time now i'm wondering if there's a way to improve > > xine's demuxers. the point is that most demuxers have nearly the same > > code, so it'd be pretty nice if that common code could be moved into a > > seperate module (yeah, i know, i'm not exactly the one who's the first to hehe, did you read my 'life after the 0.90 release' mail at mplayer-dev-eng yesterday? i've described exactly the same for our demuxer :) so, maybe we could discuss this, and both projects coudl profit from the result. (in my dreams there is a common demuxer and codec api for linux and all players use it but it's a very impossible dream...) > I don't know if I follow this idea. Demuxers have a common > job: Break an input stream down into packets. But they all do it in > different ways. Just like all video decoders have all the same job: Take a > chunk of compressed data and decompress it to a video frame. But they all > get there in completely different ways. I have written 3 xine demuxers so hmm. i thought you understood what were you doing in the demuxer area :) imho: there are 2 kind of streams, so 2 kind of demuxers: 1. stream formats: you can read packets after eachother from the stream, and depending on few bits in packet you put it to audio or video (or other) buffers. mpeg, asf, vivo and avi are such formats. note: they _may_ have index table, but it is not mandatory. 2. indexed formats: you have to read the index table, and you can read packets of specific sub-stream using the offset/size data from index mov, realmedia are such. they must have index table. in my plans, i'll implement a dual core, one for type 1. and one for type 2. for type 1, the demuxer core should handle runtime index building (for fast and precise backward seeking) and controlling stream buffering. for type 2, the demuxers should pass the parsed index table to the demuxer core, and it will handle all the messy job. > What parts of the demuxer subsystem are common enough to combine? hard to believe you ever wrote any demuxer :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu |
From: <bar...@t-...> - 2002-06-04 18:11:01
|
hi arpi, On Wed, 29 May 2002, Arpi wrote: > > > anyway, for quite some time now i'm wondering if there's a way to improve > > > xine's demuxers. the point is that most demuxers have nearly the same > > > code, so it'd be pretty nice if that common code could be moved into a > > > seperate module (yeah, i know, i'm not exactly the one who's the first to > > hehe, did you read my 'life after the 0.90 release' mail at mplayer-dev-eng > yesterday? i've described exactly the same for our demuxer :) nope, that seems to have been just a coincidence :)) as it has already been said on this mailing list, my impression was pretty wrong, system layers seem to differ too much so there is actually very little code shared between the demuxers now. I guess my impression was simply outdated from times when xine had more or less just mpeg demuxers. > imho: there are 2 kind of streams, so 2 kind of demuxers: > 1. stream formats: you can read packets after eachother from the > stream, and depending on few bits in packet you put it to audio or > video (or other) buffers. mpeg, asf, vivo and avi are such formats. > note: they _may_ have index table, but it is not mandatory. > 2. indexed formats: you have to read the index table, and you can read > packets of specific sub-stream using the offset/size data from index > mov, realmedia are such. they must have index table. > > in my plans, i'll implement a dual core, one for type 1. and one for type 2. > > for type 1, the demuxer core should handle runtime index building (for fast > and precise backward seeking) and controlling stream buffering. > > for type 2, the demuxers should pass the parsed index table to the demuxer > core, and it will handle all the messy job. humm, maybe i get you wrong here, but once the index is parsed, more-or-less all the demuxer's job is done. at least in xine stuff like buffer handling is done outside the demuxer layer anyway. so most of the demuxer code deals with parsing the stream syntax (and for xine some code is needed to handle threads) and that code is (unfortunately) very format-specific :-( cheers, guenter -- time is a funny concept |
From: Miguel F. <mi...@ce...> - 2002-05-29 10:33:59
|
Hi Mike, Hi Guenter, I don't see this much of common code in demuxers. It is true that demuxers have a common and very special "logic", and this became more obvious after mine and Thibaut work to improve seeking. But this logic is highly dependent on demuxer oddities. One thing that can improve demux programing are functions like xine_flush_engine. This one abstracts the internals needed to reset the engine, so changes there will be much easier in the future (instead of having to edit all demuxers one by one). BTW, i think video_out are actually duplicating much more code. A helper module (or function) to receive frame/window dimensions and return output size, taking care of aspect ratio and zooming would be very interesting... regards, Miguel On Wed, 2002-05-29 at 00:11, Mike Melanson wrote: > On Wed, 29 May 2002, Guenter Bartsch wrote: > > > anyway, for quite some time now i'm wondering if there's a way to improve > > xine's demuxers. the point is that most demuxers have nearly the same > > code, so it'd be pretty nice if that common code could be moved into a > > seperate module (yeah, i know, i'm not exactly the one who's the first to > > shout "seperate common code!", but in the demuxer case it's a bit heavy). > > the only problem that kept from doing it: i have know idea who to get that > > done. maybe some kind of "master demuxer" that takes some kind of struct > > of function pointers (a "demuxer driver" similar to video output drivers?) > > which are called to handle the specifics of a certain format but handles > > stuff like creating the demux thread, sending init/control buffers ... > > I don't know if I follow this idea. Demuxers have a common > job: Break an input stream down into packets. But they all do it in > different ways. Just like all video decoders have all the same job: Take a > chunk of compressed data and decompress it to a video frame. But they all > get there in completely different ways. I have written 3 xine demuxers so > far (1 hasn't been committed yet) and they are all completely > different. One fetches an index table from the file and demuxes based on > that. One fetches a header and then traverses the frames in order in the > file without building a table in advance. And the third is different > still. > > What parts of the demuxer subsystem are common enough to combine? > > Thanks... > -- > -Mike Melanson > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: <bar...@t-...> - 2002-05-29 13:06:46
|
hi miguel, On 29 May 2002, Miguel Freitas wrote: > I don't see this much of common code in demuxers. It is true that > demuxers have a common and very special "logic", and this became more > obvious after mine and Thibaut work to improve seeking. But this logic > is highly dependent on demuxer oddities. just had a closer look and i must more-or-less agree with you here. i was hoping that it could be possible to more-or-less drag out all the thread-related code, but that really seems to be difficult and its questionable if this would really improve readability. problably doing some documentation in the xine hacker's guide about this could help a lot more here. > One thing that can improve demux programing are functions like > xine_flush_engine. This one abstracts the internals needed to reset the > engine, so changes there will be much easier in the future (instead of > having to edit all demuxers one by one). > > BTW, i think video_out are actually duplicating much more code. A helper > module (or function) to receive frame/window dimensions and return > output size, taking care of aspect ratio and zooming would be very > interesting... yeah, both ideas sound good to me. for demuxers a send_control_buffer() utility function could also be usefull which automatically sends a control buffer to audio and video fifo. i guess you're right that both cases could be improved by such rather small enhancements and a redesign is inappropriate for both cases. keep up the good work, guenter -- time is a funny concept |
From: Miguel F. <mi...@ce...> - 2002-06-04 11:19:06
|
Hi Guenter, Since you are going to make api changes i'd like to remember that we need a simple way to report the ui about unknown/unhandled codecs. Yesterday i commited a few messages to cvs reporting it, but the user will rarely see these warnings. (they get a little lost in console messages, and the messages from playing logo make previous things to roll out of screen). We have two cases of unknown codecs currently: 1) codecs with no buffer type assigned. These are not listed in buffer_types.c therefore can be easily detected in demuxer initialization. Most demuxers used to ignore unknown audio codecs (just report as a warning) and fail to start when the video format is unknown. 2) codecs with fourcc listed in buffer_types.c but no plugin loaded to handle them (either the user has deleted the plugin or it have never been coded). These are only detected at decoder stages when we try to find the registered plugin. We must have a way of reporting both cases. Ideas... - ui would register a callback function like: xine_report_codec_cb( int audio_or_video, uint32_t fourcc, char *description, int handled); This function would normally be called from decoder threads, reporting if this format is handled or not. For the type (1) above, it would be demuxer's job to call this function (of course with description=""). - we change demuxers to also test for registered plugin given a buf_type. this might be a little strange within xine architecture, but the test is trivial (and can be implemented by a helper function, hiding decoder details from demuxers). By detecting this in demuxer stage the codec report can be done without callbacks, for example, by filling some structure provided in xine_play. i think we must fix this issue now, delivering data to frontends decide how to best warn the user of missing codecs. comments? Miguel |
From: <bar...@t-...> - 2002-06-04 18:00:49
|
hi miguel, On 4 Jun 2002, Miguel Freitas wrote: > Since you are going to make api changes i'd like to remember that we > need a simple way to report the ui about unknown/unhandled codecs. actually i thought that was already taken care of by the log features? most of the time you don't want to stop playback because of a missing codec but just continue without audio/video (e.g. if you accidently switch to a dts sound channel you don't want xine to stop with an error message). so i thought it'd be enough for xine to report the lack of an decoder in the xine log messages so the user will be able to find that and more informations if he/she is interested. ...of course this means that the log window should no longer be hidden from the user - one of the first things i intend to fix when i start working on xine-ui2 :) anyway, if you think this isn't enough, i think the callback idea is nice, but i think we should add a more generic async-error-report feature there, similar to x11. so a general xine_register_error_handler (xine, cb); would be appropriate. because of xine's architecture and the design of some system layers (e.g. mpeg demuxers have no idea what audio formats they'll find in the stream) i think there will be more cases in the future where errors will be detected during playback. cheers, guenter -- time is a funny concept |
From: Siggi L. <si...@us...> - 2002-06-04 18:56:38
|
On Tue, 4 Jun 2002, Guenter Bartsch wrote: [...] > > Since you are going to make api changes i'd like to remember that we > > need a simple way to report the ui about unknown/unhandled codecs. > > actually i thought that was already taken care of by the log features? > most of the time you don't want to stop playback because of a missing > codec but just continue without audio/video (e.g. if you accidently switch > to a dts sound channel you don't want xine to stop with an error message). > > so i thought it'd be enough for xine to report the lack of an decoder in > the xine log messages so the user will be able to find that and more > informations if he/she is interested. > > ...of course this means that the log window should no longer be hidden > from the user - one of the first things i intend to fix when i start > working on xine-ui2 :) Hmmm, I don't think that ordinary users will be interested in all of the logs. Actually, I'm not even interested in them most of the time. > anyway, if you think this isn't enough, i think the callback idea is nice, > but i think we should add a more generic async-error-report feature there, > similar to x11. so a general > > xine_register_error_handler (xine, cb); > > would be appropriate. because of xine's architecture and the design of > some system layers (e.g. mpeg demuxers have no idea what audio formats > they'll find in the stream) i think there will be more cases in the future > where errors will be detected during playback. Hmmm, at least for missing video codecs (and maybe audio codecs as well), an OSD warning message would be nice, but you could probably use your error handler mechanism to produce one, so maybe that's the way to go. It would be extremely useful to have some additional information (similar to syslog facilities/levels) available for the error handler to decide what to do. Just my 0.02, Siggi |
From: <bar...@t-...> - 2002-06-04 19:12:03
|
hi siggi, On Tue, 4 Jun 2002, Siggi Langauf wrote: > > ...of course this means that the log window should no longer be hidden > > from the user - one of the first things i intend to fix when i start > > working on xine-ui2 :) > > Hmmm, I don't think that ordinary users will be interested in all of the > logs. Actually, I'm not even interested in them most of the time. erm - the log window was specifically designed for end-users - unfortunately there's the tendency to log debug info to it, which is of course wrong and i'm trying to remove such code whenever i encounter it. adding a button to the panel to pop up the log window of course doesn't mean to show the window all the time, but if something goes wrong users could be interested in more information so its a good idea to give them the opportunity to get it. I'd also like to turn the log window into a general online help window, so faq, readme and other documentation can be displayed there as well. i think this is especially usefull for end-users which have pre-installed xine so they don't have to find out where their distribution hides documentation (/usr/share/doc/...) but can find helpfull information right away. cheers, guenter -- time is a funny concept |
From: Daniel Caujolle-B. <seg...@cl...> - 2002-06-04 20:02:29
|
Hi Guenter, Guenter Bartsch wrote: > hi siggi, > > On Tue, 4 Jun 2002, Siggi Langauf wrote: > > >>>...of course this means that the log window should no longer be hidden >>>from the user - one of the first things i intend to fix when i start >>>working on xine-ui2 :) >> >>Hmmm, I don't think that ordinary users will be interested in all of the >>logs. Actually, I'm not even interested in them most of the time. > > > erm - the log window was specifically designed for end-users - > unfortunately there's the tendency to log debug info to it, which is of > course wrong and i'm trying to remove such code whenever i encounter it. > > adding a button to the panel to pop up the log window of course doesn't > mean to show the window all the time, but if something goes wrong users > could be interested in more information so its a good idea to give them > the opportunity to get it. I'd also like to turn the log window into a > general online help window, so faq, readme and other documentation can be > displayed there as well. i think this is especially usefull for end-users > which have pre-installed xine so they don't have to find out where their > distribution hides documentation (/usr/share/doc/...) but can find > helpfull information right away. Right now ( i guess you saw the #warning i put in xine-ui about log window and keybinding editor), you can show the log window using a button. Personnaly, i think putting a button for this feature in the panel window isn't a good idea, it's a lot of work for something (i bet) user never take care, but, as usual, it's only my opinion. About the readme, etc.., i' asking myself here: did you ever use the setup window ?? ;-) HELP, README and FAQ (last two localized, if possible), are already there for many months now (since setup window creation, IIRC). Cheers. -- 73's de Daniel, F1RMB. -=- Daniel Caujolle-Bert -=- seg...@cl... -=- -=- f1...@f1... (AMPR NET) -=- |
From: <bar...@t-...> - 2002-06-04 20:13:18
|
hi daniel, On Tue, 4 Jun 2002, Daniel Caujolle-Bert wrote: > Personnaly, i think putting a button for this feature in the > panel window isn't a good idea, it's a lot of work for something (i bet) > user never take care, but, as usual, it's only my opinion. humm - i think i'll never get this. why is adding a simple "?" button so much work? :) and i think if done correctly users will notice and use this feature. the key is to label the button correctly as an information/help button ("?" or "i" or "HELP" would be nice). > About the readme, etc.., i' asking myself here: did you ever use the > setup window ?? ;-) HELP, README and FAQ (last two localized, if > possible), are already there for many months now (since setup window > creation, IIRC). actually i stumbled accross it some time ago, yes. the sad thing is just that this is the wrong place for online help - who would look for online help in the setup window?!? cheers, guenter -- time is a funny concept |
From: Daniel Caujolle-B. <seg...@cl...> - 2002-06-04 20:19:40
|
Hi, Guenter Bartsch wrote: > hi daniel, > > On Tue, 4 Jun 2002, Daniel Caujolle-Bert wrote: > > >>Personnaly, i think putting a button for this feature in the >>panel window isn't a good idea, it's a lot of work for something (i bet) >>user never take care, but, as usual, it's only my opinion. > > > humm - i think i'll never get this. why is adding a simple "?" button so > much work? :) Yep, button * skins == gimp disease ;-) > > and i think if done correctly users will notice and use this feature. the > key is to label the button correctly as an information/help button ("?" or > "i" or "HELP" would be nice). I put it in the setup window, since as i see, users go very often in this window ;-) > >> About the readme, etc.., i' asking myself here: did you ever use the >>setup window ?? ;-) HELP, README and FAQ (last two localized, if >>possible), are already there for many months now (since setup window >>creation, IIRC). > > > actually i stumbled accross it some time ago, yes. the sad thing is just > that this is the wrong place for online help - who would look for online > help in the setup window?!? But we can easilly create a generic help window, but non skinned. But where is the best log button location ? (Note: xitk permit to put redundant buttons.... i hope ;-) ). Ah, is someone tested the keybinding editor, i haven't get any comment/flame/... ;-), perhaps it's plain suck, but we have one now ;-). Cheers. -- 73's de Daniel, F1RMB. -=- Daniel Caujolle-Bert -=- seg...@cl... -=- -=- f1...@f1... (AMPR NET) -=- |