Age | Commit message (Collapse) | Author | Files | Lines |
|
https://bugzilla.gnome.org/show_bug.cgi?id=782359
|
|
It's more accurate and allows cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=773681
|
|
Such as 1.3.0 as on raspbian.
|
|
We were unnecessarily looping/goto-ing repeatedly when we had exactly
the amount of data as the free space, and also when the free space was
too small. This, as it turns out, is a very common scenario with
Directsound on Windows.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=773681
We have to do polling here because the event notification API that
Directsound exposes cannot be used with live playback since all events
must be registered in advance with the capture buffer, you cannot
add/remove them once playback has begun. Directsoundsrc had the same
problem.
See also: https://bugzilla.gnome.org/show_bug.cgi?id=781249
|
|
Don't need to print the function name, gstreamer does it for you.
https://bugzilla.gnome.org/show_bug.cgi?id=773681
|
|
Re-arrange order of index entry struct members to avoid padding
bytes in the middle of the struct, thus potentially reducing the
overall size of the struct and reducing memory used by the index.
On Linux x86_64 the size goes down from 32 bytes to 24 bytes for
each index entry.
|
|
|
|
|
|
|
|
|
|
Since mss has no moov, default stsd entry should be created with media-caps.
https://bugzilla.gnome.org/show_bug.cgi?id=782042
|
|
|
|
|
|
|
|
That case is correctly handled below but not in the debug output.
https://bugzilla.gnome.org/show_bug.cgi?id=781270
|
|
If gst_segment_do_seek() fails, we shouldn't try seeking on that
resulting segment but just error out. Crashes further down the line
otherwise.
|
|
From 60aeef6 to 48a5d85
|
|
Make sure avc output doesn't contain SPS/PPS inline, but
byte-stream output does.
|
|
SPS/PPS are in the caps in this case and shouldn't be in
the stream data.
|
|
If no clock was provided directly by rtspsrc. This behaviour was removed
by f8013487c91a6ffc552a4b25aa1a70f0bd5377f8 and results in rtspsrc not
providing the system clock via the rtpjitterbuffer.
As a result, if another element like an audio sink, provides a clock,
the pipeline would select that (when going to PAUSED/PLAYING again later).
Audio clocks usually don't progress in PAUSED, and thus our live source
won't be able to use the clock to produce data, making the sink never
preroll and everything is stuck.
|
|
Fixes stream where sample_description_id is specified in the tfhd
https://bugzilla.gnome.org/show_bug.cgi?id=778337
|
|
... unless the muxer uses the same audio pad template name as
splitmuxsink. We can't request a pad called "audio_0" on a muxer that
wants pads to be "sink_%d".
|
|
It's also done in gst_flv_demux_cleanup().
https://bugzilla.gnome.org/show_bug.cgi?id=779106
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=767498
|
|
This reverts commit eeea2a7fe88a17b15318d5b6ae6e190b2f777030.
It breaks EOS in some sender pipelines, see
https://bugzilla.gnome.org/show_bug.cgi?id=773218#c20
|
|
In push mode we process as much as possible in the adapter. When we receive
a DISCONT buffer which we can't match to an actual sample (based on the existing
sample table) and there is still data remaining in the incoming adapter,there is
one of two cases happening:
1) We are doing reverse playback, in which case we should flush out all pending
data
2) We have leftover data from the previous incoming buffer... which we can't do
anything about.
For the second case, make sure we flush out the remaining data so that we can start
parsing again from scratch.
https://bugzilla.gnome.org/show_bug.cgi?id=781319
|
|
Allows the application to know the exact status code that was returned
by the server in a programmatic fashion.
https://bugzilla.gnome.org/show_bug.cgi?id=781304
|
|
Fix unit test failure
https://bugzilla.gnome.org/show_bug.cgi?id=781362
|
|
They should have ideally the same timescale of the video track, which we
can't guarantee here as in theory timecode configuration and video
framerate could be different. However we should set a correct timescale
based on the framerate given in the timecode configuration, and not just
use the framerate numerator.
|
|
Make sure offset and neededbytes are properly resetted when all
streams are EOS in push-mode.
Avoids cases when some data might still be pushed by upstream (because
it didn't yet see the resulting GST_FLOW_EOS yet) and qtdemux gets
completely lost.
https://bugzilla.gnome.org/show_bug.cgi?id=781266
|
|
And make sure we actually use the provided soup_msg argument in the macro
|
|
|
|
buf is the current pad->last_buf value. If ever it gets copied/unreffed,
we need to make sure to write back the new pointer to the last_buf
variable.
Fixes using wrong pointer values in the case of decrasing DTS value
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=778337
|
|
Make sure we don't read invalid memory
|
|
It needs only to be read once.
|
|
Before pushing a sample, check if there was a change in the current
stsd entry. This patch also assumes that the first stsd entry is
used as default for the first sample. It might cause an uneeded
caps renegotiation when this isn't the case.
|
|
stsd can have multiple format entries, parse them all.
This is required to play DVB DASH profile that uses multiple entries
to identify the different available bitrates/options on dash streams
The stream format-specific data is not stored into QtDemuxStreamStsdEntry
|
|
Instead of using the stsd as a base pointer, use the actual stsd
entry as the stsd can have multiple entries. This is rarely used
for file playback but is a possible profile with in DVB DASH specs.
This still doesn't support stsd with multiple entries but makes it
easier to do so.
|
|
There might be multiple children with the same type
|
|
properties
https://bugzilla.gnome.org/show_bug.cgi?id=780867
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=780867
|
|
From 39ac2f5 to 60aeef6
|
|
This is needed for V4L2_OUTPUT interface, and is harmless of
V4L2_CAPTURE interfaces. This will fix timestamp in cases like:
v4l2src io-mode=dmabuf ! v4l2videoNenc output-io-mode=dmabuf-import ! ...
Same apply for userptr.
https://bugzilla.gnome.org/show_bug.cgi?id=781119
|
|
Accumulate the durations directly and don't scale yet another time by
the number of samples.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=781025
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=781008
|
|
Running `gst-validate-launcher -t validate.file.playback.change_state_intensive.vorbis_vp8_1_webm`
on odroid XU4 (s5p-mfc v4l2 driver) often leads to:
ERROR:../subprojects/gst-plugins-good/sys/v4l2/gstv4l2videodec.c:215:gst_v4l2_video_dec_stop: assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
This happens when the following race happens:
- T0: Main thread
- T1: Upstream streaming thread
- T2. v4l2dec processing thread)
[The decoder is in PAUSED state]
T0. The validate scenario runs `Executing (36/40) set-state: state=null repeat=40`
T1- The decoder handles a frame
T2- A decoded frame is push downstream
T2- Downstream returns FLUSHING as it is already flushing changing state
T2- The decoder stops its processing thread and sets `->processing = FALSE`
T1- The decoder handles another frame
T1- `->process` is FALSE so the decoder restarts its streaming thread
T0- In v4l2dec-> stop the processing thread is stopped
NOTE: At this point the processing thread loop never started.
T0- assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
Here I am removing the whole ->processing logic to base it all on the
GstTask state to avoid duplicating the knowledge.
https://bugzilla.gnome.org/show_bug.cgi?id=778830
|
|
|