- Apr 20, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Apr 19, 2016
-
-
The server can send multiple crypto sessions, one for each SSRC with its own rollover counter. We parse this information and pass it to the SRTP decoder via the "request-key" signal. https://bugzilla.gnome.org/show_bug.cgi?id=730540
-
- Apr 16, 2016
-
-
Xavier Claessens authored
When EOS is reached, the current file get closed and the last GOP in the mq was written in a new file. https://bugzilla.gnome.org/show_bug.cgi?id=765072
-
Jan Schmidt authored
This reverts commit 0dd46acc. With some audiosinks, starting the ringbuffer on the first commit causes audio glitches at startup by starting to output segments from the ringbuffer before it has been filled / fully prerolled. This doesn't usually happen with pulsesink because we map the pulseaudio ringbuffer directly, but we should keep things consistent with other sinks with regards to startup latency, plus it gives more headway to avoid glitching, should the initial 2nd segment take more than 10ms to generate. https://bugzilla.gnome.org/show_bug.cgi?id=657076
-
- Apr 15, 2016
-
-
Sebastian Dröge authored
Make sure to allocate not only a S16 buffer for S16 but a twice as big one to hold S32. https://bugzilla.gnome.org/show_bug.cgi?id=765116
-
- Apr 13, 2016
-
-
-
Sebastian Dröge authored
The head of the queue is the oldest packet (as in lowest seqnum), the tail is the newest packet. To calculate the fill level, we should calculate tail-head while considering wraparounds. Not the other way around. Other code is already doing this in the correct order. https://bugzilla.gnome.org/show_bug.cgi?id=764889
-
For empty edit list, segment-duration in edit list box should not be used for segment event. https://bugzilla.gnome.org/show_bug.cgi?id=764870
-
Sebastian Dröge authored
Otherwise we will use fields from the old caps with everything set up for the new caps, causing crashes and worse. Also don't do anything if the same caps are set twice.
-
- Mar 31, 2016
-
-
Jan Schmidt authored
Make sure that all data is drained out when the reference pad goes EOS. Fixes a problem where data that arrives on other pads after the reference pad finishes can stall forever and never pass EOS. https://bugzilla.gnome.org/show_bug.cgi?id=763711
-
Xavier Claessens authored
Deadlock occurs when splitting files if one stream received no buffer during the first GOP of the next file. That can happen in that scenario for example: 1) The first GOP of video is collected, it has a duration of 10s. max_in_running_time is set to 10s. 2) Other streams catchup and we receive the first subtitle buffer at ts=0 and has a duration of 1min. 3) We receive the 2nd subtitle buffer with a ts=1min. in_running_time is set to 1min. That buffer is blocked in handle_mq_input() because max_in_running_time is still 10s. 4) Since all in_running_time are now > 10s, max_out_running_time is now set to 10s. That first GOP gets recorded into the file. The muxer pop buffers out of the mq, when it tries to pop a 2nd subtitle buffer it blocks because the GstDataQueue is empty. 5) A 2nd GOP of video is collected and has a duration of 10s as well. max_in_running_time is now 20s. Since subtitle's in_running_time is already 1min, that GOP is already complete. 6) But let's say we overran the max file size, we thus set state to SPLITMUX_STATE_ENDING_FILE now. As soon as a buffer with ts > 10s (end of previous GOP) arrives in handle_mq_output(), EOS event is sent downstream instead. But since the subtitle queue is empty, that's never going to happen. Pipeline is now deadlocked. To fix this situation we have to: - Send a dummy event through the queue to wakeup output thread. - Update out_running_time to at least max_out_running_time so it sends EOS. - Respect time order, so we set out_running_tim=max_in_running_time because that's bigger than previous buffer and smaller than next. https://bugzilla.gnome.org/show_bug.cgi?id=763711
-
- Mar 29, 2016
-
-
Sebastian Dröge authored
RFC 2435 mentions in section 4.1 that U/V use table number 1, but this seems just like an example. Some encoders are not following that and there seems to be no reason to reject their streams. https://bugzilla.gnome.org/show_bug.cgi?id=761345
-
In other words, gst_pad_get_current_caps should never return NULL in a pad-added callback from the demuxer. Added tests for the two special cases with AAC and H.264 where this would happen every time. https://bugzilla.gnome.org/show_bug.cgi?id=763780
-
- Mar 28, 2016
-
-
Thiago Santos authored
This allows splitmuxsink to be reused after being put to NULL. Test included https://bugzilla.gnome.org/show_bug.cgi?id=762893
-
- Mar 25, 2016
-
-
If we don't find the index of the sample correctly in src_convert function, we have to unref about the qtdemux before returning value. So, I have modify it about instead pass qtdemux as a parameter into src_convert function. https://bugzilla.gnome.org/show_bug.cgi?id=763973
-
This is a redo of commit b848c1b6. The code was lost when the elements where ported to use a baseclass. https://bugzilla.gnome.org/show_bug.cgi?id=764169
-
- Mar 24, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Mar 17, 2016
-
-
Sebastian Dröge authored
deinterleave: Use GstIterator for iterating all pads instead of manually iterating them while holding the object lock all the time Doing queries while holding the object lock is a bit dangerous, and in this case causes deadlocks. https://bugzilla.gnome.org/show_bug.cgi?id=763326
-
Changing the input caps and not using them anymore afterwards is useless, and it breaks negotiation in pipelines like: gst-launch-1.0 videotestsrc ! "video/x-raw,framerate=25/1,interlace-mode=interleaved" ! deinterlace fields=all ! "video/x-raw,framerate=50/1,interlace-mode=progressive" ! fakesink
-
- Mar 15, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
-
- Mar 13, 2016
-
-
Sebastian Dröge authored
This reverts commit 4065fcb8. flacparse should not push tags by itself, the base class is going to do that while properly merging in upstream tags. It just didn't because of a bug in the base class, which was hidden by this commit. https://bugzilla.gnome.org/show_bug.cgi?id=763553
-
- Mar 10, 2016
-
-
Use MSVC-equivalents for alignment and packing compiler directives when building on MSVC
-
-
MSVC seems to ignore preprocessor conditionals inside static pad template macros.
-
- Mar 08, 2016
-
-
gst_v4l2_object_get_caps_info() always return V4L2_PIX_FMT_SBGGR8 for all bayer formats. This is obviously broken if the device use another ordering. Fix this by properly reading the format parameter. https://bugzilla.gnome.org/show_bug.cgi?id=763318
- Mar 07, 2016
-
-
Thiago Santos authored
When upstream is running in bytes in push-mode, qtdemux will convert seeks from time to bytes and send it upstream. Upstream element will perform a byte seek and send a byte segment to qtdemux that will convert it to time and push it downstream. There is, however, the pending_segment variable that stores a new segment event to be pushed before the next data. When handling seeks as mentioned above this variable was being ignored and, if it contained some segment event, it would override the one resulting from the seek. This would restore a previous segment and would cause the seek segment to be discarded downstream. This patch fixes this issue by unrefing any pending segment as the seek from upstream should contain the latest one that should be used, as requested by the application. https://bugzilla.gnome.org/show_bug.cgi?id=763165
-
Thiago Santos authored
Otherwise commits will fail with our indent check hook
-
Replicate V4L2_MAP_QUANTIZATION_DEFAULT macro behavior. At #v4l it was described that documentation might be wrong and that we should trust this macro instead. https://bugzilla.gnome.org/show_bug.cgi?id=762529
-
- Mar 04, 2016
-
-
Sebastian Dröge authored
On Windows the socket will be bound to ANY instead of the multicast group, as binding to a multicast group does not work. Which would mean that we override src->addr to become ANY and won't automatically join a multicast group anymore on Windows. On Linux we would automatically join a multicast group, keep it consistent. https://bugzilla.gnome.org/show_bug.cgi?id=763093
-
- Mar 02, 2016
-
-
Sebastian Dröge authored
This reverts commit a7fb7b53. The mutex is taken by the caller, we should keep it locked when returning so the caller can unlock it again.
-