[vlc-devel] [vlc-commits] input: fix pf_demux test again

Steve Lhomme robux4 at gmail.com
Wed Jun 22 18:29:49 CEST 2016


On Wed, Jun 22, 2016 at 4:53 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2016-06-22 11:09, Steve Lhomme a écrit :
>>
>> On Sat, Jun 18, 2016 at 2:27 PM, Rémi Denis-Courmont
>> <git at videolan.org> wrote:
>>>
>>> vlc | branch: master | Rémi Denis-Courmont <remi at remlab.net> | Sat Jun 18
>>> 13:34:08 2016 +0300| [937150bc0f765d1d30e28bf0a19efa5eab344030] | committer:
>>> Rémi Denis-Courmont
>>>
>>> input: fix pf_demux test again
>>>
>>>>
>>>>
>>>> http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=937150bc0f765d1d30e28bf0a19efa5eab344030
>>>
>>> ---
>>>
>>>  src/input/input.c |    2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/src/input/input.c b/src/input/input.c
>>> index 50d603e..c5d0162 100644
>>> --- a/src/input/input.c
>>> +++ b/src/input/input.c
>>> @@ -682,8 +682,6 @@ static void MainLoop( input_thread_t *p_input, bool
>>> b_interactive )
>>>                               var_InheritBool( p_input, "play-and-pause"
>>> );
>>>
>>>      demux_t *p_demux = p_input->p->master->p_demux;
>>> -    while (p_demux->p_next)
>>> -        p_demux = p_demux->p_next;
>>>      const bool b_can_demux = p_demux->pf_demux != NULL;
>>
>>
>> I understand that p_next is supposed to be private. But at this level,
>> how are we supposed to know if the real demuxer has a pf_demux or not
>> ?
>
>
> And why do we care about the real demuxer? The question is whether
> demux_Demux() is or is not a stub. This is about the last element in the
> chain, not the first.

Yes, the old code was using what is now the last element in the chain,
which is not p_input->p->master->p_demux.

If you insert a dummy demux filter (a dumb pass through for pf_demux
and pf_control), b_can_demux becomes incorrect for (real/old) demuxers
where pf_demux is NULL (some live capture access filters but not all).
The result is that MainLoopDemux() is called more often even when no
control query is received. Because the wakeup/deadline algorithm is
triggered where it used to not be triggered. Is that OK ?

> (By the way, calling the previous demux/demux filter is as confusing and
> silly as it gets, but that's not the worst of problems with the
> demux-filter.)
>
>> Since earlier we test p_input->p->b_can_pace_control and
>> p_input->p_demux->pf_demux as mutually exclusive, wouldn't it make
>> more sense to check for b_can_pace_control for the wakeup time anyway
>> ?
>
>
> I don't know if it would make sense. But mutual exclusivity is not to be
> confused with (logical) opposition.
>
> Mutually exclusive is: (not A) or (not B)
> Compare: (A and (not B)) or ((not A) and B)
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list