[gstreamer-bugs] [Bug 607555] asfmux plugin generates data streams incompatible with WMSP (MMSH) and WMP
bugzilla at gnome.org
Fri Jan 22 03:54:29 PST 2010
GStreamer | gst-plugins-bad | 0.10.25
--- Comment #10 from Håkon Skjelten <skjelten at pvv.org> 2010-01-22 11:54:26 UTC ---
(In reply to comment #9)
> Where have you read/seen that the asf packet length is indeed the "media data
> length" and not the total packet length?
> I'd be surprised that asfdemux remained with this bug for all this time. This
> would possibly mean that the packet length field isn't used. That leads me to
> another question: does your WMSP stuff need the packet length field? I'm
> considering not setting it in asfmux.
I agree that the specification can be a bit unclear at this point. The reason
why I believe the packet length = total packet length - padding length is
because I found this to be the case in Microsoft's own streaming solution.
To test this try to stream the following stream in WMP:
while you use tcpdump. If you look at the network dump in wireshark you can see
that the stream changes the packet size between 8000 and lower values
(typically 7998) - indicating padding. To save you some time with wireshark:
switch to hex dump, search for $D and skip 15 bytes. Then you'll see the packet
size field - normally 40 1f => 8000. If you where right that packet length ==
total packet length, then this would be wrong. My thinking is that if Microsoft
implements it this way - then that is the "correct way" to do it.
I don't think we should ignore this field entirely though, as that would make
us incompatible with the specification - strictly speaking.
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs