- Jan 30, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jan 27, 2017
-
-
Vivia Nikolaidou authored
The n_frames field (frames per second) should follow the nominal frame rate for drop-frame timecodes. Also, the trak's timescale (and duration, accordingly) should follow the STSD entry's timescale and frame duration (fps_n and fps_d accordingly), not the other way around. https://bugzilla.gnome.org/show_bug.cgi?id=777832
-
Arnaud Vrac authored
Fix a regression introduced by commit 183695c6 (refactor to use Soup's sync API). The code previously attempted to reconnect when the server closed the connection early, for example when the stream was put in pause for some time. Reintroduce this feature by checking if EOS is received before the expected content size is downloaded. In this case, do the request starting at the previous read position. https://bugzilla.gnome.org/show_bug.cgi?id=776720
-
-
-
- Jan 26, 2017
-
-
Sebastian Dröge authored
This reverts commit 67f6d335. It causes problems in certain scenarios and needs further investigation https://bugzilla.gnome.org/show_bug.cgi?id=764947#c9
-
- Jan 25, 2017
-
-
Rahul Bedarkar authored
In case wavparse receives a manually injected FLUSH_STOP event while operating in pull mode we get criticals because we'd try to clear a NULL adapter. https://bugzilla.gnome.org/show_bug.cgi?id=777123
-
-
-
- Jan 19, 2017
-
-
Sebastian Dröge authored
Otherwise we could read more chunks than there are available, doing an out of bounds read and potentially crash. https://bugzilla.gnome.org/show_bug.cgi?id=777469
-
Sebastian Dröge authored
This reverts commit 99d5d757. It broke playback of various valid files.
-
Sebastian Dröge authored
Otherwise we could read more chunks than there are available, doing an out of bounds read and potentially crash. https://bugzilla.gnome.org/show_bug.cgi?id=777469
-
- Jan 18, 2017
-
-
Arnaud Vrac authored
The current code configures libsoup to handle redirections transparently, without informing the caller, thus preventing the element to record the redirect code and location uri. Fix this by always setting the SOUP_MESSAGE_NO_REDIRECT, preventing libsoup from handling the redirection. When we receive a redirection request and libsoup can safely handle it, return a custom error which triggers a retry with the new URI. https://bugzilla.gnome.org/show_bug.cgi?id=777222
-
- Jan 16, 2017
-
-
Jan Schmidt authored
When reset, don't restart request pad numberings, as request pads can survive across state changes. Only restart at 0 if all request pads are handed back first. https://bugzilla.gnome.org/show_bug.cgi?id=777174
-
Andre McCurdy authored
The seqh buffer allocated in qtdemux_parse_svq3_stsd_data() needs to be freed by the caller after use. https://bugzilla.gnome.org/show_bug.cgi?id=777157 Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
-
The buffer memory type provided to the VIDIOC_CREATE_BUFS ioctl shall be set with the value ("memory") given as input parameter of the gst_v4l2_allocator_probe() function. https://bugzilla.gnome.org/show_bug.cgi?id=777327
-
- Jan 09, 2017
-
-
Matthew Waters authored
Otherwise some messages that are emitted by the element on NULL->READY will not reach the application. https://bugzilla.gnome.org/show_bug.cgi?id=764947
-
Seungha Yang authored
time in segment should be PTS based (not DTS). https://bugzilla.gnome.org/show_bug.cgi?id=765498
-
- Jan 08, 2017
-
-
Jan Schmidt authored
If a fragmented stream doesn't have a tfdt, don't reset the output timestamps at each fragment boundary by erroneously using the default value of 0. Introduced by commit 69fc48 https://bugzilla.gnome.org/show_bug.cgi?id=754230
-
- Dec 22, 2016
-
-
Sebastian Dröge authored
Also consume the data entry by entry to get complicated indexing out of the code. https://bugzilla.gnome.org/show_bug.cgi?id=776107
-
-
Heekyoung Seo authored
Add check for node length of video sample description and its fields and for the XiTh atom. Also unify the code a bit. https://bugzilla.gnome.org/show_bug.cgi?id=775794
-
- Dec 13, 2016
-
-
Sebastian Dröge authored
That is, whenever we go through start/stop we have to ensure that on the next opportunity the buffers are reallocated again. Otherwise the buffers might be NULL because the element was reused with the same configuration as before (i.e. set_caps() wouldn't have reinited the buffers). https://bugzilla.gnome.org/show_bug.cgi?id=775898
-
Sebastian Dröge authored
I.e., don't just forward the event but delay it if we don't have caps on the srcpad yet.
-
-
- Dec 07, 2016
-
-
Sebastian Dröge authored
Otherwise we might leak arbitrary information from the uninitialized memory if not every pixel is written. https://scarybeastsecurity.blogspot.gr/2016/12/1days-0days-pocs-more-gstreamer-flic.html
-
Matt Staples authored
Redirect on PLAY wasn't doing the necessary session cleanup. Fixed by removing code from gst_rtspsrc_send that changed the state varable upon encountering a redirect. Better to let the redirect handlers in gst_rtspsrc_retrieve_sdp and gst_rtspsrc_play do their own state-dependent cleanup. https://bugzilla.gnome.org/show_bug.cgi?id=775543
-
- Dec 05, 2016
-
-
Edward Hervey authored
When providing items with a seqnum, there is a (very small) probability that an element with the same seqnum already exists. Don't forget to free that item if it wasn't inserted. And avoid returning undefined values when dealing with duplicate items
-
Havard Graff authored
When doing rtx, the jitterbuffer will always add an rtx-timer for the next sequence number. In the case of the packet corresponding to that sequence number arriving, that same timer will be reused, and simply moved on to wait for the following sequence number etc. Once an rtx-timer expires (after all retries), it will be rescheduled as a lost-timer instead for the same sequence number. Now, if this particular sequence-number now arrives (after the timer has become a lost-timer), the reuse mechanism *should* now set a new rtx-timer for the next sequence number, but the bug is that it does not change the timer-type, and hence schedules a lost-timer for that following sequence number, with the result that you will have a very early lost-event for a packet that might still arrive, and you will never be able to send any rtx for this packet. Found by Erlend Graff - erlend@pexip.com https://bugzilla.gnome.org/show_bug.cgi?id=773891
-
Havard Graff authored
The lost-event was using a different time-domain (dts) than the outgoing buffers (pts). Given certain network-conditions these two would become sufficiently different and the lost-event contained timestamp/duration that was really wrong. As an example GstAudioDecoder could produce a stream that jumps back and forth in time after receiving a lost-event. The previous behavior calculated the pts (based on the rtptime) inside the rtp_jitter_buffer_insert function, but now this functionality has been refactored into a new function rtp_jitter_buffer_calculate_pts that is called much earlier in the _chain function to make pts available to various calculations that wrongly used dts previously (like the lost-event). There are however two calculations where using dts is the right thing to do: calculating the receive-jitter and the rtx-round-trip-time, where the arrival time of the buffer from the network is the right metric (and is what dts in fact is today). The patch also adds two tests regarding B-frames or the “rtptime-going-backwards”-scenario, as there were some concerns that this patch might break this behavior (which the tests shows it does not).
-
Havard Graff authored
The new timeout is always going to be (timeout + delay), however, the old behavior compared the current timeout to just (timeout), basically being (delay) off. This would happen if rtx-delay == rtx-retry-timeout, with the result that a second rtx attempt for any buffers would be scheduled immediately instead of after rtx-delay ms. Simply calculate (new_timeout = timeout + delay) and then use that instead. https://bugzilla.gnome.org/show_bug.cgi?id=773905
-
-
Edward Hervey authored
We might have non-printable characters in the unknown fourcc, replace them with '_', in the same way we do it for unknown tags.
-
-
Sebastian Dröge authored
gst_tag_image_data_to_image_sample() does not take ownership of the passed memory, so don't set it to NULL to allow us to free it later. https://bugzilla.gnome.org/show_bug.cgi?id=775472
-
Sebastian Dröge authored
Especially, simplify the code a bit.
-
Sebastian Dröge authored
1024 bytes is quite small, let's do 4096 bytes (or one page). Also remove redundant if, we're always in that case when getting here.
-
-