Age | Commit message (Collapse) | Author | Files | Lines |
|
Otherwise the playback would start at title 0
https://bugzilla.gnome.org/show_bug.cgi?id=762787
|
|
Don't artificially limit the bitrate, x264 allows much
higher bitrates, and for intra-only 4k AVC they are needed.
x264 clips to 2Gbps internally, so use that as limit for now.
https://bugzilla.gnome.org/show_bug.cgi?id=758620
|
|
Makes it possible for muxers to know the target bitrate as soon
as encoding starts, which flvmux now uses.
|
|
The query was handled
|
|
Implement accept-caps handling without doing caps queries downstream
|
|
It is faster than doing a query that propagates downstream and
should be enough
Elements: amrnbenc, lamemp3enc, twolamemp2enc
|
|
Avoids useless check of downstream caps when handling an
accept-caps query
|
|
Avoids useless check of downstream caps when handling an
accept-caps query
Elements: a52dec, amrnbdec, amrwbdec, mad
|
|
|
|
This method replace the manual adjustment of PTS and DTS to avoid
negative DTS issues. Using this method will also update the segment so
we don't loos sync.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
|
|
Provide new frame-packing property to directly set
x264enc frame packing, or pass through upstream settings
The explicit layout from the frame-packing property is
preferred over any info from the caps.
|
|
In auto mode it will happily chose much higher values anyway,
and a limit of 4 seems a bit low these days.
|
|
Make the initial chapter seek work across reuse.
https://bugzilla.gnome.org/show_bug.cgi?id=453322
|
|
Ignore the initial seek basesrc sends, as it
breaks starting from another chapter by
immediately seeking back to the start of the title
|
|
Mostly gst-launch -> gst-launch-1.0, but also
use autoaudiosink/autovideosink in more places
and update pipelines a little or flesh out
descriptions.
|
|
This is not needed any longer.
|
|
a52_init initializes the IMDCT global state as well as creating
a new state. When two A52 decoders are created (eg, when two AC3
tracks are contained in a video), calls to a52_init may happen
at the same time, and the IMDCT initialization is not reentrant.
https://bugzilla.gnome.org/show_bug.cgi?id=746781
|
|
gst_buffer_pool_acquire_buffer() gives us a new owned buffer while
gst_buffer_replace() reffed it as well so we were one reference extra.
https://bugzilla.gnome.org/show_bug.cgi?id=746887
|
|
CID #1291630
|
|
Buffer needs to be null before passing it to gst_buffer_pool_acquire_buffer()
CID #1291634
|
|
This allow using external pools that have different strides from the
default. These strides need to respect certain rules, which we check
and if these are not met, we fallback to generic pool.
https://bugzilla.gnome.org/show_bug.cgi?id=735379
|
|
This is a rewrite of the pool negotiation and configuration. Direct
to output decoding is now achieved by configuring the pool using
video-alignment. This removes copies when dealing with any elements that
supports VideoAlignment, and enable usage of generic video buffer pool,
XVImagePool and GLPool. It drops the crop meta implementation for now.
https://bugzilla.gnome.org/show_bug.cgi?id=735379
|
|
|
|
This reverts commit f3e8dcb9de4d546e7d80ccc1754ed13dd4e7ac81.
|
|
This reverts commit 63b43d3bee832aec353d02575da543f3c73f6893.
|
|
|
|
A pipeline like:
gst-launch-1.0 filesrc location=file.ts ! tsdemux ! mpegvideoparse ! mpeg2dec ! vaapisink
would look bad when file.ts contains 704x576 video, because vaapisink would
give you buffers of stride 768, but libmpeg2 was not told about this and
used a stride of 704.
Tell libmpeg2 about the stride from downstream; in the process, teach it to
reject buffer pools that don't meet libmpeg2's chroma stride requirements
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
|
|
This now follows the design docs everywhere, especially the maximum latency
handling.
https://bugzilla.gnome.org/show_bug.cgi?id=744106
|
|
The meaning of the max latency is *not* the maximum latency this element will
introduce. It is the maximum latency this element can endure without
overflowing any buffers, which is infinite for x264enc.
Fixes latency configuration in zero latency mode, where max latency was
becoming 0... which usually won't work well if something else introduces
latency as then max < min in the end, and latency configuration just fails.
|
|
This matches what is done when downstream caps are not ANY, and fixes
prerolling in byte stream mode when typefind is downstream.
|
|
|
|
There is no reason x264enc should enforce a maximum allocation size.
The maximum is normally set by buffer pool which cannot grow, but we
don't offer a buffer pool. This would lead to stall when used with
element that don't implement allocation query.
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=738302
|
|
It's the same as I420 but with the U/V planes swapped.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=732288
|
|
Currently we only shift DTS to compensate that we don't support negative
timestamp. This cause a problem that PTS is no longer >= DTS and may
make muxers live much harder. Instead, shift both PTS/DTS forward. Also
remove all the hack to handle this which seems the result of thinking libx264
is bugged.
https://bugzilla.gnome.org/show_bug.cgi?id=731351
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=730865
|
|
|
|
Else it leaks
CID #1212169
|
|
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.
|
|
We should not reach the dangerous range here, though.
Coverity 206491, 206492, 1139856
|
|
New changes to gstvideo will reset all the video info state
when calling _set_format, overwriting what was previously set
in the preceding code.
The comment says the following code is meant to preserve the
pre-crop size, so let's just keep the size and related data
as this does not seem to break anything else (this is what
the _set_format call would have set before the change that
reset all data, except the colorimetry).
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=725051
|
|
|
|
|
|
|
|
|
|
|
|
Compiler warns rightly about possibly uninitialized variable.
|
|
downstream peer
gst-launch-1.0 videotestsrc ! x264enc
|
|
|