Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driverbecause of worrying about possible misusage?

[Mark Brown]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/