GNOME Bugzilla – Bug 744875
vdpaumpeg4dec doesn't work with a udp/rtp
Last modified: 2015-02-21 14:57:30 UTC
i'm trying to stream mpeg4 encoded video through udp/rtp and decode it in the receiving pipeline using vdpau plugins. the receiving pipeline is running on an arm soc (a20 allwinner, armhf linux-sunxi kernel 3.4.10). limited vdpau support is provided through libvdpau-sunxi which works very well for mplayer. when i run a pipeline with a local video source like videotestsrc it works fine. $ gst-launch-0.10 -v videotestsrc ! ffenc_mpeg4 ! queue ! vdpaumpeg4dec ! vdpauvideopostprocess ! vdpausink when i use a udpsrc it breaks: $ GST_DEBUG=vdpaumpeg4dec:5 gst-launch-0.10 -v udpsrc port=5000 ! 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! vdpaumpeg4dec ! vdpauvideopostprocess ! vdpausink Setting pipeline to PAUSED ... [VDPAU SUNXI] VE version 0x1623 opened. /GstPipeline:pipeline0/GstVdpVideoPostProcess:vdpvideopostprocess0.GstVdpOutputSrcPad:src: device = ((GstVdpDevice*) 0x136b818) /GstPipeline:pipeline0/GstVdpMpeg4Dec:vdpmpeg4dec0.GstVdpVideoSrcPad:src: device = ((GstVdpDevice*) 0x136b818) Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96 /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0.GstPad:src: caps = video/mpeg, mpegversion=(int)4, systemstream=(boolean)false /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96 /GstPipeline:pipeline0/GstVdpMpeg4Dec:vdpmpeg4dec0.GstPad:sink: caps = video/mpeg, mpegversion=(int)4, systemstream=(boolean)false 0:00:02.875335294 3532 0x1358e60 WARN vdpaumpeg4dec mpeg4/gstvdpmpeg4dec.c:196:gst_vdp_mpeg4_dec_handle_configuration: Skipping frame since we're not configured yet ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2625): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: streaming task paused, reason custom-error (-100) Execution ended after 2126883001 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... /GstPipeline:pipeline0/GstVdpMpeg4Dec:vdpmpeg4dec0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = NULL Setting pipeline to NULL ... Freeing pipeline ... i think the vdpau code expects the mpeg4 stream to be configured before any frames are decoded. the warning suggests that the code would tolerate this situation but right after the frame is consumed the custom flow error is returned in gstvdpmpeg4dec.c.
Thanks for the bug report, but GStreamer 0.10 is no longer maintained. Please feel free to re-open or file a new report if this is still an issue with recent 1.x versions of GStreamer (although I believe the vdpau plugin has only partially been ported).
ok. is there a way to find out what is still missing? is there someone currently working on it?
The code is in gst-plugins-bad/sys/vdpau, only mpeg2 is currently enabled. If I remember well, what is missing is: - Some porting (specially to new parser API) - Context Sharing - GL Upload - H264 / MPEG4 - Port PostProcessor; - Port OutputBuffer to OutputMemory - Port OutputBufferPool to be a GstBufferPool etc. Recently https://bugzilla.gnome.org/show_bug.cgi?id=744698 was the only activity about VDPAU. If you intend to do this long work, please file a bug.