Bug 215556

I have tried cnn.com videos with gstreamer 0.10.10 and gst-plugins-base 0.10.10
and that works better. It still occasionally freezes for a bit, but it keeps going.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Should be:
http://webcvs.freedesktop.org/gstreamer/gst-plugins-base/gst/playback/gstplaybasebin.c?r1=1.115&r2=1.116

With change entry:
2006-09-15  Wim Taymans  <wim>

        * gst/playback/gstplaybasebin.c: (gst_play_base_bin_class_init),
        (gst_play_base_bin_init), (fill_buffer), (check_queue),
        (queue_threshold_reached), (gst_play_base_bin_set_property),
        (gst_play_base_bin_get_property):
        * gst/playback/gstplaybasebin.h:
        Don't use a 0 low watermark when buffering, it is catching starvation
        way too late. Instead, use a 3 second queue with 30 and 95
        percent low/high watermarks.
        Added queue-min-threshold property to configure low watermark.
        Use new _buffering message API.
        Make queue_threshold variable big enough to store a uint64 time value.
        API: playbin::queue-min-threshold property.

It might bring in some regressions
(http://bugzilla.gnome.org/show_bug.cgi?id=357577), and require some backporting
of the buffer API, though it should be quite straight forward (ie. just a
cut'n'paste job).

Created attachment 141917 [details]
gst-plugins-base-0.10.9-buffering-backports.patch

Backport the fixes made in the upstream playbin, as well as the new API
gst_message_new_buffering.

Hmm, is there abi concern here ? 
The patch changes the layout of the GstPlayBaseBin struct

From gst/playback/Makefile.am:

noinst_HEADERS = \
        gstplaybasebin.h \
        gststreaminfo.h \
        gststreamselector.h

I grepp'ed through the repo, and couldn't find anything other than ChangeLog and
Makefile entries related to that header file. So we should be fine with the ABI
change, it's internal to the plugin.

Just one thing though. We should probably rename gst_message_new_buffering to
something less likely to collide with other symbols when we upgrade GStreamer
and not the base, for example.

Ajax, need an updated patch for that, or will you do the sed job?

Ok, sounds fine then.

ajax, can you build this after
s/gst_message_new_buffering/backported_gst_message_new_buffering/
or similar ?

Actually, gst_message_new_buffering is static, so renaming it is pointless. 
I'm building this now.

Fixed in gstreamer-plugins-base-0.10.9-5.el5

We might also need to backport some bits out of:
http://bugzilla.gnome.org/show_bug.cgi?id=357577
which is one of the regressions introduced by the patch above.

Bastian, can you open a new bug for that ?

A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

Tested the following test case with gstreamer-plugins-base-0.10.9-6.el5 on
RHEL5-Client-20061226.nightly:
1. Get a collection of media files on alocal server
2. start apache
3. Applications -> Sound and Video - > Movie Player
4. Ctrl - L -> give the address of the media file
5. Check for the media to play
6. For testing the gstremer-fluendo plugins, store mp3 on the same folder and
repeat step 4
7. To test totem with gstreamer-fluendo plugins on a streaming video:ctrl - L ->
mms://nv.sina.com.cn/news/2006/12/27201324.wmv
Result: mp3 files and the online wmv can be played but there was an error
occurred when play the online wmv file:Internal data stream error.
------------
** Message: don't know how to handle video/x-wmv, wmvversion=(int)1,
framerate=(fraction)5000000/333333, width=(int)320, height=(int)240,
format=(fourcc)WMV1, pixel-aspect-ratio=(fraction)1/1, bitrate=(int)91755

** (totem:23788): WARNING **: message 0004001b from server not supported

** (totem:23788): WARNING **: could not resolve host "nv.sina.com.cn"

send error -6
Execute error -6
------------

Env:
[root@dhcp-0-179 ~]# rpm -qa | grep gstream
gstreamer-plugins-fluendo-video-0.10-7.el5
gstreamer-tools-0.10.9-3.el5
gstreamer-plugins-base-0.10.9-6.el5
gstreamer-plugins-good-0.10.4-2.el5
gstreamer-plugins-fluendo-windowsmedia-0.10-7.el5
gstreamer-plugins-fluendo-mp3-0.10-7.el5
gstreamer-0.10.9-3.el5

On x86_64, I can't get CNN videos (or any other WMVs) to work at all with the
plugin. The totem/firefox plugin loads, then seems to just disappear before
doing anything. In its place is a grey rectancle with no context menu...

If I try the video mentioned in comment #13, step 7, I see the following in the
terminal:
** Message: don't know how to handle video/x-wmv, wmvversion=(int)3,
framerate=(fraction)10000000/333333, width=(int)320, height=(int)240,
format=(fourcc)WMV3, pixel-aspect-ratio=(fraction)1/1,
codec_data=(buffer)4ff90a0100, bitrate=(int)439014

(In reply to comment #14)
> On x86_64, I can't get CNN videos (or any other WMVs) to work at all with the
> plugin. The totem/firefox plugin loads, then seems to just disappear before
> doing anything. In its place is a grey rectancle with no context menu...

This usually means that the viewer crashed...
By launching "firefox -debug" you can see the command-line used, and launch it
by hand (simply remove the "--xid XXX" argument from the line printed by the plugin)

> If I try the video mentioned in comment #13, step 7, I see the following in the
> terminal:
> ** Message: don't know how to handle video/x-wmv, wmvversion=(int)3,
> framerate=(fraction)10000000/333333, width=(int)320, height=(int)240,
> format=(fourcc)WMV3, pixel-aspect-ratio=(fraction)1/1,
> codec_data=(buffer)4ff90a0100, bitrate=(int)439014

This is bad, and that would mean that the WMV plugin doesn't work for your
system, check the output of "gst-inspect-0.10" to see whether the fluendo
plugins are there, and working.

i just tried gstreamer-plugins-fluendo-0.10-7.el5 on tree
RHEL5-Client-20070105.0, the x86_64 version.

The stream mentioned in comment #13 step 7 doesn't work for me - everything just
freezes trying to open it. Probably the server is down, or something.

However, i played around with streams from the page
http://www.praha6.cz/zast_video.html

When i copied the links from that page, and tried to load them in separately
launched Totem:
1. the mms link just popped up a dialog saying "Could not open location; You may
not have permission to open the file."
2. the http link completely crashed the player. Backtrace in attachment. The
link to the stream: http://streaming.wia.cz:443/Praha6 seems to be 100%
reproducible.

When i tried to open the streams in browser window, firefox either showed the
"grey rectangle" as zack mentioned, or crashed completely ( will file a bug on
this soon )

Created attachment 145171 [details]
Totem crash on http stream

Please file a new issue against the GStreamer Fluendo plugins, the bug is in there:

#0  0x0000003f84c75350 in strlen () from /lib64/libc.so.6
#1  0x0000003f84c45b88 in _IO_vfprintf_internal (s=0x7fff3c767ce0, format=<value
optimized out>, ap=0x7fff3c767e10) at vfprintf.c:1559
#2  0x0000003f84ce01cd in ___vsprintf_chk (s=0x2c9c85410 "GET ", flags=1,
slen=18446744073709551615, format=0x2aaab57fb13a "GET %s HTTP/1.0\r\n", 
    args=0x7fff3c767e10) at vsprintf_chk.c:87
#3  0x00002aaab57f8fc8 in mms_buffer_write_printf () from
/usr/lib64/gstreamer-0.10/libgstflumms.so

(In reply to comment #16)
> i just tried gstreamer-plugins-fluendo-0.10-7.el5 on tree
> RHEL5-Client-20070105.0, the x86_64 version.

Probably just need the latest mms plugin version:
"
So I put online an updated MMS plugin for all platforms. It fixes
several issues especially visible on all other platforms than x86_32.

So users of Solaris SPARC, Linux x86_64 and Linux PPC please test this
updated MMS version.
"

created bug 222018 on the issue.