summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* wasapisrc: Correctly disable provide-clockNirbheek Chauhan2018-08-021-3/+3
| | | | `#ifdef` will, of course, evaluate to 1 in this case. We want `#if`.
* wasapisink: fix regression in shared mode segment sizeChristoph Reiter2018-08-021-3/+9
| | | | | | | | | | | | | In commit fd806628a8 (839cc3926 in the stable branch) I changed the segment size to match exactly the buffer size. I missed that this is only valid in exclusive mode and in shared mode the buffer size is a multiple of the device period. Revert the logic for the shared mode. https://bugzilla.gnome.org/show_bug.cgi?id=796354 https://bugzilla.gnome.org/show_bug.cgi?id=796858
* compositor: Don't leak all buffers while crossfading and not all pads are ↵Sebastian Dröge2018-07-261-0/+5
| | | | crossfading
* compositor: Use 255 as maximum alpha instead of 256Sebastian Dröge2018-07-251-7/+5
| | | | | | | | | | | | | | | | | | | 255 will easily become 0 in the blending function as they expect the maximum value to be 255. Can be reproduce with gst-launch-1.0 videotestsrc pattern=ball ! c.sink_0 \ videotestsrc pattern=snow ! c.sink_1 \ compositor name=c \ sink_0::zorder=0 sink_1::zorder=1 sink_0::crossfade-ratio=0.5 \ background=black ! \ videoconvert ! xvimagesink crossfade-ratio +/- 0.001 makes it work correctly and the same happens at e.g. 0.25, 0.75, N*0.0625 https://bugzilla.gnome.org/show_bug.cgi?id=796846
* kmssink: Add support for mxsfb-drm driverGary Bisson2018-07-251-1/+1
| | | | | | | | | | The mxsfb-drm driver has been added to the kernel long ago and will now be the default display driver for NXP i.MX28, i.MX6SX and i.MX7D processors so now is a good time to add it to kmssink. Also, this is used in the upcoming i.MX8MQ and i.MX8MM processors. https://bugzilla.gnome.org/show_bug.cgi?id=796873
* kmssink: Add new entry for Xilinx DRM DriverDevarsh Thakkar2018-07-251-1/+2
| | | | | | | | | | | | | This adds entry for new DRM driver from xilinx called "xlnx" which supports atomic modesetting. We have kept entry for older DRM driver "xilinx_drm" for backward compatility with a note describing deprecation. Signed-off-by: Devarsh Thakkar <devarsht@xilinx.com> https://bugzilla.gnome.org/show_bug.cgi?id=795228
* kmssink: Add support for the Allwinner DRM driver (sun4i-drm)Paul Kocialkowski2018-07-251-1/+1
| | | | | | | | This adds the sun4i DRM driver to the list of DRM drivers in kmssink. The driver allows displaying video in either the main plane or an overlay plane. https://bugzilla.gnome.org/attachment.cgi?bugid=794839
* Release 1.14.21.14.2Tim-Philipp Müller2018-07-206-144/+672
|
* Update docsTim-Philipp Müller2018-07-20130-128/+140
|
* find_codec_preferences: use received capsMathieu Duponchelle2018-07-181-2/+5
| | | | | | | | | | | | | | | When negotiation is triggered by receiving caps on our sink pad probes, we could encounter a race condition where need-negotiation is emitted and the application requires the creation of an offer before the current caps were actually updated. This led to retrieving incomplete caps when creating the offer, using find_codec_preferences -> pad_get_current_caps. Instead, as we save the caps in the probe callback anyway, it is better and thread safe to use these if they were set. https://bugzilla.gnome.org/show_bug.cgi?id=796801
* player: Avoid trying to join the player thread from itselfRoland Jon2018-07-181-1/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796731
* decklink: Fix warning about HRESULT not being unsigned intNirbheek Chauhan2018-07-181-1/+1
|
* pitch: Flush only if there are unprocessed samplesSuhas Nayak2018-07-181-3/+5
| | | | | | | Otherwise we end up trying to flush before sample rate of SoundTouch is set https://bugzilla.gnome.org/show_bug.cgi?id=796613
* pitch: preserve seek event seqnumsMathieu Duponchelle2018-07-181-0/+4
| | | | | | This was wreaking havoc when used with a downstream audiomixer. https://bugzilla.gnome.org/show_bug.cgi?id=796603
* pitch: fix latency reportingMathieu Duponchelle2018-07-181-2/+0
| | | | | | | | | When max is GST_CLOCK_TIME_NONE in the query, it should not be set in the query handler, this otherwise could lead to impossible situations, where the minimum latency ended up greater than the maximum. https://bugzilla.gnome.org/show_bug.cgi?id=796603
* pitch: Fix single input buffer followed by EOSMathieu Duponchelle2018-07-181-3/+0
| | | | | | | | | | | | | The flush function immediately returned when pitch->next_buffer_offset was 0. This is clearly wrong, as next_buffer_offset can be 0 when a single input buffer has been received, and no output buffer has been produced before receiving EOS. Simply remove that condition. https://bugzilla.gnome.org/show_bug.cgi?id=796603
* videoaggregator: Fix string leakSeungha Yang2018-07-181-2/+3
| | | | | | | gst_video_colorimetry_to_string() returns allocated memory which must be freed. https://bugzilla.gnome.org/show_bug.cgi?id=796596
* videoaggregator: log an ERROR if we're going to return a flow errorTim-Philipp Müller2018-07-181-1/+1
|
* dvb: Fix typo in comment terminationJan Schmidt2018-07-181-1/+1
|
* dvb: camconditionalaccess: fix wrong license headersAlessandro Decina2018-07-182-26/+26
| | | | | | Update the license blurb in camconditionalaccess.[hc] from GPL to LGPL. The plugin is LGPL and the GPL header in those two files was just a copy/paste mistake.
* webrtc: Fix memory leakJan Schmidt2018-07-161-0/+1
| | | | Fix a leaked string when building RTX info.
* webrtc: Clean up and fix transportsendbinJan Schmidt2018-07-162-184/+241
| | | | | | | | | | Refactor transportsendbin, and change the way pads are blocked on dtlssrtpenc so that they don't interfere with state changes. As well as being easier to read, this fixes spurious failures shutting down webrtcbin if DTLS negotiation hasn't completed yet.
* webrtc: Move dtlssrtpenc state managementJan Schmidt2018-07-162-2/+17
| | | | | | | Move the errant piece of dtlssrtpenc state change management from dtlstransport in the Webrtc libs, into the transportsendbin that does the rest of the element management so it's all in one place.
* webrtc/dtlstransport: Add more debug. Rename categoryJan Schmidt2018-07-161-1/+1
| | | | Rename the dtlstransport debug category to webrtcdtlstransport.
* webrtc: Clean up pad block allocs on dispose.Jan Schmidt2018-07-161-16/+27
| | | | | | Release references in pad blocks and release the memory in the dispose function too, in case the state change doesn't get run (because calling the parent state change fails).
* webrtc: Move the transportsendbin pad block removalJan Schmidt2018-07-051-13/+15
| | | | | | | | | | Move freeing of the pad blocks back to before we call the GstBin state change function, as there's something racy going on on the build server otherwise, where the pads don't unblock during downward state changes. This is a bit of a stab in the dark, since I can't recreate the build server failure locally.
* webrtc: Fix wrong parent classes for DTLSTransport and ICETransportThibault Saunier2018-07-032-2/+2
| | | | Those are GObjects not GstBins
* webrtc: Explicitly initialise mutex and conditionJan Schmidt2018-07-021-0/+5
| | | | | | | Fixes random crashes when an allocated webrtcbin isn't given fresh 0-filled memory in its allocation. It works mostly because GMutex and GCond are automatically initialised in that case.
* webrtc: Don't deadlock on block pads on shutdownJan Schmidt2018-06-281-6/+12
| | | | | | | | | | | | | | When changing state downward, we can't set pads to inactive if they are blocked, it will deadlock trying to acquire the streaming lock. Just calling the parent state change function will do the correct things to unblock probes and set the pad inactive, so let it do that and remove the probes after the parent state change function has run https://bugzilla.gnome.org/show_bug.cgi?id=796682
* webrtcbin: copy sticky events on our ghostpadsMathieu Duponchelle2018-06-281-0/+12
| | | | | | | | | | This lets users call gst_pad_get_current_caps on newly-added pads to easily determine what to plug them into. We cannot copy sticky events unconditionally in core, see #719437 https://bugzilla.gnome.org/show_bug.cgi?id=796387
* webrtcbin: rtpstorage takes a 64-bit integer for "size-time" propertyTim-Philipp Müller2018-06-281-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796429
* webrtcbin: implement support for FEC and RTXMathieu Duponchelle2018-06-289-41/+1230
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=795044
* player: Fix duration-changed CRITICAL warning if duration did not actually ↵Lyon Wang2018-06-211-1/+2
| | | | | | | | change Check if duration is changed before emitting duration-changed signal https://bugzilla.gnome.org/show_bug.cgi?id=796491
* gst_webrtc_session_description_new: fix annotationsMathieu Duponchelle2018-06-211-1/+1
|
* tsdemux: Don't set invalid seqnum on segment eventNicolas Dufresne2018-06-191-1/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796623
* tsdemux: Don't query duration if program isn't activeEdward Hervey2018-06-191-0/+5
|
* mpegtsdemux: Fix SEGMENT seqnum propagationEdward Hervey2018-06-193-3/+10
| | | | | * If the seek was handled upstream, use that SEGMENT seqnum * Use the proper invalid default value
* codecparsers: mpeg2: don't mess the StartCode only packetsSreerenj Balachandran2018-06-011-1/+1
| | | | | | | | | It is completely legal to have packets with zero sizes. Zero-sized packet indicates header with only Start Code. One eg: is user data packet. The patch allows having GstMpegVideoPacket with zero sizes. https://bugzilla.gnome.org/show_bug.cgi?id=796477
* wasapisink: fix a rounding error when calculating the buffer frame countChristoph Reiter2018-05-251-3/+5
| | | | | | | | | | | | | | | | The calculation for the frame count in the non-aligned case resulted in a one too low buffer frame count. This resulted in: 1) exclusive mode not working as the frame count has to match exactly there. 2) Buffer underruns in shared mode as the current write() code doesn't handle catching up to low buffer levels (fixed in the next commit) To fix just use the wasapi API to get the buffer size which will always be correct. https://bugzilla.gnome.org/show_bug.cgi?id=796354
* wasapisink: fix missing unlock in case IAudioClient_Start failsChristoph Reiter2018-05-251-1/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796354
* wasapi: use FAILED to detect errorsChristoph Reiter2018-05-231-1/+1
| | | | | | | | | | S_FALSE is a valid return value which does not indicate an error. For example IAudioClient_Stop() returns S_FALSE when it is already stopped. Use the FAILED macro instead which just checks if an error occured or not. This fixes spurious warnings when using the wasapisink element. https://bugzilla.gnome.org/show_bug.cgi?id=796280
* wasapi: Don't pass CoTaskMemFree to g_clear_pointerChristoph Reiter2018-05-232-2/+4
| | | | | | | CoTaskMemFree has a different calling convention than GDestroyNotify and things crash at least with MinGW. https://bugzilla.gnome.org/show_bug.cgi?id=796280
* Release 1.14.11.14.1Tim-Philipp Müller2018-05-176-25/+757
|
* Update docsTim-Philipp Müller2018-05-17126-126/+126
|
* Update translationsTim-Philipp Müller2018-05-171-29/+29
|
* adaptivedemux: Support period change in live playlistSeungha Yang2018-05-141-9/+13
| | | | | | | | | | | Regardless of LIVE or VOD, "a manifest has next period but currently EOSed" state is meaning that it's time to advance period. Previous behavior of adpativedemux, however, was able to period advancing only for VOD case, since the adaptivedemux tried to update and wait new manifest without respecting existence of the next period. https://bugzilla.gnome.org/show_bug.cgi?id=781183
* dashdemux: Fix sync of updated manifest from previous oneSeungha Yang2018-05-141-0/+6
| | | | | | | _get_next_fragment_timestamp() returns relative timestamp to period start. But gst_mpd_client_stream_seek() uses absolute MPD timeline. https://bugzilla.gnome.org/show_bug.cgi?id=781183
* srtp: Add "roc" caps field to the gst-launch exampleOlivier Crête2018-05-141-1/+1
| | | | | | The currrent example was broken since 1.8.3 it seems. https://bugzilla.gnome.org/show_bug.cgi?id=786304
* tsdemux: ignore sparse stream when checking for initial timestampAurélien Zanelli2018-05-141-4/+17
| | | | | | | | | | | | Unless we only have sparse streams. In this case we will consider them. It fixes a bug happening when first observed timestamp comes from a sparse stream and other streams don't have a valid timestamp, yet. Thus leading the timestamp from sparse stream to be the start of the following segment. In this case, if the timestamp is really bigger than non-sparse stream (audio/video), it will lead the pipeline to clip samples from the non-parse stream. https://bugzilla.gnome.org/show_bug.cgi?id=744469
* nvdec: Add colorimetry info to the capsJan Schmidt2018-05-141-0/+98
| | | | | Output any colorimetry information extracted from the stream into the caps.
View Lorry Controller Status