- 12 Apr, 2017 7 commits
-
-
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
-
- 11 Apr, 2017 4 commits
-
-
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
-
-
-
- 10 Apr, 2017 3 commits
-
-
Tim-Philipp Müller authored
From 39ac2f5 to 60aeef6
-
Todor Tomov authored
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.
-
- 09 Apr, 2017 2 commits
-
-
- 07 Apr, 2017 4 commits
-
-
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
-
Sebastian Dröge authored
-
- 06 Apr, 2017 1 commit
-
-
Edward Hervey authored
AudioSpecifigConfig is used in a variety of AAC streams but was being parsed differently. Instead, make everyone use the same parsing. * Remove unused 'bits' field (it was always set to 0 if present) * Add proper GAConfig parsing (to know the number of samples per frame if present). Fixes wrong rate/channels configuration in streams coming from qtdemux https://bugzilla.gnome.org/show_bug.cgi?id=780966
-
- 05 Apr, 2017 5 commits
-
-
Nicolas Dufresne authored
The previous patch was using %llu for 64bits printf, which is 32bit specific. We also trace the latency in time human readable form now.
-
Philipp Zabel authored
Without a specified framerate from the sink, the decoder frame interval should be set using the framerate of the encoded video stream. Therefore, the v4l2object should be able to change the framerate on the output if the V4L2 device accepts it. This is also necessary for mem2mem encoders so that their bitrate calculation code may work correctly and they may report the correct frame duration on the capture queue. https://bugzilla.gnome.org/show_bug.cgi?id=779466
-
Philipp Zabel authored
If the duration of the v4l2object is GST_CLOCK_TIME_NONE, because the sink did not specify a framerate in the caps and the driver accepts the framerate, the decoder element uses GST_CLOCK_TIME_NONE to calculate and set the element latency. While this is a bug of the capture driver, the decoder element should not use the invalid duration to calculate a latency, but print a warning instead. https://bugzilla.gnome.org/show_bug.cgi?id=779466
-
Olivier Crête authored
The correct behaviour of anything stuck in the ->render() function between ->unlock() and ->unlock_stop() is to call gst_base_sink_wait_preroll() and only return an error if this returns an error, otherwise, it must continue where it left off! https://bugzilla.gnome.org/show_bug.cgi?id=774945
-
Jan Schmidt authored
At least output an element warning on the bus when we encounter a frame format GStreamer doesn't currently support.
-
- 04 Apr, 2017 4 commits
-
-
Edward Hervey authored
According to ISO/IEC:14496-2:2009 , in the case of HE-AACv2 (audioObjecType 29) parametric stereo is used (a single mono track is used and then transformations are applied to it to provide a stereo output). We therefore report two channels in the case where there is one reported in the audioChannelConfiguration. Fixes the various issues where a demuxer would report two channels, but then the parser would say there's only one channel, and then the decoder would output two channels.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
last_buf is the one we're going to write next, not buf. As such we should check timestamps against that one if there is one to select the earliest pad. Also remember the currently selected pad in the very beginning when storing the first last_buf. This both solves some edge cases where not the correct next pad was selected corresponding to the target interleave.
-
Sebastian Dröge authored
-
- 03 Apr, 2017 1 commit
-
-
Edward Hervey authored
This is an update of d78d5896 We still exit as early as possible in case of non-ok/non-unlinked combined flow, but we first make sure that we update the internal position variables. This ensures that if upstreams "ignores" the flow return (and carries on pushing), we don't end up processing data with completely bogus variables/positions.
-
- 31 Mar, 2017 2 commits
-
-
Douglas Bagnall authored
If self->channel_positions == NULL (which seems unlikely), self->default_channels_ordering_map will be used unintialised. We avoid that by keeping track of the channel_mask, which is set when the ordering map is initialised. https://bugzilla.gnome.org/show_bug.cgi?id=780331
-
Douglas Bagnall authored
When there are more than 64 channels, we don't want to exceed the bounds of the ordering_map buffer, and in these cases we don't want to rempa at all. Here we avoid doing that. https://bugzilla.gnome.org/show_bug.cgi?id=780331
-
- 28 Mar, 2017 4 commits
-
-
Thibault Saunier authored
It is avalaible in meson 0.36 which is now are requirement
-
Thibault Saunier authored
-
Thibault Saunier authored
-
Thibault Saunier authored
-
- 27 Mar, 2017 2 commits
-
-
Sebastian Dröge authored
The mdat generally does not start at offset 0, we have to include the size of the moof and whatever else was in front of the mdat.
-
Sebastian Dröge authored
CID 1403262
-
- 24 Mar, 2017 1 commit
-
-