After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 396042 - mpeg4 video typefinder loops endlessly on quicktime redirect
mpeg4 video typefinder loops endlessly on quicktime redirect
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal major
: 0.10.12
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-13 09:23 UTC by Christian Fredrik Kalager Schaller
Modified: 2007-01-22 14:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Christian Fredrik Kalager Schaller 2007-01-13 09:23:15 UTC
Please describe the problem:
Wim recently fixed up the code to handle Steve Jobs keynote:
http://events.apple.com.edgesuite.net/j47d52oo/event/

But we have to manually enter the RTSP stream URI as
GStreamer can't parse the redirects in the initial .mov files
we are given.

Clicking on the keynote button will bring up Totem with the "http://stream.qtv.apple.com/events/jan/j47d52oo/m_8848125_350_ref.mov" URL, which should redirect to http://stream.qtv.apple.com/events/jan/j47d52oo/sub8848125_2_350_ref.mov but doesn't. 

Steps to reproduce:
The uri we want to reach which GStreamer now handles is this one:
rtsp://a2047.v1413b.c1413.g.vq.akamaistream.net/5/2047/1413/1_h264_110/1a1a1ae656c632970267e04ebd3196c428970e7ce857b81c4aab1677e445aedc3fae1b4a7bafe013/8848125_1_110.mov

Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Tim-Philipp Müller 2007-01-13 13:00:22 UTC
This has something to do with typefind, since

 gst-launch-0.10 filesrc location=foo.mov ! qtdemux -m

shows the redirect messages just fine, but gst-typefind-0.10 foo.mov does the same as playbin, namely end up with 100% cpu usage somewhere. Could be related to recent core changes, works fine with core/base versions packaged in edgy.

Comment 2 Andy Wingo 2007-01-14 19:54:23 UTC
The typefind function appears to be borked, here's the result of stepping through mpeg4_video_type_find:

1329        data = gst_type_find_peek (tf, offset, 4);
(gdb) 
1330        if (data && data[0] == 0 && data[1] == 0 && data[2] == 1) {
(gdb) 
1331          int sc = data[3];
(gdb) 
1333          if (sc == 0xB0)           /* visual_object_sequence_start_code */
(gdb) 
1335          else if (sc == 0xB5)      /* visual_object_start_code */
(gdb) 
1337          else if (sc >= 0x00 && sc <= 0x1F) {      /* video_object_start_code */
(gdb) 
1340          } else if (sc >= 0x20 && sc <= 0x2F) {    /* video_object_layer_start_code */
(gdb) 
1341            if (seen_vos) {
(gdb) 
1329        data = gst_type_find_peek (tf, offset, 4);

offset is never updated, so it loops forever.
Comment 3 Tim-Philipp Müller 2007-01-22 12:04:34 UTC
Should be fixed now:

 2007-01-22  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/typefind/gsttypefindfunctions.c: (mpeg4_video_type_find):
          Don't go into an endless loop if the file starts with 00 00 01 2X,
          like quicktime redirect files might. Fixes #396042.

        * tests/check/Makefile.am:
        * tests/check/gst/.cvsignore:
        * tests/check/gst/typefindfunctions.c: (GST_START_TEST),
        (typefindfunctions_suite):
          Add unit test for the above.