[vlc-devel] [RFC PATCH 01/13] clock: add vlc_clock

[Zhao Zhili]

On 2018年10月25日 22:34, Thomas Guillem wrote:
> On Thu, Oct 25, 2018, at 15:54, Thomas Guillem wrote:
>>
>> On Fri, Aug 31, 2018, at 14:36, Zhao Zhili wrote:
>>> On 8/31/18 5:59 PM, Denis Charmet wrote:
>>>> Hi,
>>>>
>>>> On 2018-08-29 11:10, Zhao Zhili wrote:
>>>>> On 2018年06月27日 20:41, Thomas Guillem wrote:
>>>>>> +static vlc_tick_t main_stream_to_system(vlc_clock_main_t * main_clock,
>>>>>> +                                       vlc_tick_t pts)
>>>>>> +{
>>>>>> +    if (unlikely(main_clock->offset == VLC_TS_INVALID))
>>>>>> +        return VLC_TS_INVALID;
>>>>>> +    return (vlc_tick_t) (pts * main_clock->coeff / main_clock->rate
>>>>>> + main_clock->offset);
>>>>>> +}
>>>>> I'm afraid int64_t to float to int64_t won't work well as float can
>>>>> only represent a small integer precisely.
>>>>> main_clock->offset makes it worse since it isn't uncommon to be a
>>>>> large value.
>>>>>
>>>>> (vlc_tick_t)(pts * main_clock->coeff / main_clock->rate) +
>>>>> main_clock->offset
>>>>>
>>>>> may be a little better, but the problem is still there.
>>>>>
>>>> Thanks for the review, it's indeed a very interesting point. It seems
>>>> that switching to double might help a lot with that. Any other suggestions?
>>>>
>>>> Regards,
>>> double should give milliseconds precision at the worst case, but I'm not
>>> sure.
>> Your test confirms that a double will be OK.
>>
>>> I think the math in AvgRescale is incorrect, in both the master branch
>>> and the clock-core branch. I have a patch for it
>>>
>>> clock: fix AvgRescale
>>>
>>> It doesn't make sense in mathematics, but it may have a special meaning
>>> I missed. And the function is not used in the clock-core branch, so it
>>> doesn't matter anymore if it's finally being removed.
>> It will and still be used by the input clock, even in the clock-core
>> branch.
>> We'll rework and probably the input clock for VLC 5.0 when we rework the
>> buffering.
>>
>> So, I'll probably merge your AvgRescale fix in our clock branch.
> Ah no, this patch is not relevant on the clock-branch.
>
> One question, I must use double in clock internal calculs, OK. But should we use double in clock external API too ? That will mean that vout/aout/input/player rate will be a double too.

I found an example, hold rate in float variable and cast to double when 
necessary

floatmPlaybackRate;

int64_t nowMediaUs =
         anchorTimeMediaUs + (nowUs - anchorTimeRealUs) * 
(double)mPlaybackRate;

https://android.googlesource.com/platform/frameworks/av/+/master/media/libstagefright/include/media/stagefright/MediaClock.h#110
https://android.googlesource.com/platform/frameworks/av/+/master/media/libstagefright/MediaClock.cpp#101

>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel