VP8 decoder filter stops the stream on one bad frame

[GoogleCodeExporter]

It would be nice if the VP8 decoder filter was a little more resilient in the 
face of errors in the stream. Currently, if it can't decode a frame, the 
function Inpin::Receive in Vp8DecoderInPin.cpp returns S_FALSE and sets the 
m_bEndOfStream flag to true, so that all future calls to that function will 
fail. This seems a bit of overkill for one bad frame, especially if we are 
dealing with live streaming.

What steps will reproduce the problem?

I'm not sure if this happens with all errors, but one easy way to reproduce it 
is to start the stream on a non-IFrame. If the first frame is not an IFrame, 
the decoder just gives up. It would be nice if it waited until the next IFrame 
came along.

What is the expected output? What do you see instead?

Well, clearly if we're streaming live we don't want to just stop. Perhaps keep 
displaying a still-frame of the last successfully decoded frame until the next 
IFrame shows up.

Original issue reported on code.google.com by eddie.su...@gmail.com on 1 Jun 2011 at 6:37

[GoogleCodeExporter]

Original comment by iss...@webmproject.org on 1 Jun 2011 at 6:40

[GoogleCodeExporter]

Original comment by slavarn...@google.com on 2 Jun 2011 at 1:45

[GoogleCodeExporter]

Under what circumstances would a VP8 stream have a "bad" frame?

Original comment by matthewj...@google.com on 2 Jun 2011 at 5:22

• Changed state: NeedMoreInfo

[GoogleCodeExporter]

As I mentioned, you can start the stream on a non-IFrame. This causes the 
filter to stop. Also, due to network issues, you can drop one or more frames, 
or the data might actually get corrupted.

Original comment by eddie.su...@gmail.com on 8 Jun 2011 at 11:42

[GoogleCodeExporter]

We need more information in this issues, please update them. Otherwise they 
will be closed in the next week or so.

thanks 

Original comment by albe...@google.com on 16 Feb 2012 at 9:22

[GoogleCodeExporter]

What additional information would you like? I think the problem is spelled out 
pretty clearly in the bug description. If there is something I can clarify, 
please let me know specifically what.

Original comment by eddie.su...@gmail.com on 16 Feb 2012 at 9:25

[GoogleCodeExporter]

We can probably liberalize how errors are handled.  If the decode library call 
fails, we can probably just push something downstream, even if it's just a 
black frame or a green frame.

Original comment by matthewj...@google.com on 16 Feb 2012 at 10:44

• Changed state: Available
• Added labels: Component-DirectShow, Priority-Low, Type-Enhancement

[GoogleCodeExporter]

Change was checked in as of 2013/10/29:

https://gerrit.chromium.org/gerrit/gitweb?p=webm/webmdshow.git;a=commit;h=08a4a9
1ca9650b5b58008fac521f59eb518d929f

Original comment by matthewj...@google.com on 29 Oct 2013 at 10:16

• Changed state: Fixed