v0.9.7-p1 Problems with control of a stream and gold shots

[GoogleCodeExporter]

The bug in v0.9.7-p1 is found. 2 passes. If video very dark and long enough is 
more than 100000 shots in the end of video there can be a failure of exhibiting 
of gold shots (gold shots aren't exposed), the similar problem is in VP7 on 
some modes, it is connected with wrong distribution of a stream as soon as the 
codec understands that the stream doesn't suffice - it ceases to expose gold 
shots.

Original issue reported on code.google.com by [email protected] on 3 Nov 2011 at 8:39

[GoogleCodeExporter]

Original comment by [email protected] on 3 Nov 2011 at 8:40

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

* 70000 shots

Original comment by [email protected] on 3 Nov 2011 at 8:41

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Obviously that exhibiting of gold shots should be separated from a stream and 
to make dependent only from quality of intermediate shots and a coded scene.

Original comment by [email protected] on 3 Nov 2011 at 8:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Can you provide a sample stream to show the problem? 

Original comment by [email protected] on 8 Nov 2011 at 12:28

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

http://narod.ru/disk/31181568001/%D0%9A%D0%BE%D0%BF%D0%B8%D1%8F%20VTS_01_1-VP8-2
84.avi.html

After 55000 thousand frames approximately

Original comment by [email protected] on 10 Nov 2011 at 10:44

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I converted the file and processed the decoding through vpxdec. Checking on the 
decoded output seems to be correct without obvious problem. 

I suspect the bitstream, vp8 encoder and decoder, are fine in this case. 
Problem may exist outside the codec, for example, in the player, and so on. 

Original comment by [email protected] on 29 Dec 2011 at 7:32

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

If all is fine, why there are no gold shots in the end?

I and without decoding can tell in what business - in the first pass the coder 
considers one bit rate, and in the second pass bit rate above and the coder 
starts to save on gold shots, and then them absolutely disconnects.

P.S. Open Source such Open Source - for a place of a solution of a problem you 
start to mill the wind if only to prove that you are right also nothing to 
change.

Original comment by [email protected] on 4 Jan 2012 at 12:26

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Sorry that I mis-understood your issue at first, and was investigating 
something different. Earlier, I took your description as that you were seeing 
playback of "gold-shots" that were not supposed to show, i.e. a bit stream 
format bug where a frame with "not shown" flag is being decoded and played back 
on the decoder side.  

Now I understood that the problem you describe as: you expect the encoder to 
place golden reference frames at a later section of a video clip in a similar 
fashion as it does in the earlier section of the same clip, but there is not 
any golden frame placed by the encoder at later sections of a file being 
encoded. Is this the correct description of the problem? 

Original comment by [email protected] on 4 Jan 2012 at 4:11

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Original comment by [email protected] on 4 Jan 2012 at 8:34

• Changed state: NeedMoreInfo
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Yes, starting with about identical quality swore at the coder should expose 
gold shots approximately equally both in the beginning and in the end of video, 
considering that I observed exactly same problem in VP7 for a long time, I have 
understood at once in what business - an error bit rate.

It is an obvious bug of the coder - if it doesn't get in bit rate that should 
reduce proportionally quality and gold shots and intermediate, instead of 
disconnect the gold shots.

Original comment by [email protected] on 5 Jan 2012 at 10:17

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

P.S. But is better the coder would change nothing - was mistaken so was 
mistaken. The coder should expose in advance quantizer in in the second pass 
starting with bit rate and further to change nothing. It is the most optimum 
variant.

Original comment by [email protected] on 6 Jan 2012 at 7:56

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I agree with the few possible fixes to the issue suggested in previous message: 
1) reduce rate target proportionally on all frame types for the section, rather 
than disabling golden/altref. 
2) better prediction of quantizer selection from 1st pass to avoid the issue to 
appear in the first place. 
3) let the rate overshooting if the magnitude of overshooting is very small. 
etc. 

Original comment by [email protected] on 9 Jan 2012 at 7:49

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Original comment by [email protected] on 1 Mar 2012 at 7:04

• Changed state: Available
• Added labels: Mstone-14
• Removed labels: ****