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-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
