GNOME Bugzilla – Bug 572551
mpeg4videoparse fails to extract codec_data from this network camera video stream
Last modified: 2010-04-20 13:41:39 UTC
I have a ip camera that produces mpeg4 and i want to stream it via rtp. I have a problem because mpeg4videoparse fails to parse the stream.. The pipeline is souphttpsrc ! multipartdemux ! mpeg4videoparse ! .... Looking at the code it seems it can't find the VOS startcode. I'm attaching a dump created with souphttpsrc ! multipartdemux ! gdppay ! filesink and a wget http_url. First problem in the stream is that the camera is using image/mpeg4 and not video/mpeg4. You can fix it changing mapped caps in multipartdemux.c. This works: gst-launch-0.10 filesrc location=dump.log ! gdpdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! ximagesink This fails (no buffers after mpeg4videoparse): gst-launch-0.10 filesrc location=dump.log ! gdpdepay ! mpeg4videoparse ! fakesink -v
Created attachment 129147 [details] gdpay log
Created attachment 129148 [details] raw data from camera
commit 86056b3a0619300dae4729bd26d9fde7c3c48132 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Thu Feb 26 15:40:26 2009 +0100 mpeg4videoparse: handle more formats We only need a Video Object Start code before we can start pushing out data. Search for this code also instead of only looking for VOS and VOP. Fixes #572551.
mpeg4videoparse now works fine, thank you! But now i have the same problem with rtpmp4vpay so.. i've reopen the bug :) This hangs: gst-launch-0.10 souphttpsrc location=http://192.168.0.80/appro-cgi/mpeg4.cgi ! multipartdemux ! mpeg4videoparse ! rtpmp4vpay ! fakesink -v Without rtpmp4vpay it works fine, it's the same camera so you can replicate it using attached data.
commit 8b6c8b934ac0065218a273b42381106c862c6d19 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Mar 2 17:18:55 2009 +0100 rtpmp4vpay: Add support for more formats Hack around short header mpeg4 video files and put the short header as the config string. Fixes #572551.
I know you're starting to hate me but.. reopening the bug :) With the same dump mpeg4videoparse fails to extrac codec_data. I think the patch would be similar to what you've done in rtpmp4vpay.. - look for VOS even if you find 0x01 and not only VOS_STARTCODE - fix _handle_vos to not return if profile is zero thank you!
You said in Comment #4 that it works fine? what is failing now?
The problem is that mpeg4videoparse doesn't put codec_data in the caps.
commit 00148e3736ba61a5b5707511091b0d57ef026098 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Apr 20 15:37:03 2010 +0200 mpeg4videoparse: also set short configuration data in codec_data That is, header configuration may start at Video Object (startcode), rather than at Visual Object Sequence, which is catered for and parsed, so let's also take it as codec_data if no more available. Fixes (remainder of) #572551.