[vlc-devel] [PATCH v1 1/3] decoder: Always show forced pictures, even during preroll

[Michael Tänzer]

Hi,

is there still some doubt about this fix? If so what are your concerns?
This fix is essential for seeking in OggSpots to work properly.
Otherwise there will not be an image after the seek until for example
the slide changes.

Best Regards
Michael


On 07.03.2016 18:01, Michael Tänzer wrote:
> When b_force is set on a picture it is shown until a new picture gets
> decoded which apparently is used at the end of an MPEG2 stream and the
> stats module to keep the picture displayed even if no more blocks
> arrive. Since the OggSpots codec is a variable frame rate codec it also
> needs to display the picture until it decodes a new block, possibly
> skipping some cycles of the base frame rate. So it uses
> picture_t.b_force to achieve that.
> 
> During pre-roll blocks are decoded but not displayed because for fixed
> frame rate codecs the first picture after the preroll will be the one we
> want to see. If however there was a b_force picture during pre-roll and
> no new pictures since, that forced picture would also not be displayed
> at seek time. This behaviour differs from the behaviour from a normal
> play through where, at the same position in time, the picture would
> still be displayed.
> 
> That issue probably doesn't cause any major problems for the existing
> codecs that use b_force, but for a variable frame rate codec like
> OggSpots it would mean there will be no picture after seeking for quite
> some time, because it is very likely that there will be no block at the
> exact time we skipped to. So somehow the last decoded block from the
> pre-roll needs to be displayed when the pre-roll ends, but there is no
> block in the data stream to trigger the decoding. So I decided to fix
> that issue in the pre-roll code rather than introducing a new mechanism
> like a hook to trigger the codec when the seek time is reached to allow
> it to display the last picture. As most codecs don't use b_force at all
> and the ones that do would either not be influenced by that change as
> they only use it at the stream end (MPEG2) or might even have the same
> issue (stats), the change would not have a negative impact on existing
> codecs.
> 
> 
> On 07.03.2016 14:30, Jean-Baptiste Kempf wrote:
>> I'm really un-ease with that patch.
>> If we are in pre-roll, why should we display anything?
>>
>> On 03 Mar, Michael Tänzer wrote :
>>> If a picture has b_force set it is expected to be shown until the next
>>> image is decoded. If we are in the preroll and don't show forced pictures
>>> there might not be a picture when the preroll is finished.
>>> ---
>>>  src/input/decoder.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/input/decoder.c b/src/input/decoder.c
>>> index a1d7414..b66c885 100644
>>> --- a/src/input/decoder.c
>>> +++ b/src/input/decoder.c
>>> @@ -835,7 +835,7 @@ static int DecoderPlayVideo( decoder_t *p_dec, picture_t *p_picture,
>>>      bool prerolled;
>>>  
>>>      vlc_mutex_lock( &p_owner->lock );
>>> -    if( p_owner->i_preroll_end > p_picture->date )
>>> +    if( !p_picture->b_force && p_owner->i_preroll_end > p_picture->date )
>>>      {
>>>          vlc_mutex_unlock( &p_owner->lock );
>>>          picture_Release( p_picture );
>>> -- 
>>> 2.5.0
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160317/7f7796a4/attachment.sig>