[FFmpeg-devel] MPEG-TS over UDP broken by r15739
Mon Nov 10 11:52:57 CET 2008
On Mon, Nov 10, 2008 at 10:08:38AM +0100, Jindrich Makovicka wrote:
> 2008/11/7 Michael Niedermayer <michaelni at gmx.at>:
> > On Thu, Nov 06, 2008 at 10:17:21PM +0100, Jindrich Makovicka wrote:
> >> On Thu, Nov 6, 2008 at 18:28, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Fri, Oct 31, 2008 at 04:31:01PM +0100, Jindrich Makovicka wrote:
> >> >> Hi,
> >> >>
> >> >> revision 15739 broke receiving datagram based inputs like UDP - aviobuf
> >> >> now discards parts of the packets. Maybe it could be fixed by the
> >> >> attached patch that reverts to the old behavior if max_packet_size is
> >> >> specified.
> >> >
> >> > Well, the bug has to be analyzed first.
> >> > Just "reverting to the old behavior if ..." is really not how we should
> >> > fix and justify fixes.
> >> Now, the code is clearly broken wrt/ datagram inputs because with a
> >> partially filled buffer, recv() can (and will) truncate the received
> >> UDP packets, and the TS demuxer will get garbage on its input. By
> >> reverting to the old behavior, we ensure that the received packet will
> >> fit into the buffer, which is exactly max_packet_size long. As long as
> >> we assume that having one packet in the buffer is enough for format
> >> autodetection, the fix is ok.
> > understood, thanks for explaining.
> > i agree with the idea of your solution but its mildly buggy, probably doing
> > something random with checksuming also its more complex than needed
> > i think
> > simply changing dst at its initialization should be all that is needed for
> > no max_packet_size case.
> Right, this is a lot simpler and works as well.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel