Is it an issue which is only reproducible with gst 1.4?
Does any of the vc1 bitstream (not under asf container)is playing with the mentioned pipeline?

(In reply to comment #1)
> Is it an issue which is only reproducible with gst 1.4?
> Does any of the vc1 bitstream (not under asf container)is playing with the
> mentioned pipeline?

our test only cover gst 1.4, and all vc1 bitstream have this issue.

The problem is in vc1parse. To play a VC-1 file within an ASF container works fine with vaapidecode.

According to my bisect, vc1parse has never been able to parse bitstream files. In this sense this is not a regression, but a unsupported feature.

Zhixinx, does those samples working with the older gstremaer-vaapi releases??like 0.5.8 for eg..?,,And may be with gstreamer-1.2? I am wondering how you tested those samples before..

(In reply to comment #4)
> Zhixinx, does those samples working with the older gstremaer-vaapi
> releases??like 0.5.8 for eg..?,,And may be with gstreamer-1.2? I am wondering
> how you tested those samples before..

sreerenj, sorry, my mentioned reproduce step was wrong.

the following command is used for vp8 decoding test before:
 gst-launch-1.0 filesrc location=/root/media_tools/decoder/bitstreams_vc1/SA00059.vc1 '!' video/x-wmv, width=352, height=288 '!' vaapidecode '!' vaapisink sync=false

it can work on:
Gstreamer10:(1.0)4e880d4d1e151ea64f83c28b5c3e1bbc06c57903
Gst_plugins_base10:(1.0)2dd3f028c1e6dea799d7496639f53220818b20b1
Gst_plugins_good10:(1.0)643d425f51f81b56deec16c01162637546708ee5
Gst_plugins_ugly10:(1.0)c7c911b8320576429e4a4234a1e29ec7436e6814
Gst_plugins_vaapi10:(master)7f5b9edb14245abba7cc1dad430876bee0c2ca75

But it cannot work on:
Gstreamer10:(1.4)ae4c70813b936c5c507a8f47d0532612f1419e50
Gst_plugins_base10:(1.4)094f90c4c55da9017decb80b922e48cda77a93c6
Gst_plugins_good10:(1.4)ab60576c97d200cfac626e3f6e5d5efa440939ef
Gst_plugins_ugly10:(1.4)e94ce59c72961cc5e94adb19525f49a92e88636c
Gst_plugins_vaapi10:(master)ad2941c44b2a938a31ece1a41474dab687b2cd8f

error log:
[root@x-hswmedia infrastructure]# GST_DEBUG=vaapi:4 gst-launch-1.0 filesrc location=/root/media_tools/decoder/bitstreams_vc1/SA00059.vc1 '!' video/x-wmv, width=352, height=288 '!' vaapidecode '!' vaapisink sync=false
0:00:00.006650073 13748      0x26b3520 INFO                   vaapi gstvaapidisplay.c:119:libgstvaapi_init_once: gstreamer-vaapi version 0.5.9-78-gad2941c
libva info: VA-API version 0.37.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_37
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapidecode0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL;
ERROR: from element /GstPipeline:pipeline0/GstCapsFilter:capsfilter0: Filter caps do not completely specify the output format
Additional debug info:
gstcapsfilter.c(359): gst_capsfilter_prepare_buf (): /GstPipeline:pipeline0/GstCapsFilter:capsfilter0:
Output caps are unfixed: image/jpeg; video/mpeg, mpegversion=(int)2, profile=(string){ simple, main }; video/x-h264, profile=(string){ main, high, constrained-baseline, multiview-high, stereo-high }; video/x-wmv, wmvversion=(int)3, format=(string)WVC1, profile=(string)advanced; video/x-wmv, wmvversion=(int)3, profile=(string){ simple, main }
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

These are the results of my analysis (any correction is welcome):

> [root@x-hswmedia infrastructure]# GST_DEBUG=vaapi:4 gst-launch-1.0 filesrc
location=/root/media_tools/decoder/bitstreams_vc1/SA00059.vc1 '!' video/x-wmv,
width=352, height=288 '!' vaapidecode '!' vaapisink sync=false

The capsfilter doesn't fixate the caps anymore, hence the error "Filter caps do not completely specify the output format".

I hacked (dirtily) vc1parse in order to fixate some caps even in the stream is not parsed (because this one is not). In the case of the file SA00079.vc1, the vaapidecoder shows:

WARN                   vaapi gstvaapidecoder_vc1.c:1064:decode_ebdu: unsupported BDU type 29
ERROR            vaapidecode gstvaapidecode.c:271:gst_vaapidecode_decode_frame: decode error 8

Other files, such as SA00048.vc1, SA00079.vc1, etc. don't show decoding errors but my gstvc1parser's hack asserts before prerollling.

Also, I noticed that GStreamer lacks of a typefinder for WMV3 and WC1, hence the decodebin could not autoconnect neither a parser nor a decoder.

You can implement typefinders for vc1 in upstream :) 
May be some parser fixes in gstreamer-vaapi(29 is the frame_user bdu, right)?? We are basically doing all necessary parsing with in gstremaer-vaapi irrespective of what parser is doing.

(In reply to comment #7)
> You can implement typefinders for vc1 in upstream :) 

I'm looking how libav does it ;)

> May be some parser fixes in gstreamer-vaapi(29 is the frame_user bdu, right)??
> We are basically doing all necessary parsing with in gstremaer-vaapi
> irrespective of what parser is doing.

So, basically do we need "something"  that fixates the caps and leave the rest to vaapidecode?

I know elementary vc1 bitstrem handling is a mess up, and even the upstream parser is not something stable enough...But as long as the stream is not malformed, and the h/W is supporting the indicated profile(check with apis in gstvaapidisplay.h and gstvaapiprofile.h), we should be able to decode it. And in that case, make sure that vc1parser is not dropping any packets with out pushing to the decoder , and provide all parsing + decoding fix in gstremaer-vaapi. Adding typefinder and all are not the high priority item, but would be good if you can (may be later).

Created attachment 295797 [details] [review]
vaapidecode: intersect caps with the queried ones

This patch parse the caps from the query and in the ones that vaapidecode
handles and the ones that the query requests can intersect, the result of the
intersect is truncated and fixated.

The purpose of this patch is to enable the rendering of vc1 videos without the
need of a parser, for example:

gst-launch-1.0 filesrc location=sample.vc1 ! video/x-wmv ! vaapidecode ! vaapisink

Though, I think the correct fix should go to vc1parse

(In reply to comment #10)
> Created an attachment (id=295797) [details] [review]
> vaapidecode: intersect caps with the queried ones
> 
> This patch parse the caps from the query and in the ones that vaapidecode
> handles and the ones that the query requests can intersect, the result of the
> intersect is truncated and fixated.
> 
> The purpose of this patch is to enable the rendering of vc1 videos without the
> need of a parser, for example:
> 
> gst-launch-1.0 filesrc location=sample.vc1 ! video/x-wmv ! vaapidecode !
> vaapisink

Does this patch make the mentioned sample(SA00079.vc1 ) playable?
Not for me at least. But many others become playable now.
Fixating the caps might not be the right way I think, it may affect other pipelines too. But of course, it is handy for testing..

> Does this patch make the mentioned sample(SA00079.vc1 ) playable?

Nope. That's other bug, IMO.

> Not for me at least. But many others become playable now.

Yes :)

> Fixating the caps might not be the right way I think, it may affect other
> pipelines too. But of course, it is handy for testing..

I agree.

Though, this patch seems to fix this other bug:

https://bugzilla.gnome.org/show_bug.cgi?id=743687

Created attachment 295805 [details] [review]
vaapidecode: ignore VC1 user BDU's

Don't return error if the processed BDU is either a field or a frame one, just
ignore them.

(In reply to comment #14)
> Created an attachment (id=295805) [details] [review]
> vaapidecode: ignore VC1 user BDU's
> 
> Don't return error if the processed BDU is either a field or a frame one, just
> ignore them.

How about the user data in other layers? (sequence, entrypoint and slice)

Created attachment 295812 [details] [review]
vaapidecode: ignore VC1 user BDU's

Don't return error if the processed BDU is a user one, just ignore them.

Review of attachment 295797 [details] [review]:

I am bit reluctant to push this for now..Would be good to fix it in vc1parser instead.

(In reply to comment #17)
> Review of attachment 295797 [details] [review]:
> 
> I am bit reluctant to push this for now..Would be good to fix it in vc1parser
> instead.

D'accord.

What about the user BDU's patch?

(In reply to comment #18)
> (In reply to comment #17)
> > Review of attachment 295797 [details] [review] [details]:
> > 
> > I am bit reluctant to push this for now..Would be good to fix it in vc1parser
> > instead.
> 
> D'accord.
> 
> What about the user BDU's patch?

That should be fine :),,thanks...

*** Bug 719753 has been marked as a duplicate of this bug. ***

Pushed, thanks for the patch.
commit 481d6b1f250e8471b60eeb2a219867c7a3a978fe
Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Date:   Wed Feb 18 11:20:42 2015 +0200

    VC1: decoder: Ignore VC1 user BDU's
    
    Don't return error if the processed BDU is a user one, just ignore them.
    https://bugzilla.gnome.org/show_bug.cgi?id=741237
    
    Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

To make the elementary stream playable, we need the fix in vc1parser as per https://bugzilla.gnome.org/show_bug.cgi?id=743948.

May you can provide a separate vc1parser to QA for testing(source and a Makefile). WDT?

(In reply to zhixinx.liu from comment #0)
> GStreamer encountered a general stream error  when doing VC1 decoding
> 
> 1. Testing Steps:
> ========================================================================
> 1.run command:
> gst-launch-1.0 filesrc
> location=/root/media_tools/decoder/bitstreams_vc1/SA00079.vc1 ! vc1parse !
> vaapidecode ! vaapisink sync=false
> 
> 2.Log:
> ========================================================================
> [root@x-bswmedia ~]# GST_DEBUG=vaapi:4 gst-launch-1.0 filesrc
> location=/root/media_tools/decoder/bitstreams_vc1/SA00079.vc1 ! vc1parse !
>

HI Zhixinx,
This is an issue in upstream parser which is tracking in multiple other bug reports(#668565, #743948). But those fixes are not going to land in 1.4.x or 1.2.x most probably.

So for vc1 elementary stream testing, I would request you to use CMD like this
 gst-launch-1.0 filesrc location= SA00079.vc1 ! "video/x-wmv, profile=(string)advanced" ! vaapidecode ! vaapisink

Please use the gstreamer-vaapi master branch for testing
(commit 7ca05917591b3477a7d68a1e5adc308737b9e3e0).

Also if you want to use the vc1parser element for testing instead of specifying the profile manually, you can use this separate parser from Victor.
https://github.com/ceyusa/gst-vc1parse

This has been verified by QA already.
Closing.