GNOME Bugzilla – Bug 601501
[ffdec_vc1] Fails to decode some VC1 streams that work with mplayer
Last modified: 2009-11-11 19:32:26 UTC
+++ This bug was initially created as a clone of Bug #601421 +++ I am trying to play this file in Totem: http://www.linuxrising.org/files/demo_VC-1.wmv But it fails with this message: ** Message: don't know how to handle audio/x-wma, wmaversion=(int)3, bitrate=(int)192000, depth=(int)16, rate=(int)48000, channels=(int)2, block_align=(int)4096, codec_data=(buffer)1000030000000000000000000000e0000000 ** Message: Error: Internal data stream error. gstasfdemux.c(1486): gst_asf_demux_loop (): /GstPlayBin:play/GstDecodeBin:decodebin0/GstASFDemux:asfdemux0: streaming stopped, reason not-negotiated So the audio not playing is understandable, but no video appears either.
Ok, the file mentioned above contains VC1 that our ffdec_vc1 doesn't like while mplayer does like it. Other files that failed like the subject says can't be found... so let's reassign this to gst-ffmpeg ;)
This patch I made a while back fixes it, but breaks some other cases, which is why I didn't push it yet: commit a424c27c5e3c5aa0c161d0d6116b86c1d801e0f4 Author: Jan Schmidt <thaytan@noraisin.net> Date: Thu Oct 1 02:48:35 2009 +0100 ffmpeg: VC-1/WMV3 fixes. Use format field in the pad caps to differentiate VC-1 from WMV3. Add a different dodgy hack to populate the extradata size field (first byte) when it is 0 - as it seems to be for some test files. diff --git a/ext/ffmpeg/gstffmpegcodecmap.c b/ext/ffmpeg/gstffmpegcodecmap.c index 584be8e..bb5ee6b 100644 --- a/ext/ffmpeg/gstffmpegcodecmap.c +++ b/ext/ffmpeg/gstffmpegcodecmap.c @@ -965,11 +965,12 @@ gst_ffmpeg_codecid_to_caps (enum CodecID codec_id, case CODEC_ID_WMV3: caps = gst_ff_vid_caps_new (context, codec_id, "video/x-wmv", - "wmvversion", G_TYPE_INT, 3, NULL); + "wmvversion", G_TYPE_INT, 3, "format", GST_TYPE_FOURCC, + GST_MAKE_FOURCC ('W', 'M', 'V', '3'), NULL); break; case CODEC_ID_VC1: caps = gst_ff_vid_caps_new (context, codec_id, "video/x-wmv", - "wmvversion", G_TYPE_INT, 3, "fourcc", GST_TYPE_FOURCC, + "wmvversion", G_TYPE_INT, 3, "format", GST_TYPE_FOURCC, GST_MAKE_FOURCC ('W', 'V', 'C', '1'), NULL); break; case CODEC_ID_QDM2: @@ -2156,6 +2157,11 @@ gst_ffmpeg_caps_with_codecid (enum CodecID codec_id, context->extradata_size = size; } + /* Hack for VC1. Sometimes the first (length) byte is 0 for some files */ + if (codec_id == CODEC_ID_VC1 && size > 0 && data[0] == 0) { + context->extradata[0] = (guint8) size; + } + GST_DEBUG ("have codec data of size %d", size); } else if (context->extradata == NULL) { /* no extradata, alloc dummy with 0 sized, some codecs insist on reading @@ -2716,7 +2722,7 @@ gst_ffmpeg_caps_to_codecid (const GstCaps * caps, AVCodecContext * context) { guint32 fourcc; - if (gst_structure_get_fourcc (structure, "fourcc", &fourcc)) { + if (gst_structure_get_fourcc (structure, "format", &fourcc)) { if ((fourcc == GST_MAKE_FOURCC ('W', 'V', 'C', '1')) || (fourcc == GST_MAKE_FOURCC ('W', 'M', 'V', 'A'))) id = CODEC_ID_VC1;
... and I just figured out why. Pushing in a sec...
pushed: commit 62d54db07d7b862ec147f2a35bd3eda1a7530b38 Author: Jan Schmidt <thaytan@noraisin.net> Date: Thu Oct 1 02:48:35 2009 +0100 ffmpeg: VC-1/WMV3 fixes. Use format field in the pad caps to differentiate VC-1 from WMV3. Fix a typo in the caps creation and parsing - the field is called 'format' - not 'fourcc' Add a dodgy hack to populate the extradata size field (first byte) when it is 0 - as it seems to be for some (Matroska) test files.
> Use format field in the pad caps to differentiate VC-1 from WMV3. > Fix a typo in the caps creation and parsing - the field is called > 'format' - not 'fourcc' FWIW, I believe this either changed at some point, and/or we had both for a while, or it was different depending on the demuxer used, or something ;)
The only thing I know of off the top of my head where that was wrong was in the fluendo codecs, I think.