[mythtv] 0.21 and ffmpeg handling of corrupt ac3

[Scott D. Davilla]

>On Fri, Apr 18, 2008 at 2:12 PM, Scott D. Davilla <davilla at 4pi.com> wrote:
>>  >Certainly nothing wrong with doing that, but doing a check at the
>>   >decoder makes sense as well, at least to me.  Corrupted data could
>>   >come from other sources (the first one that jumps to mind is a
>>   >front-end connected via a wireless network), could it not?
>>   >
>>
>>   Possible but not likely over wireless unless one is using a UDP
>>   socket and not checking and retransmitting dropped packets. A TCP
>>   socket is guaranteed, you get the data or it stalls and you lose the
>>   socket connection.
>[...]
>>   You never have to check packets of data sent using TCP sockets. TCP
>>   does the checking for you and that's why it's "slower" than UDP.
>
>But isn't most streaming done via UDP?
>In my experience you don't typically buffer streams enough to make use
>of retransmission.
>

It depends on the Apps and device and the amount of fault tolerance designed.

For example, the HDHomeRun uses UDP and sends several ts packets 
(seven, I think) in one UDP packet. If a UDP packet is "lost", the 
next chunk of ts packets are still quantized.

The HDHomeRun is intended for a local IP device to device transfer 
and cannot not cross subnets (one of the complaints). Once you start 
crossing subnets with routers and routing then another characteristic 
of UDP comes into play and that is UPD does not guarantee the correct 
order of UDP packets. That's the responsibility of the sending and 
receiving devices. A router is free to buffer and pass UDP packets in 
any order it pleases.

TCP actually uses UDP at the low level but its internal design does 
the checking/retransmission and order sorting.

And this is starting to get off topic and should be moved to the user list.