[Bug 751147] appsink pull_preroll returns wrong segment in the sample

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=751147

Thiago Sousa Santos <thiagossantos at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiagossantos at gmail.com

--- Comment #3 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to George Kiagiadakis from comment #2)
> Indeed, it does mean that the latest segment will be received in
> preroll_segment. However, the same is done with preroll_caps and the preroll
> buffer never becomes NULL until dispose(), so checking for preroll==NULL
> would be problematic at this point. I guess the whole logic could be
> improved for optimization, but it works.

I'd more think of it as 'works' as you can get the wrong segment. But I agree
this is an improvement anyway.

> 
> Initializing it in stop() doesn't sound like it has any advantage to me. A
> preroll can only happen in PAUSED state, so if stop() gets called (going to
> NULL), then start() will be called after that before a new preroll. The only
> potential problem is what happens if somebody calls "pull-preroll" when
> appsink is in the NULL state, but that is broken anyway with the current
> code regarding the preroll variables (buffer & caps). I would not consider
> fixing this as part of this patch.

The caps issue can be done as a separate patch/bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.