... instead of just counting frames. The values are supposed to be in timebase
units, not frame units. This fixes various quality problems with VP8/VP9
encoding and in general makes the encoder behave better.
Thanks to Nirbheek Chauhan for noticing this bug.
In pulsesink_query function, we use a switch for the query
type. In the CAPS case, there is no 'break', instead we
return right away. Use a break and return at the end of
the function instead for better code readability.
https://bugzilla.gnome.org/show_bug.cgi?id=744461
If we can not create probe stream in query_getcaps function, it will appear
memory leakage from format info.
The following patch prevent memory leakage in pulsesink.
https://bugzilla.gnome.org/show_bug.cgi?id=743178
basesrc assumes that we don't return a buffer if
something else than OK is returned. It will just
leak any buffer we might accidentially provide
here.
This can potentially happen during flushing.
Maybe fixes https://bugzilla.gnome.org/show_bug.cgi?id=741993
Set positioning-mode=pixels-absolute to allow positioning with
absolute coordinates, meaning negative x/y offsets will be
interpreted as being to the left/above the video frame instead
of being interpreted as relative to the right/bottom edge of
the video frame (which is a silly default, but that's how it is).
This means we can nicely slide images into and out of the frame,
see gdkpixbufoverlay-test.
https://bugzilla.gnome.org/show_bug.cgi?id=739566
http://www.wavpack.com/file_format.txt:
"Both the APEv2 tags and/or ID3v1 tags must come at the end of the
WavPack file, with the ID3v1 coming last if both are present."
WavPack files that contain APEv2 tags at the beginning of the files
are unplayable on players that use FFmpeg (like VLC) and most other
software (except Banshee). Players that use libwavpack directly can
play the files because it skips the tags, but does not recognize the
tag data at that location.
https://bugzilla.gnome.org/show_bug.cgi?id=711437
This avoids _set_format setting the unpositioned flag when passed
NULL as channel positions, as it would not be cleared when setting
actual channel positions later.
ARNR type control in libvpx has been deprecated so this commit mark the
vp8enc and vp9enc associated properties as deprecated and change their
behavior to just display a warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=739476
Right now in parse logic the signature is checked every time the parse function
is called, and the whole data is the scanned each and every time, even though the
data is scanned in the previous instance. Changing the logic such that, we skip
the bytes which are already scanned in the previous instances of parse. This
helps in avoiding multiple scan of already scanned data/signature.
https://bugzilla.gnome.org/show_bug.cgi?id=737708
We need a mechanism in PulseAudio to allow running code outside the
mainloop lock. Then we'd be able to post to the bus (taking the
GST_OBJECT_LOCK), without worrying about locking order with the mainloop
lock, which is the current cause of deadlocks while trying to post the
stream status messages.
https://bugzilla.gnome.org/show_bug.cgi?id=736071
Stream headers are updated whenever ::set_caps is called, so we can't assume
they'll be valid before the message body is written out. We *can* assume that
for queued buffers, but SOUP_MEMORY_STATIC is still wrong for those.
Also, add some debug logging for stream header interactions.
https://bugzilla.gnome.org/show_bug.cgi?id=737771
::render sets a new callback for writing out new buffers only if there aren't
already buffers queued for writing with a previously-scheduled callback.
However, if the previously-scheduled callback is interrupted by a state change
(either manually or due to an error) and there are still buffers in the queue,
restarting the pipeline will result in buffers being queued forever, and no
callbacks will ever be scheduled, and no buffers will be written out.
https://bugzilla.gnome.org/show_bug.cgi?id=737739
This gives a quick introduction to how the pulsesink/pulsesrc code
interacts with the pa_threaded_mainloop that we start up to communicate
with the server.
The stream status messages are emitted in the PA mainloop thread, which
means the mainloop lock is taken, followed by the Gst object lock (by
gst_element_post_message()). In all other locations, the order of
locking is reversed (this is unavoidable in a bunch of cases where the
object lock is taken by GstBaseSink or GstAudioBaseSink, and then we get
control to take the mainloop lock).
The only way to guarantee that the defer callback for stream status
messages doesn't deadlock is to either stop posting those messages, or
make sure that the message emission is completed before we proceed to
any point that might take the object lock before the mainloop lock
(which is what we do after this patch).
https://bugzilla.gnome.org/show_bug.cgi?id=736071
packetized mode is being set when framerate is being set
which is not correct. Changing the same by checking the
input segement format. If input segment is in TIME it is
Packetized, and if it is in BYTES it is not.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
packetized mode is being set when framerate is being set
which is not correct. Changing the same by checking the
input segement format. If input segment is in TIME it is
Packetized, and if it is in BYTES it is not.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
packetized mode is being set when framerate is being set
which is not correct. Changing the same by checking the
input segement format. If input segment is in TIME it is
Packetized, and if it is in BYTES it is not.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
In gst_gdk_pixbuf_dec_setup_pool(), query is being allocated using
gst_query_new_allocation(), but the same is not unreferenced
hence calling gst_query_unref() after usage of query.
https://bugzilla.gnome.org/show_bug.cgi?id=735950
They are reported properly by libvpx if the correct struct members are used.
This also fixes handling of resolution changes without input caps changes.
https://bugzilla.gnome.org/show_bug.cgi?id=719359
When we cancel connection attempts and similar things, there are still
some operations pending on our main context from the GCancellables. We
should let them all run before unreffing our context, otherwise we leak
file descriptors.
Unfortunately this requires libsoup 2.47.0 or newer as earlier versions
steal our main context from us and we can't use it for cleanup later
without assertions and funny crashes.
Based on a patch by Dmitry Shatrov <shatrov@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=663944
fpp can never equal 0 here, or the loop would not execute at all.
Zero fpp was possible before as the loop condition was allowing
it specifically, but no more.
Coverity 1139681
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Makes libpng deinterlace Adam7 interlaced pictures
by default. It is the only interlaced format available
and if the picture isn't interlaced the code should behave
as before.
https://bugzilla.gnome.org/show_bug.cgi?id=726161
This will happen if we have an incoming stream with a non-TIME segment
Could be improved later to figure out proper pts/duration.
CID #1199702
CID #1199703
If nothing happens after 15 seconds, chances are good that
our connection will never will work. Stop after 15 seconds
instead of waiting until the system's default timeout, which
can be > 1 minute.
Only return EOS the next time create() is called, if at all. basesrc
should already take care of not calling it again.
Also always return immediately if the previous flow return was
not OK. This indicates an error somewhere.
Add log handlers for jack that write to the gst debug log. This avoids spamming
the console when e.g. using autoaudiosink, having the jack elements installed,
but not running jack.
Commit 46fd12ae5e introduced connection
recovery. But when server does not specify content-size,
souphttpsrc tries to reconnect even after regular end of stream.
Http server replies with SOUP_STATUS_REQUESTED_RANGE_NOT_SATISFIABLE
but souphttpsrc still emits error instead of EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=724717
Signed-off-by: Branislav Katreniak <bkatreniak@nuvotechnologies.com>
We want to notice ourselves that we're EOS. Otherwise we will
always cancel requests in the very end and confuse the server...
and also make it impossible to use persistent connections.
gstsouputils.c:35:25: error: comparison of constant 9 with expression of type
'SoupLoggerLogLevel' is always false
[-Werror,-Wtautological-constant-out-of-range-compare]
Those are advertised in the template caps, but the
setcaps handler didn't handle them. But then oggmux
and oggparse at least for now still always output
application/ogg anyway, so that wasn't a real problem.
This element and the underlying libshout2 library
can handle video media files too. The code already
handles video/webm so the name gets confusing. Also
add and use DEFAULT_FORMAT macro Instead of hardwiring
SHOUT_FORMAT_VORBIS at init
https://bugzilla.gnome.org/show_bug.cgi?id=721342
libshout2 (we require > 2.0 at config time) supports
both IP and hostname for _set_host(). Dropped an
outdated FIXME regarding this limitation, adjusted
some comments and changed the param blurb to reflect
this too.
The base videodecoder class has an error counting feature to tolerate
a few errors before posting an error message. So don't force the
error and let the base class decide when it should happen
https://bugzilla.gnome.org/show_bug.cgi?id=710762
The source hdv1394src has the guid property that permits select a camera
connected from its GUID number.
However when this property is setted the selected camera is not changed.
The source continues using the default camera.
This problem was solved using the function iec61883_cmp_connect.
The reference for the function could be found here:
http://www.dennedy.org/libiec61883/API-iec61883-cmp-connect.html
The solution came from dvgrab source code.
https://bugzilla.gnome.org/show_bug.cgi?id=710415
If the pipeline is stalled for too long, souphttpsrc will block and
stop fetching data from the network. This can cause the connection to
drop and souphttpsrc would handle it as an EOS. This patch makes it
persist and try to fetch more data until the end of the content length
or until receiving an error that it is beyong limits in case the content
is unknown.
https://bugzilla.gnome.org/show_bug.cgi?id=683536
Since jpegdec already parse the jpeg stream, the sink caps could be
relaxed. This will allow jpegdec to be selected in more case and in
particular when the jpeg typefinder does not find the width and height.
https://bugzilla.gnome.org/show_bug.cgi?id=709352
The audio library considers them as encoded formats and does not fill in the
sample width. The audio ringbuffers identifies the format as alaw/mulaw and that
is always 8 bits.
This reverts commit 01457027e0.
We'll just depend on PulseAudio 2.0 or above instead of having the bug
partially fixed based on the installed libpulse version.
The getcaps function we added uses some pa_format_info_get_prop...
accessor functions that were only added in 2.0, so we only have our
getcaps implementation exist if we're compiling against libpulse 2.0 or
above.
Eventually, we could bump the minimum requirement to 2.0 or above.
https://bugzilla.gnome.org/show_bug.cgi?id=686459
getcaps is called frequently during stream setup, and creating a new
stream each time is very inefficient. There's some more room for
optimisation by caching the queried sink formats as well, but this needs
some more changes to listen for format changes on the sink (for when
supported formats change between probe stream creation and sink
querying).
https://bugzilla.gnome.org/show_bug.cgi?id=686459
This allows us to have more fine-tuned caps in READY or above. However,
this is _really_ inefficient since we create a new stream and query sink
for every getcaps in READY, which on a simple gst-launch line happens
about 35 times. The next step is to cache getcaps results.
https://bugzilla.gnome.org/show_bug.cgi?id=686459
lame does internal resampling, but the base class only cares about
the number of raw samples, so tell finish frames about that, not
the number of samples in the outgoing frame.:
The HTTP server could give wrong information, e.g. if the HTTP stream is
chunk-encoded or compressed, or if the server does not know the complete size
at the time when the file is requested by the client.
Also see
https://bugs.webkit.org/show_bug.cgi?id=115354
Answer to scheduling queries with default parameters and the new
_BANDWIDTH_LIMITED_FLAG so that downstream is advised to minimize seek
operations and perform on-disk buffering if possible.
Bug 693484
In 1.0 we now always send the icecast request headers by default, which
makes the server send icecasts metadata inserted into the stream if it
supports that. However, there are some use cases where this is not
desirable, like when just saving a radio stream to disk, so add back
the "iradio-mode" property to allow people to disable this.
https://bugzilla.gnome.org/show_bug.cgi?id=697984
This makes sure that we update segdone based on the read index received
during latency updates. As the comment notes, we make some compromises
to deal with the fact that segdone is a segment multiple, while the read
index offers finer granularity. The updates are also not very often
(100ms since that is how often automatic timing updates are provided).
All this is required for the baseaudiosink sample alignment code to work
at all.
https://bugzilla.gnome.org/show_bug.cgi?id=694257
Apparently there's no reason to use it any longer. Drop libsoup-gnome
dependency while at it, now that we don't need anything from it any
more (it only consists entirely of deprecated API now anyways).
https://bugzilla.gnome.org/show_bug.cgi?id=693911
Now that the subset check actually works, this breaks
things with demuxers that don't put a "sof-marker"
in their jpeg caps, and we don't have a good parser
to plug either yet.
When receiving an error code from the http server, such as 404,
data might be sent along with it, like a web page. We don't want
to output that data in this case, and we also want to pass the
FLOW_ERROR return back to the base class, so it can stop properly.
https://bugzilla.gnome.org/show_bug.cgi?id=678429
* The last MP3 frame wasn't being pushed when base class was draining
* Made sure mpg123 cannot ever use its (crude) internal resampler
* Disabled mpg123 stderr output
https://bugzilla.gnome.org/show_bug.cgi?id=686595
A bug in PulseAudio causes PA_STREAM_START_MUTED to be rejected on
record streams. Until this is fixed upstream, we mute the stream
manually at startup. Based on a patch by Alban Browaeys
<prahal@yahoo.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=684469
Without this patch vp8enc send header before and after first
key frame. On second keyframe vp8dec will crash without getting
decoded frame. With this pipe it is easy to reproduce this issue:
gst-launch-1.0 videotestsrc ! vp8enc ! vp8dec ! fakesink
https://bugzilla.gnome.org/show_bug.cgi?id=680667
I only tested that vp8enc ! vp8dec does not crash, as valgrind does not grok
at least one of the instructions used by vp8enc, preventing me from checking
a leak, and the lack of one after the patch.
libvpx 1.1.0 disallows a bitrate of 0, which was used by
vp8enc as a default value.
Instead, we use the default libvpx bitrate, scaled to our
video size, if no bitrate was specified.
This fixes encoding VP8 video with libvpx 1.1.0.
https://bugzilla.gnome.org/show_bug.cgi?id=676245
Avoid getting output_state for every buffer as that requires
getting the objectlock and doing reference counting. Store it locally
when it is created and use it.
Using the input state was causing a crash because the strides/offsets
would be wrong. Fix it by using the output as we are dealing with
the decoded frame.
libvpx 1.1.0 disallows a bitrate of 0, which was used by
vp8enc as a default value.
Instead, we use the default libvpx bitrate, scaled to our
video size, if no bitrate was specified.
This fixes encoding VP8 video with libvpx 1.1.0.
https://bugzilla.gnome.org/show_bug.cgi?id=676245
altref/invisible frames usually stored in container with same timestamp as
dependet frame. This make basevideodecoder to update timestamp for dependet
frame and couse TS colision on next frame:
^- here is altref
time : 1 2 3 4 5 6 7 8 9
webm ts : 1 3 5 5 7 9
vp8dec ts: 1 3 7 7 9
Fix bug: https://bugzilla.gnome.org/show_bug.cgi?id=655245
Signed-off-by: Oleksij Rempel (Alexey Fisher) <bug-track@fisher-privat.net>
This is initial preset file, currently with only one profile
for realtime encoding.
Signed-off-by: Oleksij Rempel (Alexey Fisher) <bug-track@fisher-privat.net>
It will fix handling of altref/invisible frames since matroska-mux
drop any fram with no timestamp.
see also:
http://www.webmproject.org/code/specs/container/
The encoder will currently set the AR's timestamp as close as possible
to the previous frame while attempting to provide a timestamp that is
strictly increasing. In cases where the time base given to the encoder
at configure time is not granular enough to allow for this the AR
will share the same timestamp as D, but should be
treated as having no duration.
Fixes bug #652951
Signed-off-by: Alexey Fisher <bug-track@fisher-privat.net>
the commit f9b552f049 (vp8dec: set par to 1/1)
will fix situation where no aspect-ratio is set, but it brake
stream with available aspect-ratio. This patch fix it.
Fixes: #652902.
Signed-off-by: Alexey Fisher <bug-track@fisher-privat.net>
While this changes API slightly (e.g. actually uses set_format now), which is OK
for unstable API, it has following merits:
* symmetric w.r.t. stop at state change
* in line with other base class practice
* otherwise no subclass method at state change (global activation time)
Moreover, subclassese are either unaffected or trivially adjusted accordingly.
