GNOME Bugzilla – Bug 519878
[basesink] Superfluous critical warning on segment format mismatches.
Last modified: 2011-07-04 12:05:50 UTC
[hm, bit long story for a short item ...] Consider (a.o.) a fragment as follows ... ! muxer ! filesink muxer will presumably send buffers that may or may not have valid timestamps (buffers with media content versus some container format buffers). At EOS time, it will likely send a BYTE based NEW_SEGMENT to have filesink perform seeking, which may be the first NEW_SEGMENT to arrive there (e.g. avimux). This triggers a set_new_segment_full, which then g_return_if_fail because the basesink's segment is then already set to TIME format (strangely enough). The latter behaviour has been introduced in response to bug 494245, by forcing the running/stream time calculations to occur in TIME format. Both gst_segment_to_stream_time/running_time have the side-effect to change the segment's format to the given (TIME) one, if it is presently UNDEFINED and the input timestamp is valid. So, the segment gets into TIME format (with no real added value) along the way, and complains later on about the received BYTE segment.
Created attachment 106377 [details] [review] Possible patch. * If gst_base_sink_get_sync_times decides no do_sync, do not bother to calculate times (with possible side-effects). In particular, (a.o.) filesink NULL'ifies get_times; does not want to sync. Of course, these lines (or variations thereof) could be shifted around a bit. There may be other approaches altogether, such as fixing (several?) other elements, e.g. assuring a BYTE based segment gets sent first (which may be what the critical warning is meant to point out in the first place :) ). Anyway, these few lines (or alike) seem to make sense.
This is unfortunate. We can't sync on the clock for muxers that operate in byte formats (we could have if the seek would have happened with a seek event in bytes). Of course the muxer should send a bytes segment first before pushing buffers. It should do this only when it wants to perform a seek later on. This also tiggers the fact that any following element won't be able to sync, which is ok since this would usually be done for sending the data over a network (like UDP), which is pointless for formats that modify the header at the end. I'm tempted to even always skip the sync code if the format is not TIME.
Created attachment 106473 [details] [review] possible patch This patch disables all segment operations such as clipping and sync when the sink element received a bytes newsegment.
Created attachment 110874 [details] [review] Fix avimux generated segment format warning As mentioned above, muxer should sent BYTE segment first if it expects to do seeking later on. This makes avimux do so.
what's up with this?
Hey guys, This bug has been set to NEEDINFO for quite some time now. Any chance that we can resolve this one soonish?
I guess Wim's patch can be committed now... Wim? Otherwise lets close this bug if there's nothing to fix here.
I think this is going to break some stuff
Well. Can the reported issue be identified as a bug worth fixing? If so, we should consider setting this to NEW. If not, let's close this one.
Reopening as I can't see any open non developer question.
Ok, so what now? Can we get Wim's patch in 0.11 at least?
AFAICS, the original report should not occur anymore now; * either since muxers probably take care to send some intial BYTE newsegment. * basesink code should not trigger format problems if one does not