- Apr 27, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
That case is correctly handled below but not in the debug output. https://bugzilla.gnome.org/show_bug.cgi?id=781270
-
- Apr 25, 2017
-
-
Sebastian Dröge authored
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.
-
- Apr 24, 2017
-
-
Tim-Philipp Müller authored
From 60aeef6 to 48a5d85
-
Tim-Philipp Müller authored
Make sure avc output doesn't contain SPS/PPS inline, but byte-stream output does.
-
Tim-Philipp Müller authored
SPS/PPS are in the caps in this case and shouldn't be in the stream data.
-
- Apr 21, 2017
-
-
Sebastian Dröge authored
If no clock was provided directly by rtspsrc. This behaviour was removed by f8013487 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.
-
Jürgen Sachs authored
Fixes stream where sample_description_id is specified in the tfhd https://bugzilla.gnome.org/show_bug.cgi?id=778337
-
- Apr 20, 2017
-
-
Sebastian Dröge authored
... 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".
-
ChangBok Chae authored
It's also done in gst_flv_demux_cleanup(). https://bugzilla.gnome.org/show_bug.cgi?id=779106
-
-
- Apr 19, 2017
-
-
Tim-Philipp Müller authored
This reverts commit eeea2a7f. It breaks EOS in some sender pipelines, see https://bugzilla.gnome.org/show_bug.cgi?id=773218#c20
-
- Apr 17, 2017
-
-
Edward Hervey authored
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
-
Edward Hervey authored
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
-
- Apr 16, 2017
-
-
Seungha Yang authored
Fix unit test failure https://bugzilla.gnome.org/show_bug.cgi?id=781362
-
- Apr 14, 2017
-
-
Sebastian Dröge authored
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.
-
- Apr 13, 2017
-
-
Edward Hervey authored
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
-
Edward Hervey authored
And make sure we actually use the provided soup_msg argument in the macro
-
- Apr 12, 2017
-
-
Nirbheek Chauhan authored
-
Edward Hervey authored
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
-
Edward Hervey authored
-
-
Edward Hervey authored
Make sure we don't read invalid memory
-
Thiago Santos authored
It needs only to be read once.
-
Thiago Santos authored
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.
-
Thiago Santos authored
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
-
- Apr 11, 2017
-
-
Thiago Santos authored
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.
-
Thiago Santos authored
There might be multiple children with the same type
-
-
-
- Apr 10, 2017
-
-
Tim-Philipp Müller authored
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
-
Sebastian Dröge authored
Accumulate the durations directly and don't scale yet another time by the number of samples.
-
- Apr 09, 2017
-
-
- Apr 07, 2017
-
-
Thibault Saunier authored
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
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-