[gstreamer-bugs] [Bug 633700] [streamsynchronizer] regression: hang when pausing near EOS

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sat Nov 13 10:12:45 PST 2010


https://bugzilla.gnome.org/show_bug.cgi?id=633700
  GStreamer | gst-plugins-base | unspecified

--- Comment #10 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2010-11-13 18:12:39 UTC ---
(In reply to comment #9)
> Not really sure what to do about this. We need to make a decision though, so we
> can get on with the release.
> 
> It's clearly bad that it's possible to seek somewhere with playbin2 without
> being able to get back into playing state afterwards.

And would also occur if one simply tries to pause/play at that time
(or whenever software decides to do so behind the screen, e.g. to temporarily
pause playback to show "media details" info or whatever).

> 
> However, I'm wondering how much of a problem this actually poses in practice.
> How many files have video and audio streams with considerably different
> lengths?

It seems grasping at straws ;) to classify 2s difference (as illustrated by
attached example) in audio/video as considerably different (compared to quite
possibly many tens of minutes of clip length) [and the 2s can in fact be a lot
less for it to still happen].  Seems like a possible thin end of a wedge if we
try to discard "by practical impact" ... (especially on regression of basic
case/playback in favor of new/rare? feature).

> 
> It does pose a problem for people who want to extract the very last frame of a
> file I guess, but how common/useful is that? (I know I've seen this come up on
> the list a couple of times) (And do those people use playbin2?)
> 
> Thanks for coming up with those patches, Mark! It seems though that people are
> not too keen on this approach, which adds new API/concepts, but would prefer a
> different solution.
> 

Hmmmm.  Any particular arguments what might go/be wrong with this approach? (as
even tons of new API/events/messages have not stopped things before).
But anyway, as long as "different solutions" get the job done (and while at it
also help to handle some "preroll hell" as indicated earlier).

> That poses the question what to do for the release.
> 
> There don't seem to be alternative patches / approaches that are less intrusive
> and/or risky.
> 
> We could roll playbin2 back to the 0.10.30 version, but the fixes and additions
> since then seem worthwhile to have and probably outweigh this problem.
> 
> So maybe we should just release with this bug and get it fixed for the next
> release? Or is this issue more severe than I think it is?

I would consider it more severe then it apparently seems rated, but not
necessarily so that it needs to hold back release.  Then again, lifting it over
release might be viewed as a license to never bother again.

So, perhaps we should only release if and only if bug is either resolved or we
know how we plan to.  Releasing with bug as-is, and discarding a possible
solution in the process, with no more specific idea/notion than "other
solutions" on how to handle seems not The Way To Go.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list