Replace solid-color property with foreground-color and add
background-color. Pull some common code out of each of the
pattern generating functions. Fix many of the patterns to
use foreground-color/background-color instead of white/black.
Generated images are indentical to previously if foreground-color
and background-color are left as default.
API: GstVideoTestSrc::foreground-color
API: GstVideoTestSrc::background-color
Send FLUSH_STOP right after forwarding the seek event upstream if necessary.
This makes sure that adder->srcpad is not left flushing if seeking fails or if
upstream is blocked.
The same fix was already applied to videomixer in 49b2a946.
This should speed up standard Vorbis encoding and decoding pipelines a bit.
Thanks to David Schleef for the assistance to get the ORC code right
and explaining everything.
We currently don't use the GAP flag for video and the docs say
that this is for buffers, that have been created to fill a gap
and contains neutral data. For video this is the previous frame.
This information can be used by encoders to encode the duplicated
frames more efficiently. See bug #627459.
That is, if eos is received which will not be forwarded, and the stream
has not yet seen any data, then send a buffer to preroll downstream
(which might otherwise be accomplished by the eos event).
Streamsynchronizer excepts to see stream-changed msg for all streams, but to
arrange for this, video and subtitle streams need to be decoupled by means
of queues (due to pad blocks that may occur).
Fixes#626463.
Specifically, as the latter may have one thread pushing EOS to several streams,
that needs to be decoupled into various thread to prevent preroll hanging
problems.
Otherwise we're producing different caps and basetransform thinks that it
can't passthrough buffer allocations, etc.
In 0.11 all video caps really should have the PAR set...
... which generalizes the current listing of white, black, etc.
In particular, also allow specifying alpha channel, and modify
some structures and pattern filling to cater for alpha value as well.
Fixes#624919.
API: GstVideoTestSrc:solid-color
This fixes a race condition in playbin2's gapless mode, where the
EOS of other streams might arrive in the sinks before the last stream
ends and the switch to the new track happens. The EOS sinks won't
accept any new data then and playback stops.
To prevent this, delay all EOS events until all streams are EOS
and advance the sinks of the EOS streams by filler newsegment
events if necessary.
Fixes bug #625118.
This reads the 3gp profile from the major/compatible brands and puts
this as a 'profile' field in caps. This can be used by demuxers to
decide whether they can handle this stream or not. Also needed for
DLNA.
https://bugzilla.gnome.org/show_bug.cgi?id=620291
Logic for choice of GST_PAD_LINK_CHECK_* is as follows:
* Where return of pad_link wasn't checked before : NOTHING
* Where linking is between known compatible elements : NOTHING
* All other cases : TEMPLATE_CAPS
Slashes down playsink reconfigure by up to 50% cpu time.
This makes sure that we always keep the display aspect ratio and
add black borders if necessary, which is usually something you want
for viewing a video.
This behaviour was not preferred and caused visible image quality
degradations. The real solution would be, to apply a real
deinterlacing filter before scaling the frames.
Fixes bug #615471.
We only look for packets with payload, but it appears there may be packets without,
which makes it harder to find the N packets with payload in a row that we need in
order to typefind this successfully, so scan some more data than necessary in the
optimistic scenario. Alternatively we could change IS_MPEGTS_HEADER().
Fixes#623663.
Before gapless playback failed when switching between audio-only,
video-only and audio-video files, when choosing different clocks
and when the different streams had different durations.
This is now handled by a helper element, which keeps track of the
running times of all streams and synchronizes them.
Fixes bug #602437.
.weba (audio) and .webv (video) were speculation on my part before
the public launch. As of yet no decision has been made on the
file extension for audio-only WebM, and I'm pretty sure there will
never be one for video-only.
Fixes bug #623837.
Fixes spurious errors that happen after an error and playing a working
stream afterwards or signals that are emitted for non-active groups.
Fixes bug #624266.
This reverts commit 9d7538247f.
If the DVD subpicture caps are not part of the raw caps, uridecodebin
doesn't qualify resindvdbin as raw source and plugs decodebins, which
causes broken DVD playback because of bugs elsewhere.
This change was originally added to only expose supported, raw subtitles,
e.g. if the subtitle sink did not support DVD subpictures but a converter
to some supported format exists. It's not very important right now because
we have nothing (that is autoplugged) to convert from plaintext/pango-markup
or DVD subpictures to something else.
Fixes bug #623583.
Otherwise the uridecodebin will be still a child of playbin2 and
its signals will still be connected. In future state changes this
will then emit unrelated signals that will confuse playbin2 or,
even worse, cause crashes and assertions.
Fixes bug #623318.
If an error happens, the PAUSED state will never be reached. If an
application re-uses decodebin2 (like totem) where one would normally
set to READY between each file, the cleanup that normally happens in
the PAUSED=>READY codepath will never be called, resulting in the
following file to re-use the previous demuxer/decoder/...
https://bugzilla.gnome.org/show_bug.cgi?id=622807
We need to clear the pointer to our ts-offset element when we destroy the video
chain elements to make sure nobody derefs it to invalid memory afterwards.
Otherwise we would end up with a bogus ->audiochain->ts_offset field
which would cause segfaults/assertions when trying to modify the
'ts-offset' property in update_av_offset().
Was easy to trigger when using a list of audio+video files mixed with
video-only files in totem.
Use the pad caps when they are available to continue the autoplugging. If the
pad caps are set, they are fixed and then we can directly continue autoplugging.
