From: <xi...@za...> - 2007-05-01 00:46:44
|
> >> When a channel change happens (in a file or broadcast) the recorder >> simply changes the reconstructed PAT and thereby can effectively communicate >> to a program like xine what the current program number (sid) is. >That sounds good and simple at first, but I fear that it won't work >completely. What if you do a channel switch to another transport stream >(on the source side) which happen to have the same service id? (after >all, a service id alone is not unique). Programs then won't notice a >discontinuity, buffers won't be flushed and picture will become jerky. >The PAT doesn't give you the ONID (and even ONID+SID isn't enough, even >if it should). > It does work. I have been using it for several months now. But perhaps you didn't think about what I said carefully enough. Each PAT has a unique Transport Stream Id. So it doesn't matter if the same service id occurs. Because any application, like xine, can detect a different PAT from the TSID. > >> Unbelievably simple technique, so I don't know why every dvb application >> doesn't do it. >It's a hack. It's a good hack, but it's still a hack. It is no more a hack than the "hack" which a broadcaster uses to create a PAT in the first place. > >Of course, if enough people ACK this behaviour, it could become a >"standard" (at least for xine). But we should think about the >implications. I'd still prefer an side channel to tell the decoder about >the sid and discontinuations. > >>> But if you're live, you have all that information (essentially the >>> service-id). You can also assume that the the PID distribution is >>> "almost" the same as last time you visited this multiplex, thus caching >>> makes sense. >> That is only true if xine is the program controlling the tuning. >Sure. Wasn't that what the original idea was intended for? > So breaking other uses of xine is ok? >b.) Even an immediate blackscreen is better than the old channel. >Otherwise the application feels laggy, because you pressed a button and >"nothing happens" (we made such experiments - mainly because of buggy >drivers, though.). > Xine can show some osd while waiting for new PAT/PMT. This is exactly what it does with RTP. It will show old program for a second or so, but it also shows an osd "Buffering ...". Of course with RTP there is also some latency because of kernel buffering of RTP packets. But with RTP there is not even a discontinutity. There is hardly even a frozen frame because the rebuffering is quite fast. The osd gives adequate feedback that a change is happening. And this is even via the chain of lirc -> cmd -> DVBserver -> RTP -> xine. >>> And to be honest, I don't know if RTP fits more into the "playing back a >>> file" or "showing live DVB content" situation. I've never worked with it. >> Maybe you should. Because the best way to be using dvb is to be >> running a server application (like mine!) which makes the channels >> available at any location over a lan. RTP Multicast is the way to go. >No, because I work for a company selling DVB receivers ;) So the best >way is obviously to have one receiver for every TV-set, selling as much >hardware as possible, making my company rich. > >Joke aside, we were considering RTP transports inside homes for some >time. The critical problem for selling this is that if you're at that >point, you want to switch to wireless. And WLAN, for example, does not >yet have the capacity for that. Yes it does. > >Distributing TV over DVB-T for example makes much more sense than >distributing over WLAN. First, it *is* already distributed, no need for >expensive TX side equipment. Then you have way more bandwidth than what >WLAN will ever give you. And then you have better suited error >correction. Thus in the DVB-T situation, it makes absolutely no sense to >replace something by IP-based networks. Not in the case of subscription services where it costs $$$ per subscriber card, and where it also costs $$$ per decoder. It makes absolutely perfect sense to distribute pay-tv throughout one's household. Why are you only considering DVB-T? What about DVB-S? > >> Also live pause is so easy to implement with RTP (the server just >> broadcasts null TS packets in place of incoming packets which is >> spools, and xine happily freezes the current frame >> without any problem). No need for any rate computations, very simple. >Wasting bandwidth because there is no proper protocol? :) > >Anyway - It seems that your use-case is clearly different from what >Simon had in mind (at least i believe so). In your case, you can sent >PSI whenever you want, but in a (real) DVB setup, with a local frontend, >this is not possible. > Let's hope that whatever happens it doesn't recklessly break some parts of xine that are currently working (more-or-less). Again I don't think channel changing should be a function of xine. -JW |