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

Ronald S. Bultje rsbultje
Mon Nov 17 00:38:39 CET 2008


On Sun, Nov 16, 2008 at 6:25 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> this patch needs to be tested against asf/wmv/wma/dvr-ms files
> i think ive never seen a asf file with a packet size < min
> though iam not surprised by MSs asshattry of redefining min & max and using
> smaller packets

They explicitely state that fact exactly in the RT(S)P-MS Specs [1]:

"If the ASF data packet contains a Padding Data field, as specified in
[ASF] section 5.2.4, that field SHOULD be removed before encapsulating
the ASF data packet in an RTP packet. If the Padding Data field is
removed, the Padding Length field in the ASF payload parsing
information section (as specified in [ASF] section 5.2.2) MUST be
updated to indicate a nonexistent Padding Data field."

So yes, this is their typical "asshattry", as you all it. :-).

As for stream testing, http://samples.mplayerhq.hu/ has all the
sources? I tested it on some ASF files but they don't have the
broadcast flag set so of course there is no difference in behaviour.
It'd be more interesting if there were some broadcasted files or dumps
I could test it with before&after...

> btw, does seeking work?

On the RTSP-stream dumps? I don't know, they don't have a length
field, so I can't seek relative to length in ffplay. Is there some way
in ffplay to seek to absolute timepoints? I think it'll work, the sync
on 0x82,0x00,0x00 in asf_get_packet() should work for these streams
also... Of course, this is about as exact as seeking in unindexed VBR
mp3 files...


[1] http://msdn.microsoft.com/en-us/library/cc245238.aspx

More information about the ffmpeg-devel mailing list