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 660752 - [decodebin2] can't parse mpeg4 tcp stream on client side
[decodebin2] can't parse mpeg4 tcp stream on client side
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.35
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-10-03 07:05 UTC by Tibor Kocsis
Modified: 2012-09-24 09:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Tibor Kocsis 2011-10-03 07:05:07 UTC 
Hi,

using these pipelines:

- for server: 
gst-launch -v videotestsrc  ! \
video/x-raw-yuv,width=640,height=480,framerate=10/1 ! clockoverlay ! \
ffmpegcolorspace ! ffenc_mpeg4 ! multipartmux ! tcpserversink \
host=x.x.x.x port=5000

- for client:
gst-launch -v tcpclientsrc host=x.x.x.x port=5000 ! multipartdemux \
! decodebin2 ! xvimagesink

It doesn't work, on the client there are just the following lines:

0:00:10.580064107 15854      0x1810140 WARN          mpegvideoparse
mpegvideoparse.c:246:mpegvideoparse_handle_sequence:<mpegvideoparse0>
Width/height out of valid range [16, 4096]
0:00:12.080034791 15854      0x1810140 WARN          mpegvideoparse
mpegvideoparse.c:246:mpegvideoparse_handle_sequence:<mpegvideoparse0>
Width/height out of valid range [16, 4096]

If I use ffdec_mpeg4 instead of decodebin2 it's working.

Regards
Tibor
Comment 1 Sebastian Dröge (slomo) 2011-10-03 08:32:19 UTC 
What are the caps on multipartdemux' srcpad?
Comment 2 Sebastian Dröge (slomo) 2011-10-03 08:33:30 UTC 
And does it work if you manually plug mpeg4videoparse (note the 4)
Comment 3 Tibor Kocsis 2011-10-03 08:45:45 UTC 
with manually plugged mpeg4videoparse it's working:

gst-launch -v tcpclientsrc host=10.30.0.80 port=5000 ! multipartdemux ! mpeg4videoparse ! ffdec_mpeg4 ! ffmpegcolorspace ! xvimagesink

here is a GST_DEBUG=3 and -v log with decodebin2:

http://pastebin.com/raw.php?i=gZtk2yp2

As I see the caps on multipartdemux's srcpad is only "video/mpeg".
Comment 4 Sebastian Dröge (slomo) 2011-10-03 08:48:00 UTC 
(In reply to comment #3)

> As I see the caps on multipartdemux's srcpad is only "video/mpeg".

That's the problem then. decodebin2 will autoplug the first factory that matches this, which is mpegvideoparse. mpegvideoparse will only work with MPEG1/2 though.

To fix this either set correct caps on the stream or don't set any caps at all and let the typefinder in decodebin2 do its job.
Comment 5 Tibor Kocsis 2011-10-03 08:49:56 UTC 
In the example pipelines I don't set any caps at all. How can I fix it?
Comment 6 Sebastian Dröge (slomo) 2011-10-03 09:02:33 UTC 
You should be able to set the sink-caps property of decodebin2. The problem here probably is that multipart does not support to store all information needed from the caps.
Comment 7 Levente Farkas 2011-10-03 09:05:58 UTC 
imho it's still a gstreamer bug. if i can put together a proper pipeline while decodebin2 can't then it's a bug in multipart...
Comment 8 Sebastian Dröge (slomo) 2011-10-03 09:12:00 UTC 
I don't know the MIME multipart standard but I'd guess that it's a limitation there.
Comment 9 Tobias Mueller 2012-02-08 09:29:57 UTC 
So is this bug NOTGNOME then?
Comment 10 Tobias Mueller 2012-09-24 09:24:32 UTC 
k. closing as NOTGNOME. Please reopen if this is not appropriate.