[FFmpeg-devel] [PATCH] asfdemux: wrong padding

[Ronald S. Bultje]

Hi,

There's this code in asf.c, line 626:
    if (packet_length < asf->hdr.min_pktsize)
        padsize += asf->hdr.min_pktsize - packet_length;

What it does is to make sure that if the packet_length field is not
within the range of the min/max_pktsize specified in the ASF header,
we skip the rest as if it were padding. I suppose this fixes playback
of some files but I'm not completely sure.

Here's a quote from the specifications [1]:

"Minimum Data Packet Size
Specifies the minimum Data Packet size in bytes. In general, the value
of this field is invalid if the Broadcast Flag bit in the Flags field
is set to 1. However, for the purposes of this specification, the
values for the Minimum Data Packet Size and Maximum Data Packet Size
fields shall be set to the same value, and this value should be set to
the packet size, even when the Broadcast Flag in the Flags field is
set to 1."

This particular bit of code causes issues for broadcasted, non-file
data (i.e. broadcast-flag=1 in the ASF header). These don't have a
fixed packet size but rather use the packet_length field that is
directly at the start of the ASF packet (line 600 of asf.c). As said
in the quote, in these broadcast streams, min_pktsize == max_pktsize
and these values are bigger than the actual ASF packets, with no
padding present.

I suggest the attached patch for asf.c to not pad the input stream if
the broadcast flag is set. With this patch applied, I can cat the ASF
file header (in the SDP) plus the ASF packet data from each RTSP
packet (minus a small MS-extension header) and I in fact get an ASF
file that can be played back using ffplay. (And yes, I'm working on
MS-RTSP and it partly works, I need to do some heavy refatoring in
asf.c before that can be submitted...)

Ronald

[1] http://go.microsoft.com/fwlink/?LinkId=89814
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: x
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081116/69bc9960/attachment.asc>