[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 #5 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2010-01-21 15:49:46 UTC ---
(In reply to comment #4)
> 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.

Yes, other devels also agreed with you and convinced me, so no property :)

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

Currently I'm tracking a regression introduced by your patch with a simple
pipeline like:

gst-launch videotestsrc num-buffers=500 ! ffenc_wmv2 ! asfmux ! filesink
location=test.asf

It doesn't play till the end in totem anymore (haven't tested other players
yet).

After solving this, I'll push your patch.

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