* stream-start-id is mandatory at the beginning, so add that to the
gdp headers
* caps must be sent before new segment, invert the order from legacy
0.10 code
And fix the tests as a ref is now kept for those buffers that compose
the header
It is not perfect but it allows us to be sure that the mandatory 'framerate'
field is present in the caps.
As soon as some information is found in the stream, that will be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=723243
An SEI RBSP could contains more than one SEI message as specified in
7.4.2.3.1.
This commit change the parser API: the gst_h264_parser_parse_sei()
function now create and fill a GArray containing GstH264SEIMessage.
https://bugzilla.gnome.org/show_bug.cgi?id=721715
If the first buffer that we handle for a stream has no timestamp, we
would never consider this pad again for muxing which causes queues to
fill up and pipelines to stall. Instead, try to mux pads with -1
timestamps as soon as possible.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722330
mpeg4videoparse might not push buffers while parsing. If those buffers
contain the DISCONT flag, it gets lost and downstream won't get any
buffer with the flag.
Fix it by adding the DISCONT to the next pushed buffer.
This makes backwards playback work.
Collectpads assumes that it can pass any buffer to the clip function
for adjustment, some of which are artificially injected - so don't
adjust global timestamp tracking there. Instead, only adjust the
buffer timestamps and use them directly in the collection function.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=698748
From ETSI EN 300 743 V1.3.1 (2006-11) 7.2.1 Display definition segment specifictations
the parameters of display window are in this order: Xmin, Xmax, Ymin, Ymax.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Pierre-Yves Mordret <pierre-yves.mordret@st.com>
https://bugzilla.gnome.org/show_bug.cgi?id=720382
The perspective plugin applies a 2D perspective (also called projective)
transform to the frame buffer.
A perspective transform can be used for instance to perform keystone
correction when playing the content with a video projector.
https://bugzilla.gnome.org/show_bug.cgi?id=710810
Conversion to byte-stream/nal crashes without that because the
baseparse frame of all NALUs is finished for the first NALU, then
used again for parsing the second NALU. Just that now the buffer
of the frame is already gone. Instead we create temporary frames
for every NALU.
In case more data than a start code alone is needed to decide whether
it ends a frame, arrange for more input data and decide when available.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711627
When the input buffer is empty and we need more data to determine
whether or not to terminate the previous frame, the last start code
location needs to be set to 4 bytes before the the current position
(size of start_code is 32-bits)
https://bugzilla.gnome.org/show_bug.cgi?id=711627
Force filesink to null before posting video-done to make sure the
file was closed.
Had to do it from a separate thread to avoid calling state_change from
a sync message handler.
https://bugzilla.gnome.org/show_bug.cgi?id=709373
When the frame buffer is AYUV writing all zeros does not set it to
black, in YUV colorspace 0x10 is the black level for luminance and 0x80
is the black level for chrominance.
Fix setting the background to black when the out_frame format is AYUV;
in all the other supported formats zeroing the data with memset is still
the right thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=710392
the initial par_n = par_d = 0; was always overwritten since the switch/case
handles all values
And remove the 0 case (it's the same handling as default)
liveadder sometimes calculates the offsets incorrectly before adding. The
resulting errors can easily be heard when mixing silence with a sine.
I'm not sure what the exact conditions are to trigger this, but it definitively
happens when the buffers of two streams have a different duration and buffer
length and duration don't match exactly for one stream because of rounding
errors (e.g. duration=0:00:00.021333333)
I have to admit, I got lost in the math somewhere but it seems that not
rounding in gst_live_adder_length_from_duration() causes 1 sample overlaps in
consecutive buffers from the same stream.
When using gst_util_uint64_scale_int_round() instead of just truncating the
sine sound correctly again.
https://bugzilla.gnome.org/show_bug.cgi?id=708345
It is quite possible that we might get PTS/DTS before the first
PCR/Offset observation.
In order to end up with valid timestamp we wait until at least one
stream was able to get a proper running-time for any PTS/DTS.
Until then, we queue up the pending buffers to push out.
Once we see a first valid timestamp, we re-evaluate the amount of
running-time elapsed (based on returned inital running-time and amount
of data/DTS queued up) for any given stream.
Taking the biggest amount of elapsed time, we set that on the packetizer
as the initial offset and recalculate all pending buffers running-time
PTS/DTS.
Note: The buffer queueing system can also be used later on for the
dvb fast start proposal (where we queue up all stream packets before
seeing PAT/PMT and then push them once we know if they belong to the
chosen program).
