[FFmpeg-cvslog] h264dec: Dont display trash before a keyframe.

[Michael Niedermayer]

On Sun, Sep 18, 2011 at 01:47:18PM -0700, John Stebbins wrote:
> 
> On 09/17/2011 10:17 PM, Michael Niedermayer wrote:
> > On Sat, Sep 17, 2011 at 10:14:47PM -0700, John Stebbins wrote:
> >> On 09/17/2011 09:53 PM, Michael Niedermayer wrote:
> >>> this looks odd, like if a () is missing over the +
> >>> also id use a & (x-1) instead of %x but thats just me
> >>>
> >>> [...]
> >>>
> >> oops!  You are correct.  I just created this patch today and am still
> >> testing it.  Good eyes.
> > 
> > tell me once you are done with testing so i can commit+push it
> > 
> > [...]
> 
> Here's a patch that's been tested better this time.

applied & pushed & thanks


> 
> I have a couple samples that exorcise this code pretty well.  One is an h.264 stream that has recovery points with
> recovery_frame_cnt = 0 flagged at B-frames.  Since there is frame re-ordering done, the initial frames output by the
> decoder would be incomplete because the flagged B-frame hasn't reached the output yet.  This stream plays back only
> clean frames due to mn's previous patch.
> 
> The other stream I generated with x264 using intra-refresh.  This stream has only a single IDR at the beginning and
> recovery points with non-zero recovery_frame_cnt throughout the rest.  This stream shows junk when played with mn's
> patch.  Adding my patch cleans this up.
> 
> There is still one remaining issue.  When seeking through such streams, you may hit a recovery point on a slice that
> references a frame that is not available.  ffmpeg errors out on such frames and you get some garbage displayed. The spec
> says these should be treated like this:
> 
> "When decoding starts from the location of the recovery point SEI message, all references to not available reference
> pictures shall be inferred as references to pictures containing only macroblocks coded using Intra macroblock prediction
> modes and having sample values given by Y samples equal to 128, Cb samples equal to 128, and Cr samples equal to
> 128 (mid-level grey)"
>

> I tried to upload my PIR sample to upload.ffmpeg.org, but I get connection refused.  Perhaps a firewall problem?  I'll
> try from home later.

please upload to our trac bugtracker if the file is small enough



[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20110918/2c435ed9/attachment.asc>