Bug 582153 – rtpmp4vpay does not payload mp4v stream depayloaded with rtpmp4vdepay

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 582153 - rtpmp4vpay does not payload mp4v stream depayloaded with rtpmp4vdepay


Summary:	rtpmp4vpay does not payload mp4v stream depayloaded with rtpmp4vdepay


Status:	RESOLVED FIXED

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins-good
Version:	git master
Hardware:	Other All

Importance:	Normal normal
Target Milestone:	0.10.16
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2009-05-11 10:34 UTC by Marc Leeman
Modified:	2009-05-25 09:01 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
possible patch (1.50 KB, patch) 2009-05-12 16:44 UTC, Wim Taymans	committed	Details \| Review

Description Marc Leeman 2009-05-11 10:34:44 UTC

Please describe the problem:
When receiving a stream from an IndigoVision VideoBridge 8000 vp881; the rtp/mpeg4 stream is being stripped down to elementary MPEG4 video.

$ gst-launch udpsrc multicast-group=226.255.0.14 port=49400 caps="application/x-rtp,clock-rate=(int)90000,media=video,encoding-name=MP4V-ES" ! gstrtpjitterbuffer latency=200 ! gstrtpptdemux ! rtpmp4vdepay ! ffdec_mpeg4 ! autovideosink

When trying to send out this MPEG4 stream, in RTP with
$ gst-launch udpsrc multicast-group=226.255.0.14 port=49400 caps="application/x-rtp,clock-rate=(int)90000,media=video,encoding-name=MP4V-ES" ! gstrtpjitterbuffer latency=200 ! gstrtpptdemux ! rtpmp4vdepay ! queue2 ! rtpmp4vpay send-config=true ! udpsink host=226.226.226.2 port=2266

rtpmp4vpay does not sync on the mp4v stream; nothing is being sent.

verified with:
gst-launch udpsrc multicast-group=226.255.0.14 port=49400 caps="application/x-rtp,clock-rate=(int)90000,media=video,encoding-name=MP4V-ES" ! gstrtpjitterbuffer latency=200 ! gstrtpptdemux ! rtpmp4vdepay ! queue2 ! rtpmp4vpay send-config=true ! fakesink dump=true



Steps to reproduce:
cf supra

Actual results:
nothing :-)

Expected results:
data passed through gstreamer

Does this happen every time?
yes

Other information:
I'll be adding a gdp dump in a sec.

Comment 1 Marc Leeman 2009-05-11 10:40:13 UTC

$ gst-launch udpsrc multicast-group=226.255.0.14 port=49400 caps="application/x-rtp,clock-rate=(int)90000,media=video,encoding-name=MP4V-ES" ! gstrtpjitterbuffer latency=200 ! gdppay ! filesink dump=indigovision-videobridge-vp881.gdp.log

http://crichton.homelinux.org/~marc/downloads/indigovision-videobridge-vp881.gdp.log.bz2

I have no doubt that this is due to something in the payload of the mpeg4 data; I am just reporting the asymmetric behaviour between rtpmp4vdepay and rtpmp4vpay

Comment 2 Wim Taymans 2009-05-12 16:44:05 UTC

Created attachment 134512 [details] [review]
possible patch

I don't know if this is right but it seems to work. (don't have any mpeg4 spec here)

Comment 3 Marc Leeman 2009-05-13 08:18:54 UTC

Tnx. 

Verified with the HW encoder. Is this a patch that will end up in good or do I have to keep track of this patch yself.

Comment 4 Wim Taymans 2009-05-18 08:43:50 UTC

I will probably commit it to good after the freeze

Comment 5 Chris Shoemaker 2009-05-24 23:07:17 UTC

Good is unfrozen.  Has the fix been reviewed/committed?

Comment 6 Wim Taymans 2009-05-25 09:01:23 UTC

Thanks for the reminder.

commit e13e3c624924745b1ff75a84f5e4016ce1dca0db
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Tue May 12 18:39:28 2009 +0200

    rtpmp4vpay: don't look for headers in some cases
    
    In some streams (starting with 00000100) don't look for the headers but push
    data as it is.
    Fixes #582153