When we start and renegotiate, there is a moment where the stream is created but
not yet connected. Make sure all functions deal with this situation correctly
instead of erroring out.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=681247
When get_time is called but we are not yet negotiated, return 0 instead of
posting an error. It's possible that the base class is still negotiating when
our get_time is called.
This makes sure that we:
a) Destroy an existing stream if a negotiate() request comes in: this is
required when receiving a downstream renegotiation request after a
stream has been created.
b) Create a new stream on prepare(): this is required since we do a
setcaps() in negotiate(), which causes the stream to be dropped by a
ringbuffer release() call (this does not happen during first negotiation
since the release is only done on a running ringbuffer). The subsequent
call to ringbuffer acquire() fails because the stream was lost on
release().
https://bugzilla.gnome.org/show_bug.cgi?id=681247
If converting a PA channel map to gst channel positions results in a
valid set of channel positions, we clear the unpositioned flag from the
ringbuffer spec.
This itereates over the GstAudioInfo to set invalid channel positions
rather than use memset() which works right now because it assumes that
GST_AUDIO_CHANNEL_POSITION_INVALID is -1.
Not sure why it as disabled exactly given that it had already
been ported (though without metas or baseclass).
Move plugin_init bits into separate source file, and rename
decoder element to gdkpixbufdec.
Post the notify outside of the pa_lock to avoid a deadlock caused by basesrc
calling get_time with the object lock.
Reset the clock on connect.
Post clock-lost and clock-provide messages.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=673977
Conflicts:
ext/pulse/pulsesrc.c
Leave it to the application to decide on the header. No header at all
is better than having the wrong header as DLNA mandates that a missing
header has to be tolerated while a wrong header is an error.
https://bugzilla.gnome.org/show_bug.cgi?id=676020
Consider a downstream element that may issue seeks in very short
succession (e.g. queue2), depending on the access pattern of
the downstream element (e.g. qtdemux with audio/video chunks
interleaved so that there's always a sizeable gap between the
current chunks for each stream). In this case, queue2 will maintain
two ranges, and even when it serves a chunk from memory, it will
switch ranges and make souphttpsrc seek to the end of the available
data for that range, assuming that that's where we'll want to
continue reading from next.
This may lead to the following seek request pattern:
- source reading position A
- seek to B
- now reading position still A, requested_postion is B
- streaming thread to be restarted to continue from B
- seek to A, before streaming thread had time to do the seek
- do_seek() now sees reading position == seek position and
returns early.
- however, requested position is still B from the earlier
seek request
- streaming thread starts up, sees that a seek to B is pending
and requests data from B from the server, while the GstBaseSrc
segment has of course been updated/reset to position A, which
was the last seek request.
- we will now send data for position B and pretend that's the
data from position A (via the newsegment event, etc.)
- this causes data corruption
Reproducible doing seek-emulated fast-forward/backward on 006648.
This never really took off and is most likely completely
unused. If there is still a need for this, it should
probably be done differently, perhaps inside oggdemux/mux.
Downstream likely won't accept video/x-raw and the caps query
will return EMPTY caps. Instead, create a copy of the caps that
has all structure names replaced by 'image/jpeg'
Simple pipeline that shows the problem:
gst-launch-1.0 videotestsrc num-buffers=1 ! "video/x-raw, \
width=(int)640, height=(int)480" ! videoscale ! jpegenc ! \
"image/jpeg, width=(int)800, height=(int)600" ! filesink \
location=/tmp/image.jpg
When we explicitely set the mute property to FALSE, connect to pulseaudio with
the PA_STREAM_START_UNMUTED flag set, otherwise pulseaudio will use its
previously used value (which might start the stream muted).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=672401
