GNOME Bugzilla – Bug 667564
mpeg4videoparse: does not detect config data when VOP only stream is sent
Last modified: 2013-11-27 19:53:44 UTC
A hardware based encoder only sends VOP headers; and as such, the config_data is never found (mp4vparse->vol_offset remains smaller than 0 and vo_found remains FALSE, though it is in the stream), and the data is dropped by default. Disabling the parser (or enabling drop=0 on the mpeg4videoparser) allows correct decoding. clip of 30": http://crichton.homelinux.org/~marc/downloads/mango-dsp-ivs-raven-m.gdp.gz This bug also affects rtpmp4vpay when the data is sent out the rtp payloader
In ffmpeg, this code is called for bad headers: if(s->time_increment_bits==0 || !(show_bits(gb, s->time_increment_bits+1)&1)){ av_log(s->avctx, AV_LOG_ERROR, "hmm, seems the headers are not complete, trying to guess time_increment_bits\n"); for(s->time_increment_bits=1 ;s->time_increment_bits<16; s->time_increment_bits++){ if ( s->pict_type == AV_PICTURE_TYPE_P || (s->pict_type == AV_PICTURE_TYPE_S && s->vol_sprite_usage==GMC_SPRITE)) { if((show_bits(gb, s->time_increment_bits+6)&0x37) == 0x30) break; }else if((show_bits(gb, s->time_increment_bits+5)&0x1F) == 0x18) break; } av_log(s->avctx, AV_LOG_ERROR, "my guess is %d bits ;)\n",s->time_increment_bits); } GStreamer fails here (gst_mpeg4_parse_video_object_layer): READ_UINT8 (&br, video_object_layer_start_code, 8); if (!(video_object_layer_start_code >= GST_MPEG4_VIDEO_LAYER_FIRST && video_object_layer_start_code <= GST_MPEG4_VIDEO_LAYER_LAST)) goto wrong_start_code; Adding header scanning (offset 1 byte) 0:00:00.139527614 874 0x1502f30 ERROR ffmpeg :0:: hmm, seems the headers are not complete, trying to guess time_increment_bits 0:00:00.139653102 874 0x1502f30 ERROR ffmpeg :0:: my guess is 5 bits ;) should bring us a step closer.
sdp config data --------------- 00 00 01 b0 // GST_MPEG4_VIDEO_OBJ_SEQ_START 03 00 00 01 b5 // GST_MPEG4_VISUAL_OBJ 09 00 00 01 01 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST 00 86 e0 00 24 e2 20 03 e8 00 68 82 48 00 ce 18 b0 22 40 a3 1f 00 00 01 b3 // GST_MPEG4_GROUP_OF_VOP 00 10 07 mpeg4 raw rtp ------------- 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST 00 86 e0 00 24 e2 20 03 e8 00 68 82 48 00 ce 18 b0 22 40 a3 1f 00 00 01 b6 // GST_MPEG4_VIDEO_OBJ_PLANE
The camera send the config data out of band in the rtsp session, but also sends it in band in the stream. Gst does not pick this up in the stream if the RTSP is not available (silly 3rd party stream mangler).
sdp config data --------------- The original data in the RTSP SDP 00 00 01 b0 // GST_MPEG4_VIDEO_OBJ_SEQ_START 03 00 00 01 b5 // GST_MPEG4_VISUAL_OBJ 09 00 00 01 01 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST 00 86 e0 00 24 e2 20 03 e8 00 68 82 48 00 ce 18 b0 22 40 a3 1f 00 00 01 b3 // GST_MPEG4_GROUP_OF_VOP 00 10 07 mpeg4 raw rtp ------------- The config data is partially in the raw MPEG4 stream 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST 00 86 e0 00 24 e2 20 03 e8 00 68 82 48 00 ce 18 b0 22 40 a3 1f 00 00 01 b6 // GST_MPEG4_VIDEO_OBJ_PLANE rtsp clean ---------- The configuration data is cleanly multiplexed with GStreamer when the full RTSP is used 00 00 01 b0 // GST_MPEG4_VIDEO_OBJ_SEQ_START 03 00 00 01 b5 // GST_MPEG4_VISUAL_OBJ 09 00 00 01 01 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST 00 86 e0 00 24 e2 20 03 e8 00 68 82 48 00 ce 18 b0 22 40 a3 1f 00 00 01 b0 // GST_MPEG4_VISUAL_OBJ_SEQ_START 03 00 00 01 b5 // GST_MPEG4_VISUAL_OBJ 09 00 00 01 01 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST 00 86 e0 00 24 e2 20 03 e8 00 68 82 48 00 ce 18 b0 22 40 a3 1f 00 00 01 b3 // GST_MPEG4_GROUP_OF_VOP 00 10 07 00 00 01 b6 // GST_MPEG4_VIDEO_OBJ_PLANE caps with rtsp -------------- When looking at the caps of the mpeg4 parser with the full RTSP session 00 00 01 b0 // GST_MPEG4_VIDEO_OBJ_SEQ_START 03 00 00 01 b5 // GST_MPEG4_VISUAL_OBJ 09 00 00 01 01 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST 00 86 e0 00 24 e2 20 03 e8 00 68 82 48 00 ce 18 b0 22 40 a3 1f 00 00 01 b3 // GST_MPEG4_GROUP_OF_VOP 00 10 07
Created attachment 206620 [details] [review] Reconstruct config based on broken stream The stream is a squence of VOPs, so the state machine in the parser fails. The patch make an exception when there is no config an tries 'harder'; by acting on GST_MPEG4_VIDEO_LAYER_FIRST flag and scanning for the next header. This partial copied in a full configuration and the caps are set.
Thanks for the report and the investigation, took some time to get around to this ... Referring to the dumps above ---- 00 00 01 b5 // GST_MPEG4_VISUAL_OBJ 09 00 00 01 01 00 00 01 20 // GST_MPEG4_VIDEO_LAYER_FIRST ---- There is a VideoObject startcode in there that is not so explicitly flagged; 00 00 01 01 However, the raw data does not have this one and starts directly with VideoObjectLayer. So, the problem seems to be that we currently don't allow a frame to start at VideoObjectLayer, and also do not have this trigger config_found. That is arguably strange or a bug, since VideoObject has no real substance/data other than a startcode. The link seems no longer valid, so sticking to theory here. Following commit also allows for VideoObjectLayer to trigger whatever VideoObject triggers (start of frame, config): commit fac0f1f668aaa5c39d4d64618c309ca3f732c28a Author: Mark Nauwelaerts <mnauw@users.sourceforge.net> Date: Sat Nov 23 11:23:35 2013 +0100 mpeg4videoparse: accept VideoObjectLayer as start of frame and config ... which it deserves as much as VideoObject. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=667564
Yes, I had some problems with dyndns, I can make file available again on a different hostname with afraid.org