[mythtv] 0.21 and ffmpeg handling of corrupt ac3
Scott D. Davilla
davilla at 4pi.com
Fri Apr 18 20:46:06 UTC 2008
>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
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.
More information about the mythtv-dev