On 12/07/2011 08:01 AM, Andreas Oberritter wrote: > On 07.12.2011 14:49, Mark Brown wrote: >> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: >>> On 06.12.2011 15:19, Mark Brown wrote: >> >>>> Your assertatation that applications should ignore the underlying >>>> transport (which seems to be a big part of what you're saying) isn't >>>> entirely in line with reality. >> >>> Did you notice that we're talking about a very particular application? >> >> *sigh* >> >>> VoIP really is totally off-topic. The B in DVB stands for broadcast. >>> There's only one direction in which MPEG payload is to be sent (using >>> RTP for example). You can't just re-encode the data on the fly without >>> loss of information. >> >> This is pretty much exactly the case for VoIP some of the time (though >> obviously bidirectional use cases are rather common there's things like >> conferencing). I would really expect similar considerations to apply >> for video content as they certainly do in videoconferencing VoIP >> applications - if the application knows about the network it can tailor >> what it's doing to that network. >> >> For example, if it is using a network with a guaranteed bandwidth it can >> assume that bandwidth. If it knows something about the structure of the >> network it may be able to arrange to work around choke points. >> Depending on the situation even something lossy may be the answer - if >> it's the difference between working at all and not working then the cost >> may be worth it. > > Once and for all: We have *not* discussed a generic video streaming > application. It's only, I repeat, only about accessing a remote DVB API > tuner *as if it was local*. No data received from a satellite, cable or > terrestrial DVB network shall be modified by this application! > > Virtually *every* user of it will use it in a LAN. > > It can't be so hard to understand. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html I tend to stay out of these discussions, since like a couple of others, I'm not a kernel developer (or hacker). However, I wanted to chime in with my two cents here. 1. I agree that it's not acceptable to "NACK" purely for philosophical reasons (except when it's a clear violation of a license--be that open source or closed source (since we don't want to open ourselves up to lawsuits). 2. In this case, there have been technical reasons provided. Granted the developers (and people who are pro-inclusion) don't feel those are justified, but they have been cited. 3. You'll catch more flies with honey than vinegar (in other words, fighting with the person(s) who maintain the project will most definitely *not* get your code included). 4 (and the reason I decided to chime in here). This email sums everything up. Mark is pointing out that someone may want to use this in a non LAN setting, and they may/will have problems due to the Internet (and their specific way of accessing it). Andreas is arguing that it's not the case. I have to side with Mark on this one, solely because if I knew that it would work, I'd use it to watch television when I'm traveling (as some places don't carry the same channels that I have at home). So, I would prove Mark's point. Andreas, you said that "virtually EVERY (emphasis mine) user of it will use it on a LAN". "Virtually" implies almost all-- NOT ALL. So, unless there's some restriction in the application, which prevents it from being used over the Internet, you can't guarantee that Mark's issues aren't valid. If as HoP pointed out in another reply on this thread, there's no kernel patching required, then I suggest that you keep on developing it as a userspace application. There's no law/rule/anything that says you can't install your own driver in the kernel. It just won't be supported upstream. That just means more work for you, if you want the application to continue working in the future. Truthfully, that has it's upsides also. If you find out about a way to improve the transmission, you don't have to wait (and hope) that it gets included in the kernel. You can include it in your driver. Sorry for butting into this. You're free to flame or ignore me, as you choose. Have a great day:) Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
