[gstreamer-bugs] [Bug 607555] asfmux plugin generates data streams incompatible with WMSP (MMSH) and WMP

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=607555
  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:
http://straumV.nrk.no/nrk_tv_webvid03_h
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.