[vlc-devel] [PATCH] Don't flag as preroll blocks with invalid pts and dts

[Laurent Aimar]

On Sat, Jan 14, 2012 at 08:22:55PM +0100, Denis Charmet wrote:
> This behaviour causes #5165 as when mkv has several audio frame in
> a lace only the first has a valid pts. The other frames have to have
> a VLC_TS_INVALID pts and dts and it's up to the decoder to extrapolate
> the real values.
> 
> Fix #5165.
> ---
>  src/input/es_out.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/src/input/es_out.c b/src/input/es_out.c
> index 89bff72..a2a21c7 100644
> --- a/src/input/es_out.c
> +++ b/src/input/es_out.c
> @@ -1952,7 +1952,7 @@ static int EsOutSend( es_out_t *out, es_out_id_t *es, block_t *p_block )
>          if( p_block->i_pts <= VLC_TS_INVALID )
>              i_date = p_block->i_dts;
>  
> -        if( i_date < p_sys->i_preroll_end )
> +        if( i_date > VLC_TS_INVALID && i_date < p_sys->i_preroll_end )
>              p_block->i_flags |= BLOCK_FLAG_PREROLL;
>      }

 This won't work as a lot of packets will not be marked as prerolled and so
basically making prerolling useless.
 The only side effects of marking packets without timestamp as 'prerolled'
should be that a bit too much of audio/video are trimmed (ie the part until
a valid timestamp is seen again).

For example: ('?' mean we don't have a dts/pts)
[packet 1] [packet ?] [packet 3] [packet ?] [packet 5] [packet ?] [packet 7]

For a preroll up to 7:
 - without the patch: perfect
 - with the patch: we don't preroll all the packets with '?' (ie 3 extra packets)

For a preroll up to 6:
 - without the patch: we preroll one packet too much
 - with the patch: we don't preroll all the packets with '?' (ie 3 extra packets)

So, I am not sure why #5165 would happens due to that. On the samples reproducing
the issue, what are the delay between 2 packets with timestamp?

-- 
fenrir