Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Samstag, den 06.02.2010, 13:02 +0100 schrieb BOUWSMA Barry: > I'm not even trying to follow this discussion at all, but I > feel I have to chime in to be off-topic... > > On Sat, 6 Feb 2010, hermann pitton wrote: > > > > > > Bye bye Teletext. Nothing for future kernels, huh? > > > > > > > > Yes, you say it. It definitely will go away and we do have not any > > > > influence on that! Did you not notice the very slow update rate these > > > > days? > > > > > > a. NOTHING "will go away". This is empty rant, nothing else it is! > > > In US teletext is dead, yes. In Europe analogue television is close to > > > dead. Yes. > > > But I have found no information source that teletext will disappear in > > > general. At least not in Europe or Germany. > > > So if you keep that up then prove the assertion please. > > > > In the UK too. And after world war II we always followed BBC. > > Not that bad ... > > The BBC has switched over to ``Digital Text'' via the Red Button > service on Freeview. This is based on MHEG, and has the advantage > that pretty much all receivers are built around a particular > platform which specifies inclusion of the Red Button services, > a particular EPG, LCNs, and so on. Be that platform Freeview, or > Sky, or Freesat. > > This is not the case in your country -- the public broadcasters > have adopted MHP which has gone over about as well as a lead > balloon. There is also not a specified platform, but rather any > manufacturer can offer a receiver based on the DVB specifications. > Usually teletext support will be built-in to the decoder; also, > most boxes pass the DVB Teletext information to the television > regenerated as the analogue VBI interval which pretty much every > set supports. > > As far as I know, the proposed Eutelsat Viseo platform being > pushed does not specify a MHP- or MHEG-based replacement for > teletext, nor am I aware of any alternative platforms to take > over and mandate a replacement of the current level teletext. > > Can you even find a MHP-capable settop box in the shops today? > Also, as far as I know, the national MHP service was dropped from > terrestrial broadcasting some years ago, and at best there may > be still a regional and minimal service offered by Bayerischer > Rundfunk, but nothing like one finds on Freeview. > > Conditions have diverged too much between the two countries these > days. In the UK, Sky has a lion's share of the market, while I've > barely seen anything but a few sports bars with a Premiere > subscription. Also while the commercial public service > broadcasters in the UK have relied on terrestrial service through > the country, this has not been true of the comparable private > commercial broadcasters in germany, who are not even participating > in terrestrial broadcasting outside of a handful of strategic > centres. Also, teletext in germany is a service of the individual > broadcasters or contracted out in the commercial case, while the > Teletext and Teletext Holidays and such closing in the UK is its > own service. > > > Without support already in place for a transition away from VBI- > based teletext over the coming years, I can't see it happening. > I know that Austria made a big deal of their MHP-based ORF text > service, but I don't know how great a penetration it has. I've > read tht it requires significant bandwidth of the terrestrial > multiplexes, while conventional teletext requires around that of > an audio channel -- back when ZDFvision was sending MHP data plus > AC3 streams terrestrially, I clocked four MHP streams each with a > data rate comparable to a lower-quality audio stream, together > some twice the data rate of each of the three separate teletext > streams. > > > > > > What slow update rate please? > > > What the hell are you talking about, man? > > > > Previously information available there was updated within minutes, now > > in best case every six hours it seems to me. > > I don't know what services you are viewing; those which I use > are updated within seconds of updated data, and happen to be the > first place I turn to for current information. The amount and > quality of information I get from conventional teletext is far > more impressive than what I see on the BBC's Red Button service. > > > barry bouwsma Hi Barry, sorry for delay and thanks for your advice. I know it was already there previously and is best we have. ZDF is becoming very slow in updating news on page 112 and 113. KiKa seems to be already fully commercial. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
I'm not even trying to follow this discussion at all, but I feel I have to chime in to be off-topic... On Sat, 6 Feb 2010, hermann pitton wrote: > > > > Bye bye Teletext. Nothing for future kernels, huh? > > > > > > Yes, you say it. It definitely will go away and we do have not any > > > influence on that! Did you not notice the very slow update rate these > > > days? > > > > a. NOTHING "will go away". This is empty rant, nothing else it is! > > In US teletext is dead, yes. In Europe analogue television is close to > > dead. Yes. > > But I have found no information source that teletext will disappear in > > general. At least not in Europe or Germany. > > So if you keep that up then prove the assertion please. > > In the UK too. And after world war II we always followed BBC. > Not that bad ... The BBC has switched over to ``Digital Text'' via the Red Button service on Freeview. This is based on MHEG, and has the advantage that pretty much all receivers are built around a particular platform which specifies inclusion of the Red Button services, a particular EPG, LCNs, and so on. Be that platform Freeview, or Sky, or Freesat. This is not the case in your country -- the public broadcasters have adopted MHP which has gone over about as well as a lead balloon. There is also not a specified platform, but rather any manufacturer can offer a receiver based on the DVB specifications. Usually teletext support will be built-in to the decoder; also, most boxes pass the DVB Teletext information to the television regenerated as the analogue VBI interval which pretty much every set supports. As far as I know, the proposed Eutelsat Viseo platform being pushed does not specify a MHP- or MHEG-based replacement for teletext, nor am I aware of any alternative platforms to take over and mandate a replacement of the current level teletext. Can you even find a MHP-capable settop box in the shops today? Also, as far as I know, the national MHP service was dropped from terrestrial broadcasting some years ago, and at best there may be still a regional and minimal service offered by Bayerischer Rundfunk, but nothing like one finds on Freeview. Conditions have diverged too much between the two countries these days. In the UK, Sky has a lion's share of the market, while I've barely seen anything but a few sports bars with a Premiere subscription. Also while the commercial public service broadcasters in the UK have relied on terrestrial service through the country, this has not been true of the comparable private commercial broadcasters in germany, who are not even participating in terrestrial broadcasting outside of a handful of strategic centres. Also, teletext in germany is a service of the individual broadcasters or contracted out in the commercial case, while the Teletext and Teletext Holidays and such closing in the UK is its own service. Without support already in place for a transition away from VBI- based teletext over the coming years, I can't see it happening. I know that Austria made a big deal of their MHP-based ORF text service, but I don't know how great a penetration it has. I've read tht it requires significant bandwidth of the terrestrial multiplexes, while conventional teletext requires around that of an audio channel -- back when ZDFvision was sending MHP data plus AC3 streams terrestrially, I clocked four MHP streams each with a data rate comparable to a lower-quality audio stream, together some twice the data rate of each of the three separate teletext streams. > > What slow update rate please? > > What the hell are you talking about, man? > > Previously information available there was updated within minutes, now > in best case every six hours it seems to me. I don't know what services you are viewing; those which I use are updated within seconds of updated data, and happen to be the first place I turn to for current information. The amount and quality of information I get from conventional teletext is far more impressive than what I see on the BBC's Red Button service. barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack: > Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton: > > Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack: > > > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: > > > > Andreas Oberritter wrote: > > > > > Andy Walls wrote: > > > > > > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by > > > > >>> software running on Dream Multimedia set top boxes. > > > > >> Right, so reverting the patch is not an option. > > > > >> > > > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device > > > > >> node probably a waste of time at this point. > > > > > > > > > > I think so, too. But I guess it's always worth discussing > > > > > alternatives. > > > > > > > > If this discussion happened before 2.6.32 release, and provided that a > > > > different > > > > implementation were agreed, things would be easier, as a different > > > > solution like > > > > your proposal could be decided and used. > > > > > > > > > You cannot expect people reacting immediately if something is wrong. > > > There are and do exist enormous delays between publishing a new kernel > > > and the decision to use it after appropriate system or distro update. > > > So your expectation level is simply wrong. > > > > > > > > > > Now, we have already a regression on a stable kernel, and solving it by > > > > creating another regression is not something smart to do. > > > > > > > > > Yes. Trivial! > > > > > > > > > > >From what I understood, the regression appeared on an old, orphan > > > > application with a non-official patch applied on it. Other applications > > > > with > > > > similar features weren't affected. On the other hand, if the patch got > > > > reverted, > > > > we'll break a maintained application that is used on a great number of > > > > devices, > > > > and whose features depend on the new ioctls. > > > > > > > > > It's truly amazing how the filter system of your perception works, isn't > > > it? :) > > > > > > It's not just "an old, orphaned application with a non-official patch on > > > it." That's nonsense! > > > > > > a. As I stated already, there do exist several patched versions of > > > alevt-dvb. For instance the one that Herman Pitton tested here in public > > > causes a closed demux device error on my machine. That means that it > > > does not run because xine-ui is already using the demux device. > > > And this phenomenon has got nothing to do with the kernel headers! > > > I've tried all possibilities (old kernel headers and actual ones) so I > > > know better than Hermann Pitton does! > > > > > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier > > > whom I helped with my tip to revert that patch) cause a kernel crash > > > with the actual kernel. > > > > > > b. As I also stated already the other teletext application called mtt > > > does officially not exist except for Novell / OpenSuSe distros (at least > > > as far as I have seen and found out). And this one > > > is, as I also stated, not affected by the kernel patch. It's part of a > > > discontinued program suite called xawtv-4.0 pre with a very complex > > > infrastructure behind. > > > > > > Please do not ask me why this one runs without noise - I do not know. > > > > > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is > > > available in almost all Gnu/Linux distros. > > > > > > "Other applications with similar features weren't affected." > > > > > > >From where do you know that the features are "similar"? > > > > > > This is a 100 % phantasy product of your mind that has got nothing to do > > > with existing reality, man! > > > > > > Just one example: alevt-dvb has got an excellent html export filter > > > which makes it possible to export teletext pages as graphical html > > > files. > > > I do not know any other teletext application offering that. > > > > > > > > > > We are too late in -rc cycle, so probably there's not enough time for > > > > writing, test, validate any new API in time for 2.6.33 and write some > > > > compat > > > > layer to emulate those two ioctls with a different implementation. > > > > > > Who says that a new API or an overworked API must be ready for 2.6.33? > > > When do you think the correct starting point must be set? > > > When the merge window for 2.6.34 opens or when? > > > Absurd argument! Not valid at all! > > > > > > > > > > So, removing those two ioctls is not an option anymore. > > > > > > Yes. Conclusion??? None! > > > > > > So if everybody wants to close down this discussion with that output > > > then you must admit (if you want it or not) that you de facto bury > > > teletext usage in the mud for the majority of Gnu/Linux DVB users. > > > > > > So the output is more than badly disappointing. > > > Bye bye Teletext. Nothing for future kernels, huh? > > > > Yes, you say it. It definitely wi
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton: > Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack: > > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: > > > Andreas Oberritter wrote: > > > > Andy Walls wrote: > > > > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by > > > >>> software running on Dream Multimedia set top boxes. > > > >> Right, so reverting the patch is not an option. > > > >> > > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device > > > >> node probably a waste of time at this point. > > > > > > > > I think so, too. But I guess it's always worth discussing alternatives. > > > > > > If this discussion happened before 2.6.32 release, and provided that a > > > different > > > implementation were agreed, things would be easier, as a different > > > solution like > > > your proposal could be decided and used. > > > > > > You cannot expect people reacting immediately if something is wrong. > > There are and do exist enormous delays between publishing a new kernel > > and the decision to use it after appropriate system or distro update. > > So your expectation level is simply wrong. > > > > > > > Now, we have already a regression on a stable kernel, and solving it by > > > creating another regression is not something smart to do. > > > > > > Yes. Trivial! > > > > > > > >From what I understood, the regression appeared on an old, orphan > > > application with a non-official patch applied on it. Other applications > > > with > > > similar features weren't affected. On the other hand, if the patch got > > > reverted, > > > we'll break a maintained application that is used on a great number of > > > devices, > > > and whose features depend on the new ioctls. > > > > > > It's truly amazing how the filter system of your perception works, isn't > > it? :) > > > > It's not just "an old, orphaned application with a non-official patch on > > it." That's nonsense! > > > > a. As I stated already, there do exist several patched versions of > > alevt-dvb. For instance the one that Herman Pitton tested here in public > > causes a closed demux device error on my machine. That means that it > > does not run because xine-ui is already using the demux device. > > And this phenomenon has got nothing to do with the kernel headers! > > I've tried all possibilities (old kernel headers and actual ones) so I > > know better than Hermann Pitton does! > > > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier > > whom I helped with my tip to revert that patch) cause a kernel crash > > with the actual kernel. > > > > b. As I also stated already the other teletext application called mtt > > does officially not exist except for Novell / OpenSuSe distros (at least > > as far as I have seen and found out). And this one > > is, as I also stated, not affected by the kernel patch. It's part of a > > discontinued program suite called xawtv-4.0 pre with a very complex > > infrastructure behind. > > > > Please do not ask me why this one runs without noise - I do not know. > > > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is > > available in almost all Gnu/Linux distros. > > > > "Other applications with similar features weren't affected." > > > > >From where do you know that the features are "similar"? > > > > This is a 100 % phantasy product of your mind that has got nothing to do > > with existing reality, man! > > > > Just one example: alevt-dvb has got an excellent html export filter > > which makes it possible to export teletext pages as graphical html > > files. > > I do not know any other teletext application offering that. > > > > > > > We are too late in -rc cycle, so probably there's not enough time for > > > writing, test, validate any new API in time for 2.6.33 and write some > > > compat > > > layer to emulate those two ioctls with a different implementation. > > > > Who says that a new API or an overworked API must be ready for 2.6.33? > > When do you think the correct starting point must be set? > > When the merge window for 2.6.34 opens or when? > > Absurd argument! Not valid at all! > > > > > > > So, removing those two ioctls is not an option anymore. > > > > Yes. Conclusion??? None! > > > > So if everybody wants to close down this discussion with that output > > then you must admit (if you want it or not) that you de facto bury > > teletext usage in the mud for the majority of Gnu/Linux DVB users. > > > > So the output is more than badly disappointing. > > Bye bye Teletext. Nothing for future kernels, huh? > > Yes, you say it. It definitely will go away and we do have not any > influence on that! Did you not notice the very slow update rate these > days? a. NOTHING "will go away". This is empty rant, nothing else it is! In US teletext is dead, yes. In Europe analogue television is close to dead. Yes. But I have found no information
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack: > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: > > Andreas Oberritter wrote: > > > Andy Walls wrote: > > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by > > >>> software running on Dream Multimedia set top boxes. > > >> Right, so reverting the patch is not an option. > > >> > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device > > >> node probably a waste of time at this point. > > > > > > I think so, too. But I guess it's always worth discussing alternatives. > > > > If this discussion happened before 2.6.32 release, and provided that a > > different > > implementation were agreed, things would be easier, as a different solution > > like > > your proposal could be decided and used. > > > You cannot expect people reacting immediately if something is wrong. > There are and do exist enormous delays between publishing a new kernel > and the decision to use it after appropriate system or distro update. > So your expectation level is simply wrong. > > > > Now, we have already a regression on a stable kernel, and solving it by > > creating another regression is not something smart to do. > > > Yes. Trivial! > > > > >From what I understood, the regression appeared on an old, orphan > > application with a non-official patch applied on it. Other applications with > > similar features weren't affected. On the other hand, if the patch got > > reverted, > > we'll break a maintained application that is used on a great number of > > devices, > > and whose features depend on the new ioctls. > > > It's truly amazing how the filter system of your perception works, isn't > it? :) > > It's not just "an old, orphaned application with a non-official patch on > it." That's nonsense! > > a. As I stated already, there do exist several patched versions of > alevt-dvb. For instance the one that Herman Pitton tested here in public > causes a closed demux device error on my machine. That means that it > does not run because xine-ui is already using the demux device. > And this phenomenon has got nothing to do with the kernel headers! > I've tried all possibilities (old kernel headers and actual ones) so I > know better than Hermann Pitton does! > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier > whom I helped with my tip to revert that patch) cause a kernel crash > with the actual kernel. > > b. As I also stated already the other teletext application called mtt > does officially not exist except for Novell / OpenSuSe distros (at least > as far as I have seen and found out). And this one > is, as I also stated, not affected by the kernel patch. It's part of a > discontinued program suite called xawtv-4.0 pre with a very complex > infrastructure behind. > > Please do not ask me why this one runs without noise - I do not know. > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is > available in almost all Gnu/Linux distros. > > "Other applications with similar features weren't affected." > > >From where do you know that the features are "similar"? > > This is a 100 % phantasy product of your mind that has got nothing to do > with existing reality, man! > > Just one example: alevt-dvb has got an excellent html export filter > which makes it possible to export teletext pages as graphical html > files. > I do not know any other teletext application offering that. > > > > We are too late in -rc cycle, so probably there's not enough time for > > writing, test, validate any new API in time for 2.6.33 and write some compat > > layer to emulate those two ioctls with a different implementation. > > Who says that a new API or an overworked API must be ready for 2.6.33? > When do you think the correct starting point must be set? > When the merge window for 2.6.34 opens or when? > Absurd argument! Not valid at all! > > > > So, removing those two ioctls is not an option anymore. > > Yes. Conclusion??? None! > > So if everybody wants to close down this discussion with that output > then you must admit (if you want it or not) that you de facto bury > teletext usage in the mud for the majority of Gnu/Linux DVB users. > > So the output is more than badly disappointing. > Bye bye Teletext. Nothing for future kernels, huh? Yes, you say it. It definitely will go away and we do have not any influence on that! Did you not notice the very slow update rate these days? > Regards > > CS > > P. S.: If you continue like that you make people run away. > Instead you better should try to win people, shouldn't you? > > Just see how many volunteers are here to help and then reflect > why that manpower is missing, Mauro! > Your gesture being expressed above does a lot, but it is definitely NOT > motivating to change that precarious situation. Then maybe better tell what you tried already, instead leaving others behind doing the same in vain aga
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: > Andreas Oberritter wrote: > > Andy Walls wrote: > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by > >>> software running on Dream Multimedia set top boxes. > >> Right, so reverting the patch is not an option. > >> > >> It also makes implementing multiple dvr0.n nodes for a demux0 device > >> node probably a waste of time at this point. > > > > I think so, too. But I guess it's always worth discussing alternatives. > > If this discussion happened before 2.6.32 release, and provided that a > different > implementation were agreed, things would be easier, as a different solution > like > your proposal could be decided and used. You cannot expect people reacting immediately if something is wrong. There are and do exist enormous delays between publishing a new kernel and the decision to use it after appropriate system or distro update. So your expectation level is simply wrong. > Now, we have already a regression on a stable kernel, and solving it by > creating another regression is not something smart to do. Yes. Trivial! > >From what I understood, the regression appeared on an old, orphan > application with a non-official patch applied on it. Other applications with > similar features weren't affected. On the other hand, if the patch got > reverted, > we'll break a maintained application that is used on a great number of > devices, > and whose features depend on the new ioctls. It's truly amazing how the filter system of your perception works, isn't it? :) It's not just "an old, orphaned application with a non-official patch on it." That's nonsense! a. As I stated already, there do exist several patched versions of alevt-dvb. For instance the one that Herman Pitton tested here in public causes a closed demux device error on my machine. That means that it does not run because xine-ui is already using the demux device. And this phenomenon has got nothing to do with the kernel headers! I've tried all possibilities (old kernel headers and actual ones) so I know better than Hermann Pitton does! And my version (and obviously the ones of Thomas Voegtle and Emil Meier whom I helped with my tip to revert that patch) cause a kernel crash with the actual kernel. b. As I also stated already the other teletext application called mtt does officially not exist except for Novell / OpenSuSe distros (at least as far as I have seen and found out). And this one is, as I also stated, not affected by the kernel patch. It's part of a discontinued program suite called xawtv-4.0 pre with a very complex infrastructure behind. Please do not ask me why this one runs without noise - I do not know. So AFAICS alevt-dvb is the ONLY teletext application for Linux which is available in almost all Gnu/Linux distros. "Other applications with similar features weren't affected." >From where do you know that the features are "similar"? This is a 100 % phantasy product of your mind that has got nothing to do with existing reality, man! Just one example: alevt-dvb has got an excellent html export filter which makes it possible to export teletext pages as graphical html files. I do not know any other teletext application offering that. > We are too late in -rc cycle, so probably there's not enough time for > writing, test, validate any new API in time for 2.6.33 and write some compat > layer to emulate those two ioctls with a different implementation. Who says that a new API or an overworked API must be ready for 2.6.33? When do you think the correct starting point must be set? When the merge window for 2.6.34 opens or when? Absurd argument! Not valid at all! > So, removing those two ioctls is not an option anymore. Yes. Conclusion??? None! So if everybody wants to close down this discussion with that output then you must admit (if you want it or not) that you de facto bury teletext usage in the mud for the majority of Gnu/Linux DVB users. So the output is more than badly disappointing. Bye bye Teletext. Nothing for future kernels, huh? Regards CS P. S.: If you continue like that you make people run away. Instead you better should try to win people, shouldn't you? Just see how many volunteers are here to help and then reflect why that manpower is missing, Mauro! Your gesture being expressed above does a lot, but it is definitely NOT motivating to change that precarious situation. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi, Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: > Andreas Oberritter wrote: > > Andy Walls wrote: > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by > >>> software running on Dream Multimedia set top boxes. > >> Right, so reverting the patch is not an option. > >> > >> It also makes implementing multiple dvr0.n nodes for a demux0 device > >> node probably a waste of time at this point. > > > > I think so, too. But I guess it's always worth discussing alternatives. > > If this discussion happened before 2.6.32 release, and provided that a > different > implementation were agreed, things would be easier, as a different solution > like > your proposal could be decided and used. > > Now, we have already a regression on a stable kernel, and solving it by > creating another regression is not something smart to do. > > >From what I understood, the regression appeared on an old, orphan > application with a non-official patch applied on it. Other applications with > similar features weren't affected. On the other hand, if the patch got > reverted, > we'll break a maintained application that is used on a great number of > devices, > and whose features depend on the new ioctls. > > We are too late in -rc cycle, so probably there's not enough time for > writing, test, validate any new API in time for 2.6.33 and write some compat > layer to emulate those two ioctls with a different implementation. > > So, removing those two ioctls is not an option anymore. > > > Cheers, > Mauro during the still ongoing v4l to v4l2 conversion, all major apps did ship with their own headers. Since we keep backward compat, that previously unknown to me alevt-dvb-t, agreed it is a nice to have, should compile against the older headers instead latest kernel headers, until someone maintains it again and takes advantage of later improvements. Untested, but usually we see just such. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Andreas Oberritter wrote: > Andy Walls wrote: >>> As Honza noted, these ioctls are used by enigma2 and, in general, by >>> software running on Dream Multimedia set top boxes. >> Right, so reverting the patch is not an option. >> >> It also makes implementing multiple dvr0.n nodes for a demux0 device >> node probably a waste of time at this point. > > I think so, too. But I guess it's always worth discussing alternatives. If this discussion happened before 2.6.32 release, and provided that a different implementation were agreed, things would be easier, as a different solution like your proposal could be decided and used. Now, we have already a regression on a stable kernel, and solving it by creating another regression is not something smart to do. >From what I understood, the regression appeared on an old, orphan application with a non-official patch applied on it. Other applications with similar features weren't affected. On the other hand, if the patch got reverted, we'll break a maintained application that is used on a great number of devices, and whose features depend on the new ioctls. We are too late in -rc cycle, so probably there's not enough time for writing, test, validate any new API in time for 2.6.33 and write some compat layer to emulate those two ioctls with a different implementation. So, removing those two ioctls is not an option anymore. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Andy Walls wrote: > Originally the dvr0 device provided a single TS multiplex of PIDs while > the open instances of demux0 each provided a single stream. > > The end objective appears to be able to have multiple different TS > multiplexes from a single hardware (or software) demux. Right. > IMO, the logical answer from a userspace perspective is to have multiple > dvr device nodes (eg dvr0.n) corresponding to a single originating > demux0 device node. With each one of those dvr0.n devices configurable > essentially as before from the demux0 node, but being able to steer the > output of a filter to a dvr node other than dvr0 (e.g. dvr0.2). This sounds like a matter of taste to me. But anyway, your proposal would have one of two possible side effects: You could either choose to allocate those device nodes statically, which would create an artificial limit of filter groups on hardware, where filters are shared between multiple inputs. Or you could create the device nodes dynamically, which would involve waiting for udev to create the new node between setting up the filter(s) and being able to read data. Another reason for the addition of the two new ioctls was, that changing the DMX_SET_PES_FILTER control was not an option, to keep old software running on new kernels and vice versa. > The patches that added DMX_OUT_TSDEMUX_TAP and then > DMX_ADD_PID/DMX_REMOVE_PID, seemed to be avoiding implementing multiple > dvr nodes associated with a single demux node. The end result is that > demux0, essentially a device node intended for control AFAICT, has now > been transformed to be multiple anonymous dvr device nodes. > > In my opinion, that was the wrong end result. I guess that is based on > my notion that the original Nokia/Convergence API separated control from > datastream, and these changes together do just the opposite. That's wrong. The demuxN devices have always been used to control filters and to read section and PES (i.e. TS payload) data streams. The addition of DMX_OUT_TSDEMUX_TAP was just an extension to read a third type of data from it (TS header + payload). >>> I understand the need for sending a single PID TS out to an open demux0 >>> instance as described in this email: >>> >>> http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html >>> >>> even though it seems like a slight abuse of the demux0 device. >> How so? It's all about reading demultiplexed packets, which is exactly >> what a demux is good for. > > My perception was that the demux0 node was for control of the TS output > (and perhaps debug for isolating stream). Being able to read section and PES data is very important for DVB applications. This is definitely not a debugging feature. Processing raw TS streams for other purposes than recording to disk is rarely seen on DVB devices. It's something that mainly comes from the PC world, which is dominated by cheap peripherials which have no or very limited capabilities for filtering and stream processing. > The dvr0 node was for > presenting a TS to userspace. Right. >>> But sending multiple PIDs out in a TS to the open demux0 device instance >>> is just an awkward way to essentially dynamically create a dvrN device >>> associated with filter(s) set on an open demux0 instance. >> Actually it makes dvrN obsolete, but it must of course be kept for >> backwards compatibility. > > Yes it does, except for write() functionality, which is only available > for dvr0 and not demux0. Right. > It also collapses control of one demultiplexer and all the data streams > available from it down to one device node. That has already been the case for sections and PES since the first days of the API. The only recent change is to allow multiple PIDs per file descriptor (which only makes sense for TS, not for sections and PES, where the PID value itself is not carried inside the payload). >> As Honza noted, these ioctls are used by enigma2 and, in general, by >> software running on Dream Multimedia set top boxes. > > Right, so reverting the patch is not an option. > > It also makes implementing multiple dvr0.n nodes for a demux0 device > node probably a waste of time at this point. I think so, too. But I guess it's always worth discussing alternatives. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Andreas, On Fri, 2010-02-05 at 14:19 +0100, Andreas Oberritter wrote: > Hello Andy, > > Andy Walls wrote: > > After investigation, my recommendation for fixing the problem is to > > revert the patch that is causing the problem. > > > > The reason for this is not that fixing the patch is impossible. > > INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in > > conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the > > demux0 device into multiple dynamically created anonymous dvr0 devices, > > and that is the wrong thing to do. > > why exactly do you think this is wrong? Originally the dvr0 device provided a single TS multiplex of PIDs while the open instances of demux0 each provided a single stream. The end objective appears to be able to have multiple different TS multiplexes from a single hardware (or software) demux. IMO, the logical answer from a userspace perspective is to have multiple dvr device nodes (eg dvr0.n) corresponding to a single originating demux0 device node. With each one of those dvr0.n devices configurable essentially as before from the demux0 node, but being able to steer the output of a filter to a dvr node other than dvr0 (e.g. dvr0.2). The patches that added DMX_OUT_TSDEMUX_TAP and then DMX_ADD_PID/DMX_REMOVE_PID, seemed to be avoiding implementing multiple dvr nodes associated with a single demux node. The end result is that demux0, essentially a device node intended for control AFAICT, has now been transformed to be multiple anonymous dvr device nodes. In my opinion, that was the wrong end result. I guess that is based on my notion that the original Nokia/Convergence API separated control from datastream, and these changes together do just the opposite. > > I understand the need for sending a single PID TS out to an open demux0 > > instance as described in this email: > > > > http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html > > > > even though it seems like a slight abuse of the demux0 device. > > How so? It's all about reading demultiplexed packets, which is exactly > what a demux is good for. My perception was that the demux0 node was for control of the TS output (and perhaps debug for isolating stream). The dvr0 node was for presenting a TS to userspace. > There is btw. no other way for multiple > readers to receive TS packets without implementing a second demux > layer in a userspace daemon, which must then be used by all readers. > This would needlessly create quite some overhead on high bandwidth > services. I agree. The DVB subsystem need a way to present multiple TS multiplexs to userspace from a single, orginating demultiplexer. > > But sending multiple PIDs out in a TS to the open demux0 device instance > > is just an awkward way to essentially dynamically create a dvrN device > > associated with filter(s) set on an open demux0 instance. > > Actually it makes dvrN obsolete, but it must of course be kept for > backwards compatibility. Yes it does, except for write() functionality, which is only available for dvr0 and not demux0. It also collapses control of one demultiplexer and all the data streams available from it down to one device node. > > It would be better, in my opinion, to figure out a way to properly > > create and/or associate a dvrN device node with a collection of demuxN > > filters. > > Would this involve running mknod for every recording you start? I would think that dvb_dmxdev_init() would register a number of DVB_DEVICE_DVR device nodes for demux0 named something like dvr0.0 (or dvr0), dvr0.1, dvr0.2, dvr0.3, etc. udev rules would handle device node creation. A module parameter could allow the user to set the number of dvr0.n nodes to a non-default number. Just an idea. > > Maybe just allow creation of a logical demux1 device and dvr1 device and > > the use the DVB API calls as is on the new logical devices. > > A demux device (and dvr respectively) represents a transport stream > input. Hardware with multiple transport stream inputs (read: embedded > set top boxes) already has multiple demux and dvr devices. Yes, that was a bad idea. I agree with you: one demux device node per input TS and demultiplexer device. One could still have multiple dvr0.m nodes representing different filter configurations from a demux0 node. > > I'm not a DVB apps programmer, so I don't know all the userspace needs > > nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > > ioctl()s. > > The need for such an interface was already pointed out and discussed > back in 2006: > http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html > > As Honza noted, these ioctls are used by enigma2 and, in general, by > software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. Thanks for the comments. Regards, Andy >
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
On Fri, 2010-02-05 at 13:19 +0100, HoP wrote: > Hi Chicken > > > > > Furthermore: If it is technically possible to send and receive, demux > > and multiplex, play and record complete contents of a transponder (i. e. > > multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line > > parameter), then I myself do not see the necessity to extend the > > capabilities of one physical device dvr0 or demux0 into a multiplicity > > of devices dvr0 or demux0. > > The what and especially the why will remain Andreas Oberritters' secret. > > I can only say my 2 words regarding Andreas' patch: > > At least one big DVB application is using it - enigma (originally > inside tuxbox project, later enhanced by Dream Multimedia > for theirs well-known linux based set-top-boxes Dreambox). > Those boxes are selling worlwide, so userbase is wide enough > (note: I'm not in any way connected with Dream Multimedia, > so it is only my personal feeling and/or investigation). > > Of course using full TS and remuxing only in user land > is not possible way for embedded application. And if you count > that there can be more then one TS input, things are getting even worst. Well then, it appears reverting the patch is not an option. Time to slog through the code and fix it, I guess. > And as Andy wrote: > >> But sending multiple PIDs out in a TS to the open demux0 device instance > >> is just an awkward way to essentially dynamically create a dvrN device > >> associated with filter(s) set on an open demux0 instance. > >> > >> It would be better, in my opinion, to figure out a way to properly > >> create and/or associate a dvrN device node with a collection of demuxN > >> filters. > >> > >> Maybe just allow creation of a logical demux1 device and dvr1 device and > >> the use the DVB API calls as is on the new logical devices. > >> > >> I'm not a DVB apps programmer, so I don't know all the userspace needs > >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > >> ioctl()s. > >> > >> > > Well, it is also possible way. But it expands > dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so. > > We definitelly need such feature. I thought about this more and was thinking the device nodes presented to userspace might look something like this: /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/dvr0.0 (symlink to dvr0 or the other way around) /dev/dvb/adapter0/dvr0.1 /dev/dvb/adapter0/dvr0.2 ... /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/net0 So that dvr0.n was still associated with the demux0 filter settings, but that the demux filter outputs could be steered to one of a number of different dvr0.n devices. That keeps dvr0.n devices as providing a TS multiplex of exactly the PIDs one wants, allows multiple TS multiplexes to be recorded from the originating demux0, and also allows the dvr0.n outputs to be controlled by the originating demux0. It would require the current DMX_SET_PES_FILTER_PARAMS ioctl()'s to be modified, so that the output setting could include a "subaddress" (the n in dvr0.n), but with a default of 0 for backward compatability. > I, personally, like DMX_OUT_TSDEMUX_TAP approach. >From what I gather, originally: a. the demux0 device would provide a single PID stream (not a TS but a "section"?) with DMX_OUT_TAP b. the dvr0 device would provide a full TS multiplex of all the PIDs specified with DMX_OUT_TS_TAP c. a dvr node always delivered a TS and an open demux instance always delivered a non-TS stream So the problems were, I think: a. No way to capture more than one TS from an originating demux. So userspace could not re-multiplex PIDs together easily(?). b. No way to capture more than one TS multiplex from an originating demux. No way for userspace to easily capture separate TV programs from a single multiplex, into separate TS multiplexes each containing only the related PID for each spearate TV program (i.e. audio and video PIDs) Problem a. was solved by the DMX_OUT_TSDEMUX_TAP change. That was a very simple patch and appear fairly straight forward. It changes the type of output one can get from an open demux0 instance from just "section" to also include a single PID TS. IMO, that change looks like a conveient shortcut to avoid dealing with how to implement multiple dvr nodes per originating demux. But that's OK, if your userspace app just needs one PID per TS: mplayer playing audio and video from one TV program (?) Problem b. was solved by the DMX_ADD_PID, DMX_REMOVE_PID patch. This allows an open demux instance to now not only send a TS, but also send multiple PIDs in that TS, essentially creating an output of the kind one would see at a dvr0 node. So my thinking at this point is why dance around the issue? The requirement appears to be to set up multiple dvr type feeds for userspace from a single originating demux. I would want to take the time to audit the code and fix the problems with the DMX_ADD_PID, DMX_REMOVE_PID patc
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 11:28 -0200 schrieb Mauro Carvalho Chehab: > Andreas Oberritter wrote: > > Hello Andy, > > > > Andy Walls wrote: > >> After investigation, my recommendation for fixing the problem is to > >> revert the patch that is causing the problem. > > Well, the patch were already added on an upstream kernel, so just reverting it > will cause regressions. > > If it is just aletv-dvb that broke, it seems better to fix it than to cause > even more troubles by reverting two new ioctls. > > >> The reason for this is not that fixing the patch is impossible. > > Why? Where exactly the breakage happened? Mauro, I think the dissassembler extracts done by Andy do answer this question already. Just go back to the first messages of that thread and you will know where the breakage begins. For an experienced programmer / coder it should not be too different to draw the adequate conclusions what needs to be done. While everybody is behaving rather passive defending the kernel status quo, stressing the fact that this discussion is nearly one week old now: The core questions are: 1. What is the minimum adequate requirement for alevt-dvb to conform to the latest DVB demux design and do its work again without noise and causing kernel oopses? 2. What is the minimum adequate requirement for alevt-dvb to stop causing hanging processes when the transponder is changed? In its current state the application does not seem to understand the effects of a PMT change (->program management table). 3. Who can write / offer patches for alevt's DVB design? Still hoping for qualified help CS > >> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in > >> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the > >> demux0 device into multiple dynamically created anonymous dvr0 devices, > >> and that is the wrong thing to do. > > > > why exactly do you think this is wrong? > > > >> I understand the need for sending a single PID TS out to an open demux0 > >> instance as described in this email: > >> > >> http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html > >> > >> even though it seems like a slight abuse of the demux0 device. > > > > How so? It's all about reading demultiplexed packets, which is exactly > > what a demux is good for. There is btw. no other way for multiple > > readers to receive TS packets without implementing a second demux > > layer in a userspace daemon, which must then be used by all readers. > > This would needlessly create quite some overhead on high bandwidth > > services. > >> But sending multiple PIDs out in a TS to the open demux0 device instance > >> is just an awkward way to essentially dynamically create a dvrN device > >> associated with filter(s) set on an open demux0 instance. > > > > Actually it makes dvrN obsolete, but it must of course be kept for > > backwards compatibility. > > > >> It would be better, in my opinion, to figure out a way to properly > >> create and/or associate a dvrN device node with a collection of demuxN > >> filters. > > > > Would this involve running mknod for every recording you start? > > > >> Maybe just allow creation of a logical demux1 device and dvr1 device and > >> the use the DVB API calls as is on the new logical devices. > > > > A demux device (and dvr respectively) represents a transport stream > > input. Hardware with multiple transport stream inputs (read: embedded > > set top boxes) already has multiple demux and dvr devices. > > > Andreas arguments makes sense to me. > > > >> I'm not a DVB apps programmer, so I don't know all the userspace needs > >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > >> ioctl()s. > > > > The need for such an interface was already pointed out and discussed > > back in 2006: > > http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html > > > > As Honza noted, these ioctls are used by enigma2 and, in general, by > > software running on Dream Multimedia set top boxes. I'm sure, other > > projects are going to adopt this interface sooner or later. It is > > still quite new after all. > > > It seems too late for me to revert it. So, we need to figure out a way > to workaround it or to fix the applications that got broken by this change. > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 11:28 -0200 schrieb Mauro Carvalho Chehab: > Andreas Oberritter wrote: > > Hello Andy, > > > > Andy Walls wrote: > >> After investigation, my recommendation for fixing the problem is to > >> revert the patch that is causing the problem. > > Well, the patch were already added on an upstream kernel, so just reverting it > will cause regressions. > > If it is just aletv-dvb that broke, it seems better to fix it than to cause > even more troubles by reverting two new ioctls. > > >> The reason for this is not that fixing the patch is impossible. > > Why? Where exactly the breakage happened? Mauro, alevt-dvb is the only application that is broken by that kernel patch in question. mtt works, but it is part of a suite of programs, it's not teletext only. So the architexture behind is much more complicated than alevt-dvb itself ever was. Conclusion: fix the application alevt-dvb is the shortest way to solve the problem. CS > >> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in > >> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the > >> demux0 device into multiple dynamically created anonymous dvr0 devices, > >> and that is the wrong thing to do. > > > > why exactly do you think this is wrong? > > > >> I understand the need for sending a single PID TS out to an open demux0 > >> instance as described in this email: > >> > >> http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html > >> > >> even though it seems like a slight abuse of the demux0 device. > > > > How so? It's all about reading demultiplexed packets, which is exactly > > what a demux is good for. There is btw. no other way for multiple > > readers to receive TS packets without implementing a second demux > > layer in a userspace daemon, which must then be used by all readers. > > This would needlessly create quite some overhead on high bandwidth > > services. > >> But sending multiple PIDs out in a TS to the open demux0 device instance > >> is just an awkward way to essentially dynamically create a dvrN device > >> associated with filter(s) set on an open demux0 instance. > > > > Actually it makes dvrN obsolete, but it must of course be kept for > > backwards compatibility. > > > >> It would be better, in my opinion, to figure out a way to properly > >> create and/or associate a dvrN device node with a collection of demuxN > >> filters. > > > > Would this involve running mknod for every recording you start? > > > >> Maybe just allow creation of a logical demux1 device and dvr1 device and > >> the use the DVB API calls as is on the new logical devices. > > > > A demux device (and dvr respectively) represents a transport stream > > input. Hardware with multiple transport stream inputs (read: embedded > > set top boxes) already has multiple demux and dvr devices. > > > Andreas arguments makes sense to me. > > > >> I'm not a DVB apps programmer, so I don't know all the userspace needs > >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > >> ioctl()s. > > > > The need for such an interface was already pointed out and discussed > > back in 2006: > > http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html > > > > As Honza noted, these ioctls are used by enigma2 and, in general, by > > software running on Dream Multimedia set top boxes. I'm sure, other > > projects are going to adopt this interface sooner or later. It is > > still quite new after all. > > > It seems too late for me to revert it. So, we need to figure out a way > to workaround it or to fix the applications that got broken by this change. > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hello Andy, Andy Walls wrote: > After investigation, my recommendation for fixing the problem is to > revert the patch that is causing the problem. > > The reason for this is not that fixing the patch is impossible. > INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in > conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the > demux0 device into multiple dynamically created anonymous dvr0 devices, > and that is the wrong thing to do. why exactly do you think this is wrong? > I understand the need for sending a single PID TS out to an open demux0 > instance as described in this email: > > http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html > > even though it seems like a slight abuse of the demux0 device. How so? It's all about reading demultiplexed packets, which is exactly what a demux is good for. There is btw. no other way for multiple readers to receive TS packets without implementing a second demux layer in a userspace daemon, which must then be used by all readers. This would needlessly create quite some overhead on high bandwidth services. > But sending multiple PIDs out in a TS to the open demux0 device instance > is just an awkward way to essentially dynamically create a dvrN device > associated with filter(s) set on an open demux0 instance. Actually it makes dvrN obsolete, but it must of course be kept for backwards compatibility. > It would be better, in my opinion, to figure out a way to properly > create and/or associate a dvrN device node with a collection of demuxN > filters. Would this involve running mknod for every recording you start? > Maybe just allow creation of a logical demux1 device and dvr1 device and > the use the DVB API calls as is on the new logical devices. A demux device (and dvr respectively) represents a transport stream input. Hardware with multiple transport stream inputs (read: embedded set top boxes) already has multiple demux and dvr devices. > I'm not a DVB apps programmer, so I don't know all the userspace needs > nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > ioctl()s. The need for such an interface was already pointed out and discussed back in 2006: http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. I'm sure, other projects are going to adopt this interface sooner or later. It is still quite new after all. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Andreas Oberritter wrote: > Hello Andy, > > Andy Walls wrote: >> After investigation, my recommendation for fixing the problem is to >> revert the patch that is causing the problem. Well, the patch were already added on an upstream kernel, so just reverting it will cause regressions. If it is just aletv-dvb that broke, it seems better to fix it than to cause even more troubles by reverting two new ioctls. >> The reason for this is not that fixing the patch is impossible. Why? Where exactly the breakage happened? >> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in >> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the >> demux0 device into multiple dynamically created anonymous dvr0 devices, >> and that is the wrong thing to do. > > why exactly do you think this is wrong? > >> I understand the need for sending a single PID TS out to an open demux0 >> instance as described in this email: >> >> http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html >> >> even though it seems like a slight abuse of the demux0 device. > > How so? It's all about reading demultiplexed packets, which is exactly > what a demux is good for. There is btw. no other way for multiple > readers to receive TS packets without implementing a second demux > layer in a userspace daemon, which must then be used by all readers. > This would needlessly create quite some overhead on high bandwidth > services. >> But sending multiple PIDs out in a TS to the open demux0 device instance >> is just an awkward way to essentially dynamically create a dvrN device >> associated with filter(s) set on an open demux0 instance. > > Actually it makes dvrN obsolete, but it must of course be kept for > backwards compatibility. > >> It would be better, in my opinion, to figure out a way to properly >> create and/or associate a dvrN device node with a collection of demuxN >> filters. > > Would this involve running mknod for every recording you start? > >> Maybe just allow creation of a logical demux1 device and dvr1 device and >> the use the DVB API calls as is on the new logical devices. > > A demux device (and dvr respectively) represents a transport stream > input. Hardware with multiple transport stream inputs (read: embedded > set top boxes) already has multiple demux and dvr devices. Andreas arguments makes sense to me. >> I'm not a DVB apps programmer, so I don't know all the userspace needs >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID >> ioctl()s. > > The need for such an interface was already pointed out and discussed > back in 2006: > http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html > > As Honza noted, these ioctls are used by enigma2 and, in general, by > software running on Dream Multimedia set top boxes. I'm sure, other > projects are going to adopt this interface sooner or later. It is > still quite new after all. It seems too late for me to revert it. So, we need to figure out a way to workaround it or to fix the applications that got broken by this change. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Chicken > > Furthermore: If it is technically possible to send and receive, demux > and multiplex, play and record complete contents of a transponder (i. e. > multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line > parameter), then I myself do not see the necessity to extend the > capabilities of one physical device dvr0 or demux0 into a multiplicity > of devices dvr0 or demux0. > The what and especially the why will remain Andreas Oberritters' secret. I can only say my 2 words regarding Andreas' patch: At least one big DVB application is using it - enigma (originally inside tuxbox project, later enhanced by Dream Multimedia for theirs well-known linux based set-top-boxes Dreambox). Those boxes are selling worlwide, so userbase is wide enough (note: I'm not in any way connected with Dream Multimedia, so it is only my personal feeling and/or investigation). Of course using full TS and remuxing only in user land is not possible way for embedded application. And if you count that there can be more then one TS input, things are getting even worst. And as Andy wrote: >> But sending multiple PIDs out in a TS to the open demux0 device instance >> is just an awkward way to essentially dynamically create a dvrN device >> associated with filter(s) set on an open demux0 instance. >> >> It would be better, in my opinion, to figure out a way to properly >> create and/or associate a dvrN device node with a collection of demuxN >> filters. >> >> Maybe just allow creation of a logical demux1 device and dvr1 device and >> the use the DVB API calls as is on the new logical devices. >> >> I'm not a DVB apps programmer, so I don't know all the userspace needs >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID >> ioctl()s. >> >> Well, it is also possible way. But it expands dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so. We definitelly need such feature. I, personally, like DMX_OUT_TSDEMUX_TAP approach. Rgds /Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Donnerstag, den 04.02.2010, 21:21 -0500 schrieb Andy Walls: > On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote: > > Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls: > > > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: > > > > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: > > > > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: > > > > > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: > > > > > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: > > > > > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > here is a link to a patch which breaks backwards > > > > > > > > > compatibility for a > > > > > > > > > teletext software called alevt-dvb. > > > > > > > > > > > > > > > > > > http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html > > > > > > > > > > > > > > > > > > The kernel patch was introduced with kernel 2.6.32-rc1. > > > > > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab > > > > > > > > > and its > > > > > > > > > author, Andreas Oberritter. > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > CS > > > > > > > > > > > > > > > > > > P. S.: This is how the kernel crash looks like: > > > > > > > > > > > > > > > > The information below can get me started. Could you please > > > > > > > > provide > > > > > > > > whole Ooops from the output dmesg or from your > > > > > > > > /var/log/messages file? > > > > > > > > > > > > > > > > I'll try to look at this tonight. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Andy > > > > > > > > > > > > > > > > > brian:~# alevt > > > > > > > > > alevt: SDT: service_id 0xcf24 not in PAT > > > > > > > > > > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) > > > > > > > > > Getötet > > > > > > > > > brian:~# > > > > > > > > > Message from sysl...@brian at Jan 31 19:52:33 ... > > > > > > > > > kernel:[ 116.563487] Oops: [#1] PREEMPT SMP > > > > > > > > So there is something wrong with the list manipulations or, if > > > > > > > needed, > > > > > > > locking around the the list manipulations of the list that was > > > > > > > introduced in the patch you identified as the problem. That is > > > > > > > what is > > > > > > > causing the Ooops on close(). It will take a some more scrutiny > > > > > > > to see > > > > > > > what exactly is wrong. > > > > Schedule update: I'll be looking at this tonight (Thursday evening). > > After investigation, my recommendation for fixing the problem is to > revert the patch that is causing the problem. > > The reason for this is not that fixing the patch is impossible. > INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in > conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the > demux0 device into multiple dynamically created anonymous dvr0 devices, > and that is the wrong thing to do. > > I understand the need for sending a single PID TS out to an open demux0 > instance as described in this email: > > http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html > > even though it seems like a slight abuse of the demux0 device. > > > But sending multiple PIDs out in a TS to the open demux0 device instance > is just an awkward way to essentially dynamically create a dvrN device > associated with filter(s) set on an open demux0 instance. > > It would be better, in my opinion, to figure out a way to properly > create and/or associate a dvrN device node with a collection of demuxN > filters. > > Maybe just allow creation of a logical demux1 device and dvr1 device and > the use the DVB API calls as is on the new logical devices. > > I'm not a DVB apps programmer, so I don't know all the userspace needs > nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > ioctl()s. > > > Comments? > > Regards, > Andy Hi Andy, thanks for this excellent analysis :) kaffeine-1.0pre3, xawtv-4.0pre (->discontinued), vdr-1.6.0, mythtv-0.22: None of them uses neither DMX_ADD_PID nor DMX_REMOVE_PID in conjunction with DMX_OUT_TSDEMUX_TAP. So reverting the kernel patch does not do harm to anybody. Furthermore: If it is technically possible to send and receive, demux and multiplex, play and record complete contents of a transponder (i. e. multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line parameter), then I myself do not see the necessity to extend the capabilities of one physical device dvr0 or demux0 into a multiplicity of devices dvr0 or demux0. The what and especially the why will remain Andreas Oberritters' secret. However: The hanging process that alevt-dvb produces if an external application switches to a channel belonging to a different DVB-S transponder still remains the second problem which is not touched by this discussion - just as a reminder for everybody! The one who wants to use teletext un
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Andy, Am Donnerstag, den 04.02.2010, 21:21 -0500 schrieb Andy Walls: > On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote: > > Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls: > > > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: > > > > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: > > > > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: > > > > > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: > > > > > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: > > > > > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > here is a link to a patch which breaks backwards > > > > > > > > > compatibility for a > > > > > > > > > teletext software called alevt-dvb. > > > > > > > > > > > > > > > > > > http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html > > > > > > > > > > > > > > > > > > The kernel patch was introduced with kernel 2.6.32-rc1. > > > > > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab > > > > > > > > > and its > > > > > > > > > author, Andreas Oberritter. > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > CS > > > > > > > > > > > > > > > > > > P. S.: This is how the kernel crash looks like: > > > > > > > > > > > > > > > > The information below can get me started. Could you please > > > > > > > > provide > > > > > > > > whole Ooops from the output dmesg or from your > > > > > > > > /var/log/messages file? > > > > > > > > > > > > > > > > I'll try to look at this tonight. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Andy > > > > > > > > > > > > > > > > > brian:~# alevt > > > > > > > > > alevt: SDT: service_id 0xcf24 not in PAT > > > > > > > > > > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) > > > > > > > > > Getötet > > > > > > > > > brian:~# > > > > > > > > > Message from sysl...@brian at Jan 31 19:52:33 ... > > > > > > > > > kernel:[ 116.563487] Oops: [#1] PREEMPT SMP > > > > > > > > So there is something wrong with the list manipulations or, if > > > > > > > needed, > > > > > > > locking around the the list manipulations of the list that was > > > > > > > introduced in the patch you identified as the problem. That is > > > > > > > what is > > > > > > > causing the Ooops on close(). It will take a some more scrutiny > > > > > > > to see > > > > > > > what exactly is wrong. > > > > Schedule update: I'll be looking at this tonight (Thursday evening). > > After investigation, my recommendation for fixing the problem is to > revert the patch that is causing the problem. > > The reason for this is not that fixing the patch is impossible. > INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in > conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the > demux0 device into multiple dynamically created anonymous dvr0 devices, > and that is the wrong thing to do. > > I understand the need for sending a single PID TS out to an open demux0 > instance as described in this email: > > http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html > > even though it seems like a slight abuse of the demux0 device. > > > But sending multiple PIDs out in a TS to the open demux0 device instance > is just an awkward way to essentially dynamically create a dvrN device > associated with filter(s) set on an open demux0 instance. > > It would be better, in my opinion, to figure out a way to properly > create and/or associate a dvrN device node with a collection of demuxN > filters. > > Maybe just allow creation of a logical demux1 device and dvr1 device and > the use the DVB API calls as is on the new logical devices. > > I'm not a DVB apps programmer, so I don't know all the userspace needs > nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > ioctl()s. > > > Comments? > > Regards, > Andy without looking any much closer, just at some headers that might be out of sync, taking the DVB patched version from here http://pluto.blackbone-ev.de/v1/AleVT%20mit%20DVB-T.html make cc -O2 -s -w main.o ui.o xio.o fdset.o vbi.o cache.o help.o edline.o search.o edit.o misc.o hamm.o lang.o export.o exp-txt.o exp-html.o exp-gfx.o font.o -o alevt -L/usr/X11R6/lib -L/usr/X11R6/lib64 -lX11 -lpng -lz -lm /usr/bin/ld: i386 architecture of input file `main.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `ui.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `xio.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `fdset.o' is incompatible with i386:x86-64 output collect2: ld gab 1 als Ende-Status zurück make: *** [alevt] Fehler 1 make clean rm -f *.o page*.txt a.out core bdf2xbm font?.xbm fontsize.h Makefile.bak rm -f alevt alevt-date alevt-cap rm -f alevt.1x alevt-date.1 alevt-cap.1 rm
Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote: > Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls: > > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: > > > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: > > > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: > > > > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: > > > > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: > > > > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > here is a link to a patch which breaks backwards compatibility > > > > > > > > for a > > > > > > > > teletext software called alevt-dvb. > > > > > > > > > > > > > > > > http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html > > > > > > > > > > > > > > > > The kernel patch was introduced with kernel 2.6.32-rc1. > > > > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and > > > > > > > > its > > > > > > > > author, Andreas Oberritter. > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > CS > > > > > > > > > > > > > > > > P. S.: This is how the kernel crash looks like: > > > > > > > > > > > > > > The information below can get me started. Could you please > > > > > > > provide > > > > > > > whole Ooops from the output dmesg or from your /var/log/messages > > > > > > > file? > > > > > > > > > > > > > > I'll try to look at this tonight. > > > > > > > > > > > > > > Regards, > > > > > > > Andy > > > > > > > > > > > > > > > brian:~# alevt > > > > > > > > alevt: SDT: service_id 0xcf24 not in PAT > > > > > > > > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) > > > > > > > > Getötet > > > > > > > > brian:~# > > > > > > > > Message from sysl...@brian at Jan 31 19:52:33 ... > > > > > > > > kernel:[ 116.563487] Oops: [#1] PREEMPT SMP > > > > > > So there is something wrong with the list manipulations or, if > > > > > > needed, > > > > > > locking around the the list manipulations of the list that was > > > > > > introduced in the patch you identified as the problem. That is > > > > > > what is > > > > > > causing the Ooops on close(). It will take a some more scrutiny to > > > > > > see > > > > > > what exactly is wrong. > > Schedule update: I'll be looking at this tonight (Thursday evening). After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. The reason for this is not that fixing the patch is impossible. INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. Comments? Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
