[vlc-devel] [PATCH] Inproved buffering accuracy and no rebuffering on ignored

[David Robison]

An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20131003/83d5d98f/attachment.html>
-------------- next part --------------
Unfortunately not. The testing was done with a hardware tool called a minimaxwell. This sits between the camera and the network and allows the tester to add network impairment such as jitter, delay, drops, and losses.

Sent from my Verizon Wireless 4G LTE DROID

Sergio Ammirata <sergio at ammirata.net> wrote:

David,

Can you share your testing code/app?

I am interested in seeing under which edge conditions will it actually
affect the video and/or increase the buffer size.

Sergio

On 10/3/13 7:41 AM, "David R Robison" <drrobison at openroadsconsulting.com>
wrote:

>Any thoughts on this? David
>
>David R Robison
>Open Roads Consulting, Inc.
>103 Watson Road, Chesapeake, VA 23320
>phone: (757) 546-3401
>e-mail: drrobison at openroadsconsulting.com
>web: http://openroadsconsulting.com
>blog: http://therobe.blogspot.com
>book: 
>http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526
>
>On 10/1/2013 10:40 AM, David Robison wrote:
>> To test this change, I used a MiniMaxwell which allows me to introduce
>>jitter, delay, and packet re-ordering in the video stream. I ran for
>>over 12 hours with no effect on the video and no increase in buffer
>>size. I'm reattaching the final patch here. I've made 2 basic changes to
>>the buffering strategy:
>>
>> 1) I now check to see if I and done buffering on both the
>>ES_OUT_SET_PCR and ES_OUT_SET_GROUP_PCR calls. This causes the buffered
>>amount to be checked more frequently and prevents over buffering which I
>>have seen in some instances
>> 2) When ignoring the jitter, I do not flush the buffer and rebuffer,
>>since I am not increasing the buffer size anyway. Instead I just reset
>>the PCR and continue on.
>>
>> Here is the final patch, Any comments?
>> David
>>
>> diff --git a/src/input/es_out.c b/src/input/es_out.c
>> index 68acf5e..c2431ba 100644
>> --- a/src/input/es_out.c
>> +++ b/src/input/es_out.c
>> @@ -2309,14 +2309,14 @@ static int EsOutControlLocked( es_out_t *out,
>>int i_query, va_list args )
>>                               EsOutIsExtraBufferingAllowed( out ),
>>                               i_pcr, mdate() );
>>   
>> -        if( p_pgrm == p_sys->p_pgrm )
>> +        if( p_sys->b_buffering )
>>           {
>> -            if( p_sys->b_buffering )
>> -            {
>> -                /* Check buffering state on master clock update */
>> -                EsOutDecodersStopBuffering( out, false );
>> -            }
>> -            else if( b_late && ( !p_sys->p_input->p->p_sout ||
>> +            /* Check buffering state on master clock update */
>> +            EsOutDecodersStopBuffering( out, false );
>> +        }
>> +        else if( p_pgrm == p_sys->p_pgrm )
>> +        {
>> +            if( b_late && ( !p_sys->p_input->p->p_sout ||
>>                 
>>!p_sys->p_input->p->b_out_pace_control ) )
>>               {
>>                   const mtime_t i_pts_delay_base = p_sys->i_pts_delay -
>>p_sys->i_pts_jitter;
>> @@ -2330,19 +2330,23 @@ static int EsOutControlLocked( es_out_t *out,
>>int i_query, va_list args )
>>                                "ES_OUT_SET_(GROUP_)PCR  is called too
>>late (jitter of %d ms ignored)",
>>                                (int)(i_pts_delay - i_pts_delay_base) /
>>1000 );
>>                       i_pts_delay = p_sys->i_pts_delay;
>> +
>> +                    /* reset clock */
>> +                    for( int i = 0; i < p_sys->i_pgrm; i++ )
>> +                      input_clock_Reset( p_sys->pgrm[i]->p_clock );
>>                   }
>>                   else
>>                   {
>>                       msg_Err( p_sys->p_input,
>>                                "ES_OUT_SET_(GROUP_)PCR  is called too
>>late (pts_delay increased to %d ms)",
>>                                (int)(i_pts_delay/1000) );
>> -                }
>>   
>> -                /* Force a rebufferization when we are too late */
>> +                    /* Force a rebufferization when we are too late */
>>   
>> -                /* It is not really good, as we throw away already
>>buffered data
>> -                 * TODO have a mean to correctly reenter bufferization
>>*/
>> -                es_out_Control( out, ES_OUT_RESET_PCR );
>> +                    /* It is not really good, as we throw away already
>>buffered data
>> +                     * TODO have a mean to correctly reenter
>>bufferization */
>> +                    es_out_Control( out, ES_OUT_RESET_PCR );
>> +                }
>>   
>>                   es_out_SetJitter( out, i_pts_delay_base, i_pts_delay
>>- i_pts_delay_base, p_sys->i_cr_average );
>>               }
>> -- 
>> 1.7.9.5
>>
>>    _____
>> From: Rémi Denis-Courmont [mailto:remi at remlab.net]
>> To: Mailing list for VLC media player developers
>>[mailto:vlc-devel at videolan.org]
>> Sent: Thu, 26 Sep 2013 10:03:03 -0400
>> Subject: Re: [vlc-devel] [PATCH] Do not rebuffer if not increasing
>>buffer	size
>>
>> Is there any easy way to test it?
>>
>
>
>
>This email communication (including any attachments) may contain
>confidential and/or privileged material intended solely for the
>individual or entity to which it is addressed.
>If you are not the intended recipient, please delete this email
>immediately.
>
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel


_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc-devel



This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed.
If you are not the intended recipient, please delete this email immediately.