Update the blocksize depending on how much is obtained from a read
of the input stream. This avoids doing too many reads in small chunks
when larger amounts of data are available and also prevents using
a very large memory area to read a small chunk of data.
https://bugzilla.gnome.org/show_bug.cgi?id=767833
The heuristic to choose between packetise or not was changed to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
The heuristic to choose between packetise or not was change to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
Previously the segment.time was wrong, and the position was not updated
correctly, resulting in seeks in PUSH mode with upstream providing a BYTES
segment to not work at all.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
This fixes seeking in DV streams where upstream operates in PUSH mode with a
TIME segment (e.g. avidemux). Without this, we would generate wrong durations
and timestamps after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
When early returning in gst_soup_http_src_read_buffer() because the
element is FLUSHING, we need to unmap and unref the buffer which was just created.
https://bugzilla.gnome.org/show_bug.cgi?id=766718
Directly setting audio/x-raw caps leads to problems when the delivered
data blocks do not align properly at sample boundaries (for example, a
data block with 391 bytes). So, instead, set audio/x-unaligned-raw to
let a parser be autoplugged.
https://bugzilla.gnome.org/show_bug.cgi?id=689460
Non-blocking read will return the amount of data available without
blocking to wait for the full requested size.
The downside is that now it souphttpsrc needs to have a waiting
mechanism in case there is no data available yet to avoid busy
looping arond the inputstream.
The previous ones resulted in odd display aspect ratios and were different
from the ones used by e.g. ffmpeg. The new ones now result in display aspect
ratios of 4:3 and 16:9.
https://bugzilla.gnome.org/show_bug.cgi?id=765946
When a frame's duration is too low, calling gst_util_uint64_scale()
to scale its value can result into it being truncated to zero, which
will cause the vpx encoder to return an VPX_CODEC_INVALID_PARAM error
when trying to encode.
To prevent this from happening, we simply ignore the duration when
encoding if it becomes zero after scaling, logging a warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=765391
This reverts commit 0dd46accf6.
With some audiosinks, starting the ringbuffer on the first commit
causes audio glitches at startup by starting to output segments
from the ringbuffer before it has been filled / fully prerolled. This
doesn't usually happen with pulsesink because we map the pulseaudio
ringbuffer directly, but we should keep things consistent with
other sinks with regards to startup latency, plus it gives more
headway to avoid glitching, should the initial 2nd segment take
more than 10ms to generate.
https://bugzilla.gnome.org/show_bug.cgi?id=657076
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
We already pass the entire frame to the decoder. If the decoder ask for
more data, don't pass the same data again as this leads to infinit loop.
Instead, simply fail the fill function to signal the problem with that
frame. It will then be skipped properly.
https://bugzilla.gnome.org/show_bug.cgi?id=761670
All code paths for handle_frame() must somehow take ownership of the frame, be
it by actually unreffing, forwarding the frame elsewhere or storing it for
later.
http://bugzilla.gnome.org/show_bug.cgi?id=760666
With the VPX decoders it's not simple to use downstream buffer pool,
because we don't know the image size and alignment when buffers get
allocated. We can though use GstAllocator (for downstream, or the system
allocator) to avoid a copy before pushing if downstream supports
GstVideoMeta. This would still cause a copy for sink that requires
specialized memory and does not have a GstAllocator for that, though
it will greatly improve performance for sink like glimagesink and
cluttersink. To avoid allocating for every buffer, we also use a
internal buffer pool.
https://bugzilla.gnome.org/show_bug.cgi?id=745372
This adds an automatic mode to the threads property of vpxdec in order to
use as many threads as there is CPU on the platform. This brings back
GStreamer VPX decoding performance closer to what is achieved by other
players, including Chromium.
https://bugzilla.gnome.org/show_bug.cgi?id=758195
When jpeg_finish_decompress is called, output state reference is being created.
But if there is any failures in finishing decompress, it jumps to setjmp,
and at that point state was not referenced. Resulting in leak of output state.
Hence adding another setjmp after output state is referenced.
Similarly adding another setjmp to unmap the frame in case error happens before
finish_decompress
https://bugzilla.gnome.org/show_bug.cgi?id=753087
