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

[Michael Niedermayer]

On Sat, Sep 17, 2011 at 08:59:09PM -0700, John Stebbins wrote:
[...]
> >> There are many simple and more useful ways of solving this, I suggested several like adding an error flag to the context or to AVFrame but nobody showed real interest, instead it's such a "oh, let's break it for the _other_ half of users I instead" solution :-(
> > 
> > Better solution is welcome, but default should be no trash because
> > this is what a non geek user would expect. And it is what any kind
> > of professional would require. Also think of editing
> > 
> > [...]
> > 
> > 
> 
> Since I'm not a regular around here, my opinion probably doesn't count
> for much, but I mildly disagree with this as well :p. I do agree that

Everyones oppinon counts.


> this this is something that belongs at application level (or as an
> option that can be disabled).  We do this in HandBrake for instance. And
> I've implemented set-top box based players that required the opposite
> behaviour (so that channel changes "appeared" to be faster).

Its not easy to implement this fully correctly for all codecs
at application level.
Ill add an option to disable this tomorrow.
Does this resolve your concerns ?
And other comments & sugggestions are welcome of course!


> 
> On a related note, this patch alone will not eliminate all cases of
> garbage at the beginning when the first "keyframe" is a recovery point.

I know that, thats one reason why i asked for samples where it doesnt
work


> As implemented, ffmpeg flags the frame where the recovery point is
> initially seen as a keyframe.  But a fully reconstructed frame will not
> exist till frame_num == h->frame_num + h->sei_recovery_frame_cnt % (1 <<
> h->sps.log2_max_frame_num).  Here's a patch for this if it interests you.
> 
> -- 
> John      GnuPG fingerprint: CADFA1DB594CA50EB79427284617578AADE759A1

>  h264.c     |   14 ++++++++++++--
>  h264.h     |    7 +++++++
>  h264_sei.c |    1 +
>  3 files changed, 20 insertions(+), 2 deletions(-)
> 130a6ceb93f7f6967ac300899c9bc2a0dad33e31  ffmpeg.recovery-point.diff
> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> index 33f70fe..a49bb17 100644
> --- a/libavcodec/h264.c
> +++ b/libavcodec/h264.c
> @@ -3709,9 +3709,19 @@ static int decode_nal_units(H264Context *h, const uint8_t *buf, int buf_size){
>              if((err = decode_slice_header(hx, h)))
>                 break;
>  
> +            if (h->sei_recovery_frame_cnt >= 0) {
> +                h->recovery_frame = h->frame_num + h->sei_recovery_frame_cnt %
> +                                    (1 << h->sps.log2_max_frame_num);

this looks odd, like if a () is missing over the +
also id use a & (x-1) instead of %x but thats just me

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- 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/5430c794/attachment.asc>