From: Mathieu R. <mro...@en...> - 2005-02-25 14:57:33
|
Charles, Xine already features a plugin (xineplug_inp_dvd) that plays dvds using dvdnav with all the features that xine-dvdnav has. Have I missed something? Is there anything that this other plugin does differently/better? I'm very interested in anything that is related to playing dvds on xine. About your compilation problem, it looks like you need to specify the folder in which xine's header files are. You should look at the README (or the makefile) to figure out how you must define that path. Mat -----Original Message----- From: xin...@li... [mailto:xin...@li...] On Behalf Of Charles Chou Sent: Thursday, February 24, 2005 8:06 PM To: xin...@li... Subject: [xine-devel] xine-dvdnav Hello, I have been trying to add dvdnav to xine. I have downloaded the source for xine-lib-1.0 and xine-ui-0.99.3 and successfully built the libraries and xine executables. I also downloaded and installed libdvdnav-0.1.10, libdvdread-0.9.4. However, when I tried to build xine-dvdnav-0.9.13 I get the following errors: input_dvdnav.c:61:25: xine/events.h: No such file or directory input_dvdnav.c:63:34: xine/spu_decoder_api.h: No such file or directory input_dvdnav.c:150: parse error before "mrl_t" input_dvdnav.c:150: warning: no semicolon at end of struct or union input_dvdnav.c:159: parse error before '}' token input_dvdnav.c:159: warning: type defaults to `int' in declaration of `dvdnav_input_plugin_t' ..... The other errors and warnings are probably due to the fact that xine/events.h and xine/spu_decoder_api.h were not found. Can someone please point me to the right source packages or places where I can get answers in order to successfully build xine-dvdnav? Many thanks. Best Regards, Charles Chou ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ xine-devel mailing list xin...@li... https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Charles C. <cc...@ki...> - 2005-02-26 01:55:47
|
Hello List, Thanks very much for the replies. Indeed xine-lib 1.0 has dvdnav built in. There is one more challenge on this topic. I am also trying to get xine running on a VIA CLE266 platform. There is a special version of xine on sourceforge.net called VeXP which I have downloaded and built and it ran OK on the machine, with occasional crashes and lock-ups. I believe the xine-lib for this VeXP is an old one. However, it contains modified mpeg library calls to utilize the on-board MPEG2 decoder chip. I would like to know if any one on this list has ported the current version of xine-lib to run on this platform? Best Regards, Charles Chou |
From: Xavier B. <xb...@ke...> - 2005-02-26 15:32:28
|
Charles Chou wrote: > Hello List, > > Thanks very much for the replies. Indeed xine-lib 1.0 has dvdnav built in. > > There is one more challenge on this topic. I am also trying to get xine > running on a VIA CLE266 platform. There is a special version of xine on > sourceforge.net called VeXP which I have downloaded and built and it ran OK > on the machine, with occasional crashes and lock-ups. I believe the xine-lib > for this VeXP is an old one. However, it contains modified mpeg library > calls to utilize the on-board MPEG2 decoder chip. I would like to know if > any one on this list has ported the current version of xine-lib to run on > this platform? > > Best Regards, > Charles Chou I'm not a xine developper so that is none of my business but I own a Via board too, and I know the background of this pretty well. So here are facts, and not stupid marketing tricks : 1/ VeXP is a fork of xine, made without asking _anything_ to xine devs. It is based on an old version of xine-lib and thus contains flaws that are now fixed. The changes they made to xine are _BAD_ and will never get back into xine-lib, if this was even possible. The GPL allows them to do that, but this is, well, let's say terribly stupid, at best... They advertise this as an "enhanced xine"... 2/ To run this sub-par version of xine-lib, you need to use broken binary drivers, only available for outdated Linux distros, as root. Remember I just said the xine-lib version they used have flaws ? some are security related... 3/ xine natively supports hardware MPEG2 acceleration with CLE266, thx to the unichrome project, in a clean way 4/ Via has just done the same with MPlayer, again without previously get in touch with Mplayer's devs, which also already support hardware MPEG2 acceleration, again thx to the unichrome project. This is again announced to be an enhancement. 5/ the unichrome project did not received any information nor help nor even acknowledge of existence from Via There's certainly more to say on this matter, and I might not be very accurate, but now you got a little piece of background to build an opinion. Personnally, I deeply regret that I once gived my money to this company on the sole fact they claimed and seemed to support Linux and open-source. Looking back, I don't call that support, at any rate... Sorry but I'm really feeling tired of VIA bullshitting... And I'm just an "open source enthousiast", not one of the devs of either xine, MPlayer or Unichrome. I guess if I was one of them I'll be really, really angry ... Regards, Xavier |
From: Charles C. <cc...@ki...> - 2005-02-27 21:22:09
|
Hi Xavier, Thank you for sharing your insights (and frustrations). I have been trying to get the VIA machine to play DVD on Linux for some time now. So far the most satisfactory solution is actually the latest generic xine-lib (1.0) running on a RedHat 9.0 (2.4.20-8 kernel) with no special code to take advantage of the hardware decoder. The CPU is running at about 60%-70% with occasional frame drops, but the picture is high quality and the playback is stable. Regarding your comment: > 3/ xine natively supports hardware MPEG2 acceleration with CLE266, thx > to the unichrome project, in a clean way > I guess you meant the XvMC extension that is in newer Linux distributions. I have tried xine on a Mandrake 9.2 as well which has the XvMC and the result was great, with CPU utilization at 13%-16% and the playback nearly perfect. However, when I switch the monitor from an LCD to plasma, the machine simply fail to load X and crashed. I guess this is more of an XvMC/Unichrome issue than xine. So for now I will just stay with RedHat9 with no XvMC on the VIA platform. Regards, Charles Chou |
From: Michael R. <mr...@us...> - 2005-02-25 16:38:54
|
Hi Mat, > Xine already features a plugin (xineplug_inp_dvd) that plays dvds using > dvdnav with all the features that xine-dvdnav has. Have I missed > something? Is there anything that this other plugin does > differently/better? No, this other plugin is just an ancient version of what is now inluded into the xine-lib tarball. (We used to ship dvdnav separately some time ago.) Michael -- "Premature optimization is the root of all evil." -Donald E. Knuth |
From: Mathieu R. <mro...@en...> - 2005-02-25 17:20:34
|
Michael, Thank you for the precision. While we're on the dvd plugin subject, I'd like to bring to your attention what looks like a missing feature. There are apparently ways for a dvd to modify on-the-fly the overlay palette. The only DVD I have found that uses this is a test DVD made by Microsoft WHQL. It is called "Test Annex 3" and can be ordered here: http://www.microsoft.com/whdc/whql/nethctcd.aspx On one of the menus, the user can select how a TEST overlay appears. There are buttons for choosing different colors and opacities. On a regular DVD player, the overlay changes color according to the button pressed. When played with xine, the TEST overlay is always transparent, no matter what button is pressed. I have not investigated the root of this bug yet but I thought I would mention it here in case anybody has something to say about it. And by the way, the patch you sent some time ago for letting an activated button show up before flusing the overlays did not make its way in 1.0. I am using this patch ever since and never ever had any problem. I think it would be a good idea to apply it once and for all. I can generate a new patch if you want to. One more thing. There are restrictions defined on DVD that tells a player whether some operations are permitted or not (for example, a user should not be allowed to skip the FBI warning, or fast-forward in a menu). This information is available by browsing the dvdnav structures. I would like to add this "denial of operation" in xine to make it more compliant. However, I can't see how I could do this using the current interface. The idea would be to have means to refuse executing operations that are marked as prohibited, but also to report to the ui the disabled operations so those buttons would be greyed, for example. What do you guys think? Mat -----Original Message----- From: Michael Roitzsch [mailto:mr...@us...] Sent: Friday, February 25, 2005 11:39 AM To: xin...@li... Cc: Mathieu Routhier Subject: Re: [xine-devel] xine-dvdnav Hi Mat, > Xine already features a plugin (xineplug_inp_dvd) that plays dvds using > dvdnav with all the features that xine-dvdnav has. Have I missed > something? Is there anything that this other plugin does > differently/better? No, this other plugin is just an ancient version of what is now inluded into the xine-lib tarball. (We used to ship dvdnav separately some time ago.) Michael -- "Premature optimization is the root of all evil." -Donald E. Knuth |
From: Matthias H. <ma...@ms...> - 2005-02-25 20:32:33
|
Hi Mat, > One more thing. There are restrictions defined on DVD that tells a player > whether some operations are permitted or not (for example, a user should not > be allowed to skip the FBI warning, or fast-forward in a menu). This > information is available by browsing the dvdnav structures. I would like to > add this "denial of operation" in xine to make it more compliant. However, PLEASE NOOOO! These so-called user prohibitions are just made for the annoiance of users. I cannot imagine why *anybody* would like to have them. This is just the same as with region codes, xine doesn't care about that crap, and that is good. Appearantly, industries are moving in the same direction, as region code free players sell better than region code locked. I hope it is only a matter of time until first user prohibition free players show up in the market. Yes, they won't be able to have a DVD certified logo on their box. Who cares? The average user doesn't even know such things like certification logos exist. They just want to play DVDs. My 2 cents Matthias -- Matthias Hopf <mh...@su...> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ ma...@ms... Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de |
From: Mathieu R. <mro...@en...> - 2005-02-25 21:44:53
|
Matthias, I do understand your point. And as a user, I partially agree :) I thought a bit more about this. I think a nice compromise would be to communicate the information about restrictions through a new type of xine event. It would then be up to the ui to disable the buttons and enforce those restrictions if it wants to. This would require a minimal amount of modifications and would not change the library interface in any way. What do you think? Mathieu -----Original Message----- From: xin...@li... [mailto:xin...@li...] On Behalf Of Matthias Hopf Sent: Friday, February 25, 2005 3:28 PM To: Xine DEV ML Subject: Re: [xine-devel] DVD misc Hi Mat, > One more thing. There are restrictions defined on DVD that tells a player > whether some operations are permitted or not (for example, a user should not > be allowed to skip the FBI warning, or fast-forward in a menu). This > information is available by browsing the dvdnav structures. I would like to > add this "denial of operation" in xine to make it more compliant. However, PLEASE NOOOO! These so-called user prohibitions are just made for the annoiance of users. I cannot imagine why *anybody* would like to have them. This is just the same as with region codes, xine doesn't care about that crap, and that is good. Appearantly, industries are moving in the same direction, as region code free players sell better than region code locked. I hope it is only a matter of time until first user prohibition free players show up in the market. Yes, they won't be able to have a DVD certified logo on their box. Who cares? The average user doesn't even know such things like certification logos exist. They just want to play DVDs. My 2 cents Matthias -- Matthias Hopf <mh...@su...> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ ma...@ms... Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ xine-devel mailing list xin...@li... https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Mike M. <mi...@mu...> - 2005-02-25 22:34:11
|
Mathieu Routhier wrote: > Matthias, > > I do understand your point. And as a user, I partially agree :) > > I thought a bit more about this. I think a nice compromise would be to > communicate the information about restrictions through a new type of xine > event. It would then be up to the ui to disable the buttons and enforce > those restrictions if it wants to. This would require a minimal amount of > modifications and would not change the library interface in any way. > > What do you think? When you put it like this, I see possibilities: After xine installation, the first time you try to bypass the FBI warning and the 5-15 minutes of forced ads, the UI could use this new event mechanism to pop up a dialog informing you that "The Man" is trying to force him to sit through advertisements and that technically the player software should disallow skipping; but because xine loves you, it will offer you the ability to skip these ads. "Would you like to enable unconditional skipping now? [X] Yes [ ] No" Good marketing gimmick, that is what I am driving at here... -- -Mike Melanson |
From: Mathieu R. <mro...@en...> - 2005-02-28 16:23:15
|
> "Would you like to enable unconditional > skipping now? [X] Yes [ ] No" I think the library should remain as is, and allow all operations all the time. The way I see it, skipping restrictions is only a gui/front-end feature. Therefore, my suggestion was to add to xine a new type of event, that the dvd plugin would throw when it encounters a new set of restriction flags. It would then be up to the front-end to take it or leave it. The default behavior would be to ignore the restrictions. Does anybody object? Mat -----Original Message----- From: Mike Melanson [mailto:mi...@mu...] Sent: Friday, February 25, 2005 5:34 PM To: Mathieu Routhier Cc: 'Xine DEV ML' Subject: Re: [xine-devel] DVD misc Mathieu Routhier wrote: > Matthias, > > I do understand your point. And as a user, I partially agree :) > > I thought a bit more about this. I think a nice compromise would be to > communicate the information about restrictions through a new type of xine > event. It would then be up to the ui to disable the buttons and enforce > those restrictions if it wants to. This would require a minimal amount of > modifications and would not change the library interface in any way. > > What do you think? When you put it like this, I see possibilities: After xine installation, the first time you try to bypass the FBI warning and the 5-15 minutes of forced ads, the UI could use this new event mechanism to pop up a dialog informing you that "The Man" is trying to force him to sit through advertisements and that technically the player software should disallow skipping; but because xine loves you, it will offer you the ability to skip these ads. "Would you like to enable unconditional skipping now? [X] Yes [ ] No" Good marketing gimmick, that is what I am driving at here... -- -Mike Melanson |
From: Sander J. <s.j...@gm...> - 2005-03-02 06:52:02
|
My 2 cents... The way its done in Ogle, the restriction flags can be requested by the frontend. Ogle doesn't prevent you from doing anything based on those flags. In my own frontend for Ogle (Goggles) I'm partially following those flags, though the user has a choice to ignore those flags by a setting in the preferences panel. I think it should be up to the frontend to enable/disable certain restrictions... not by the underlying library. Sander On Mon, 28 Feb 2005 11:23:11 -0500, Mathieu Routhier <mro...@en...> wrote: > > "Would you like to enable unconditional > > skipping now? [X] Yes [ ] No" > > I think the library should remain as is, and allow all operations all the > time. The way I see it, skipping restrictions is only a gui/front-end > feature. > > Therefore, my suggestion was to add to xine a new type of event, that the > dvd plugin would throw when it encounters a new set of restriction flags. > It would then be up to the front-end to take it or leave it. The default > behavior would be to ignore the restrictions. > > Does anybody object? > > Mat > > -----Original Message----- > From: Mike Melanson [mailto:mi...@mu...] > Sent: Friday, February 25, 2005 5:34 PM > To: Mathieu Routhier > Cc: 'Xine DEV ML' > Subject: Re: [xine-devel] DVD misc > > Mathieu Routhier wrote: > > Matthias, > > > > I do understand your point. And as a user, I partially agree :) > > > > I thought a bit more about this. I think a nice compromise would be to > > communicate the information about restrictions through a new type of xine > > event. It would then be up to the ui to disable the buttons and enforce > > those restrictions if it wants to. This would require a minimal amount of > > modifications and would not change the library interface in any way. > > > > What do you think? > > When you put it like this, I see possibilities: After xine > installation, the first time you try to bypass the FBI warning and the > 5-15 minutes of forced ads, the UI could use this new event mechanism to > pop up a dialog informing you that "The Man" is trying to force him to > sit through advertisements and that technically the player software > should disallow skipping; but because xine loves you, it will offer you > the ability to skip these ads. "Would you like to enable unconditional > skipping now? [X] Yes [ ] No" > > Good marketing gimmick, that is what I am driving at here... > -- > -Mike Melanson > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel > |
From: Mathieu R. <mro...@en...> - 2005-03-02 14:39:03
|
Hi, I think we all agree on this :) Here's the definition of the new event type and the associated data structure. Can somebody add this to xine.h.in and commit? I will post a patch to input_dvd.c shortly. /* specific to DVD */ #define XINE_EVENT_DVD_RESTRICTIONS 400 /* * DVDs contain instructions to disable certain user operations in * certain sequences. When the DVD plugin detects a change in these * flags, it will generate an event of type XINE_EVENT_DVD_RESTRICTIONS. * The data member of the event is a pointer to this structure. * When a given flag is non-zero, the operation is prohibited. It is * up to the front-end to either ignore or implement those restrictions. */ typedef struct { unsigned char video_pres_mode_change; unsigned char karaoke_audio_pres_mode_change; unsigned char angle_change; unsigned char subpic_stream_change; unsigned char audio_stream_change; unsigned char pause_on; unsigned char still_off; unsigned char button_select_or_activate; unsigned char resume; unsigned char chapter_menu_call; unsigned char angle_menu_call; unsigned char audio_menu_call; unsigned char subpic_menu_call; unsigned char root_menu_call; unsigned char title_menu_call; unsigned char backward_scan; unsigned char forward_scan; unsigned char next_pg_search; unsigned char prev_or_top_pg_search; unsigned char time_or_chapter_search; unsigned char go_up; unsigned char stop; unsigned char title_play; unsigned char chapter_search_or_play; unsigned char title_or_time_play; } xine_dvd_restrictions_t; Mat -----Original Message----- From: xin...@li... [mailto:xin...@li...] On Behalf Of Sander Jansen Sent: Wednesday, March 02, 2005 1:52 AM To: Mathieu Routhier Cc: xin...@li... Subject: Re: [xine-devel] DVD misc My 2 cents... The way its done in Ogle, the restriction flags can be requested by the frontend. Ogle doesn't prevent you from doing anything based on those flags. In my own frontend for Ogle (Goggles) I'm partially following those flags, though the user has a choice to ignore those flags by a setting in the preferences panel. I think it should be up to the frontend to enable/disable certain restrictions... not by the underlying library. Sander On Mon, 28 Feb 2005 11:23:11 -0500, Mathieu Routhier <mro...@en...> wrote: > > "Would you like to enable unconditional > > skipping now? [X] Yes [ ] No" > > I think the library should remain as is, and allow all operations all the > time. The way I see it, skipping restrictions is only a gui/front-end > feature. > > Therefore, my suggestion was to add to xine a new type of event, that the > dvd plugin would throw when it encounters a new set of restriction flags. > It would then be up to the front-end to take it or leave it. The default > behavior would be to ignore the restrictions. > > Does anybody object? > > Mat > > -----Original Message----- > From: Mike Melanson [mailto:mi...@mu...] > Sent: Friday, February 25, 2005 5:34 PM > To: Mathieu Routhier > Cc: 'Xine DEV ML' > Subject: Re: [xine-devel] DVD misc > > Mathieu Routhier wrote: > > Matthias, > > > > I do understand your point. And as a user, I partially agree :) > > > > I thought a bit more about this. I think a nice compromise would be to > > communicate the information about restrictions through a new type of xine > > event. It would then be up to the ui to disable the buttons and enforce > > those restrictions if it wants to. This would require a minimal amount of > > modifications and would not change the library interface in any way. > > > > What do you think? > > When you put it like this, I see possibilities: After xine > installation, the first time you try to bypass the FBI warning and the > 5-15 minutes of forced ads, the UI could use this new event mechanism to > pop up a dialog informing you that "The Man" is trying to force him to > sit through advertisements and that technically the player software > should disallow skipping; but because xine loves you, it will offer you > the ability to skip these ads. "Would you like to enable unconditional > skipping now? [X] Yes [ ] No" > > Good marketing gimmick, that is what I am driving at here... > -- > -Mike Melanson > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ xine-devel mailing list xin...@li... https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Miguel F. <mfr...@gm...> - 2005-03-02 14:48:10
|
On Wed, 2 Mar 2005 09:38:53 -0500, Mathieu Routhier <mro...@en...> wrote: > I think we all agree on this :) Here's the definition of the new event type > and the associated data structure. Can somebody add this to xine.h.in and > commit? I will post a patch to input_dvd.c shortly. looks good to me. i guess we may commit it as soon as you send us the complete patch (unless, of course, anybody objects...) miguel |
From: Michael R. <mr...@us...> - 2005-03-02 20:14:27
|
Hi, > > I think we all agree on this :) Here's the definition of the new event > > type and the associated data structure. Can somebody add this to > > xine.h.in and commit? I will post a patch to input_dvd.c shortly. > > looks good to me. i guess we may commit it as soon as you send us the > complete patch (unless, of course, anybody objects...) Just a thought from me: I would like some additional sanity checking for certain special cases. Example: We generally want to allow arbitrary seeking and skipping, but we may want to deny it, if there are cell commands, because skipping over those can move the VM into a bad state. Unfortunately, this information is not available to frontends, so the frontend might not be the best place to make such decisions. I would still prefer a configurable restriction level in libdvdnav, which specifies, how much restriction you want to follow. But this can be done in addition to the current event solution, which would still be needed to enable/disable the corresponding UI elements. It's just that I would like to move the actual enforcing of the restrictions into libdvdnav, because it is common code and libdvdnav has more context knowledge to make smarter decisions. Michael -- /* When we have more time, we can teach the penguin to say * "By your command" or "Activating turbo boost, Michael". */ 2.2.16 /usr/src/linux/arch/sparc/prom/sun4prom.c |
From: Mathieu R. <mro...@en...> - 2005-03-02 20:54:14
|
Michael, If we move the restriction management in libdvdnav, how can it then refuse operations such as "pause" and "speed x2"? I agree though that we should add a feature in libdvdnav to report the set of prohibited operations. I guess here too, a special event type should be created: DVDNAV_RESTRICTIONS (analogous to DVDNAV_BLOCK_OK and DVDNAV_CELL_CHANGE). Right now, in my implementation of the restrictions, I have to access private fields of the dvdnav_t structure. But how do you want to detect the operations that would induce a bad state of the VM? Mat -----Original Message----- From: Michael Roitzsch [mailto:mr...@us...] Sent: Wednesday, March 02, 2005 3:14 PM To: xin...@li...; Miguel Freitas Cc: Mathieu Routhier Subject: Re: [xine-devel] DVD misc Hi, > > I think we all agree on this :) Here's the definition of the new event > > type and the associated data structure. Can somebody add this to > > xine.h.in and commit? I will post a patch to input_dvd.c shortly. > > looks good to me. i guess we may commit it as soon as you send us the > complete patch (unless, of course, anybody objects...) Just a thought from me: I would like some additional sanity checking for certain special cases. Example: We generally want to allow arbitrary seeking and skipping, but we may want to deny it, if there are cell commands, because skipping over those can move the VM into a bad state. Unfortunately, this information is not available to frontends, so the frontend might not be the best place to make such decisions. I would still prefer a configurable restriction level in libdvdnav, which specifies, how much restriction you want to follow. But this can be done in addition to the current event solution, which would still be needed to enable/disable the corresponding UI elements. It's just that I would like to move the actual enforcing of the restrictions into libdvdnav, because it is common code and libdvdnav has more context knowledge to make smarter decisions. Michael -- /* When we have more time, we can teach the penguin to say * "By your command" or "Activating turbo boost, Michael". */ 2.2.16 /usr/src/linux/arch/sparc/prom/sun4prom.c |
From: Michael R. <mr...@us...> - 2005-03-04 15:57:43
|
Hi, > If we move the restriction management in libdvdnav, how can it then refuse > operations such as "pause" and "speed x2"? You are right here. > But how do you want to detect the operations that would induce a bad state > of the VM? In general, you cannot (obviously), but that's why I think there are two categories of user restrictions: * good ones, that prevent you from doing actions the author knows will put the VM in trouble * bad ones, which just prohibit things because the author does not want you to execute them (like skipping copyright screens) My point is that it would be a good idea to detect some common cases for good restrictions (like seek/skip disabled in the presence of cell commands), which has to be done inside libdvdnav. My proposal: A new function for libdvdnav which allows you to set the restriction level you want (like the current function for setting the VM's region register). With this level set to "no restrictions", libdvdnav will always report all restrictions to be cleared. With this level set to "all restrictions", the restrictions from the DVD will be reported. A setting "sane restrictions" would check for some common cases of good restrictions and only report those. Having that in mind, maybe reporting the restrictions as a bitfield or an array with enum index would be a good idea, because it would allow masking the restrictions with &. But since this proposal does not interfere with your current plan (the function and the filtering can be done later), you can just go ahead and commit your code, which I fully agree with (now that I understand the problem a better). Michael -- /* * Hash table gook.. */ 2.4.0-test2 /usr/src/linux/fs/buffer.c |
From: Sander J. <s.j...@gm...> - 2005-03-03 19:40:11
|
It would be nice if we can get a domain change message to the frontend(s). Its handy so one can determine if they're in a menu or not.... and act accordingly. Sander On Wed, 2 Mar 2005 11:48:05 -0300, Miguel Freitas <mfr...@gm...> wrote: > On Wed, 2 Mar 2005 09:38:53 -0500, Mathieu Routhier > <mro...@en...> wrote: > > I think we all agree on this :) Here's the definition of the new event type > > and the associated data structure. Can somebody add this to xine.h.in and > > commit? I will post a patch to input_dvd.c shortly. > > looks good to me. i guess we may commit it as soon as you send us the > complete patch (unless, of course, anybody objects...) > > miguel > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel > |
From: Jerome <je...@ki...> - 2005-03-03 20:39:04
|
On Thu, 2005-03-03 at 13:39 -0600, Sander Jansen wrote: >It would be nice if we can get a domain change message to the >frontend(s). Its handy so one can determine if they're in a menu or >not.... and act accordingly. > > Sander > I personally use XINE_EVENT_UI_NUM_BUTTONS event for that. It worked like a charm so far. Jerome "poitch" Poichet When only code matters Key fingerprint =3D CF22 CE30 3223 8940 5849 5828 E08B CD06 A28D 2C59 Key ID =3D A28D2C59 -- random quote -- No woman ever falls in love with a man unless she has a better opinion of him than he deserves. -- Edgar Watson Howe |
From: Marcel J. <ko...@ho...> - 2005-02-26 00:35:19
|
On Friday 25 February 2005 23:33, Mike Melanson wrote: > When you put it like this, I see possibilities: After xine > installation, the first time you try to bypass the FBI warning and the > 5-15 minutes of forced ads, the UI could use this new event mechanism to > pop up a dialog informing you that "The Man" is trying to force him to > sit through advertisements and that technically the player software > should disallow skipping; but because xine loves you, it will offer you > the ability to skip these ads. "Would you like to enable unconditional > skipping now? [X] Yes [ ] No" Dialogs are not a nice option for my LIRC controlled xine. Pop ups are even more nasty than the warning itself (I usually just wait the few seconds the FBI warning displays instead of skipping it). Anyways, if it gets implemented in xine, please keep a patch available to undo this behaviour :-) Shouldn't these warnings be displayed by ripping software instead of player software ? Regards, Marcel |
From: Michael R. <mr...@us...> - 2005-02-27 15:01:19
|
Hi Marcel, > Dialogs are not a nice option for my LIRC controlled xine. > Pop ups are even more nasty than the warning itself (I usually just wait > the few seconds the FBI warning displays instead of skipping it). I agree. A player application should avoid to interrupt the user's attention to the playback. > Anyways, if it gets implemented in xine, please keep a patch available to > undo this behaviour :-) Why not a config option? (There is an according TODO item in libdvdnav.) Michael -- panic ("Splunge!"); 2.2.16 /usr/src/linux/drivers/scsi/psi240i.c |
From: Marcel J. <ko...@ho...> - 2005-02-27 15:23:53
|
On Sunday 27 February 2005 16:00, Michael Roitzsch wrote: > Why not a config option? (There is an according TODO item in libdvdnav.) Sounds fine to me. Regards, Marcel |
From: Dave D. <do...@do...> - 2005-02-28 05:27:32
|
On Sat, Feb 26, 2005 at 01:35:14AM +0100, Marcel Janssen wrote: > (I usually just wait the few seconds the FBI warning displays > instead of skipping it). Things like the FBI warning and MPAA rating card aren't so bad, but you still have idiot DVD makers who throw a bunch of movie trailers on the front and disable all the bypass controls. The "Bruce Almighty" DVD I watched the other night had that "feature". It's also gotten to the point that I want to explicitly disable all of the animated transitions within the menus themselves. Some of the special edition DVDs I've seen have been getting ridiculous in that regard, taking several seconds (and showing me footage I'd rather not see until after I've seen the movie) on each menu operation. I haven't done much DVD playing with xine so I don't know if it can do this or not. -Dave Dodge |
From: Michael R. <mr...@us...> - 2005-02-28 10:38:32
|
Hi Dave, > It's also gotten to the point that I want to explicitly disable all of > the animated transitions within the menus themselves. Some of the > special edition DVDs I've seen have been getting ridiculous in that > regard, taking several seconds (and showing me footage I'd rather not > see until after I've seen the movie) on each menu operation. I > haven't done much DVD playing with xine so I don't know if it can do > this or not. You can skip the menu transitions with xine manually, but automatically skipping them could be very error prone, because as far as dvdnav is concerned, menu transitions are just a small animation being played. There are not different from a feature you play, except for their length. Michael -- die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c |
From: James Courtier-D. <Ja...@su...> - 2005-02-25 22:30:33
|
Mathieu Routhier wrote: > Michael, > > Thank you for the precision. While we're on the dvd plugin subject, I'd > like to bring to your attention what looks like a missing feature. There > are apparently ways for a dvd to modify on-the-fly the overlay palette. The > only DVD I have found that uses this is a test DVD made by Microsoft WHQL. > It is called "Test Annex 3" and can be ordered here: > http://www.microsoft.com/whdc/whql/nethctcd.aspx > > On one of the menus, the user can select how a TEST overlay appears. There > are buttons for choosing different colors and opacities. On a regular DVD > player, the overlay changes color according to the button pressed. When > played with xine, the TEST overlay is always transparent, no matter what > button is pressed. I have not investigated the root of this bug yet but I > thought I would mention it here in case anybody has something to say about > it. This is probably better discussed on the dvd-devel mailing list at dvd.sf.net (The home of libdvdnav) Can you use dvdbackup and make a backup of this DVD, and then post a URL to it, so we can test it also. It would be good to implement support for this is libdvdnav. > > And by the way, the patch you sent some time ago for letting an activated > button show up before flusing the overlays did not make its way in 1.0. I > am using this patch ever since and never ever had any problem. I think it > would be a good idea to apply it once and for all. I can generate a new > patch if you want to. > > One more thing. There are restrictions defined on DVD that tells a player > whether some operations are permitted or not (for example, a user should not > be allowed to skip the FBI warning, or fast-forward in a menu). This > information is available by browsing the dvdnav structures. I would like to > add this "denial of operation" in xine to make it more compliant. However, > I can't see how I could do this using the current interface. The idea would > be to have means to refuse executing operations that are marked as > prohibited, but also to report to the ui the disabled operations so those > buttons would be greyed, for example. What do you guys think? Do you actually have any users requesting it? We only implement features that users actually want. > > Mat > > |
From: Alien <ali...@us...> - 2005-02-25 22:46:01
|
Op vrijdag 25 februari 2005 23:30, schreef James Courtier-Dutton: > Do you actually have any users requesting it? > We only implement features that users actually want. not worth the time developping it, there are more pressing matters to atten= d=20 to... like full 64bit compability... |