[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 #4 from Håkon Skjelten <skjelten at pvv.org> 2010-01-21 15:26:55 UTC ---
Ok, here are some comments from the different parts of the patch:

-  GST_WRITE_UINT64_LE (*buf + 16, 0);   /* object size - needs updating */
+  
+  /* Data object size. This is always >= ASF_DATA_OBJECT_SIZE. The standard
+   * specifically accepts the value 0 in live streams, but WMP is not
accepting
+   * this while streaming using WMSP, so we default to minimum size also for
+   * live streams. Otherwise this field must be updated later on when we know 
+   * the complete stream size.
+   */
+  GST_WRITE_UINT64_LE (*buf + 16, ASF_DATA_OBJECT_SIZE);
+

The correct size for all live video streams are _always_ ASF_DATA_OBJECT_SIZE.
As you know the specification explicitly allows 0 in live streams - telling
demuxers to do a:
if (data_object_size == 0)
  data_object_size = ASF_DATA_OBJECT_SIZE;

To add a property to the muxer so that you can force it to 0 seems like
overkill to me, but this is of course your decision.

Without this change windows media player won't even try to play the stream.
Shame on them. Next problem is that the windows media player breaks down after
a certain time of buffering. The reason for this is that we don't send the
correct data_packet size when we do padding. The part of the diff that fixes
this is extracted below:

-  GST_WRITE_UINT32_LE (data + 2, asfmux->packet_size);
....
+    GST_WRITE_UINT32_LE (data + offset, asfmux->packet_size - size_left);

We _must_ subtract size_left from the total length or we typically get packets
with packet size 4803 bytes if we pad 3 bytes. This is a critical error and
makes us violate the standard.

With these two fixes there is one major problem left: Windows Media Player is
buffering forever. It took me horribly many hours of tweaking the asfmux plugin
to realize that it was due to the packet size and padding size in the parsing
info header. WMP can for some unknown reason not accept 32 bit data & padding
size. A quick fix would be to just always force 16 bit packet & padding sizes,
we hardly ever want packet sizes above 64K, but it felt a bit hackish. So
instead I created a function to check if the sizes are small enough to fit in
16 bit and adapt the parsing info header accordingly. On my PC the wmsp_server
now finally streams correctly.

All my work on the asfmux was done by analyzing the asf headers in NRK's
(Norwegian Broadcasting Corporation) TV broadcast streams available on
http://www.nrk.no/nett-tv/direkte/nrk1/
They use Microsoft's own streaming server solution and could easily be
downloaded and re-streamed with wmsp_server.

I hope this made things a bit clearer. And I find it strange that the
wmsp_server didn't work for you. It shouldn't segfault while streaming - only
if you restart the client without restarting the server.

Oh, and to help you do debugging with WMP I can recommend that you download
this web page and opens it in internet explorer:
http://blogs.msdn.com/randomnumber/archive/2009/07/20/wmp-debug-page-to-dump-player-events.aspx
It's not great - but better than working directly in WMP (just remember to
allow activex plugins - or it won't work).

I'm interested in getting this WMSP work out of the box in gstreamer - so
please tell me more about how far you get with the test program and I'll see if
I can assist you in any way.

-- 
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.