Commit graph

15743 commits

Author SHA1 Message Date
William Manley
e9e620cd37 docs: Fix GstBuffer typo "memory bock" -> "memory block"
https://bugzilla.gnome.org/show_bug.cgi?id=737117
2014-09-23 19:31:21 +03:00
William Manley
f6b053d375 docs: Improve gst_buffer_get_meta() to clear up confusion
I was confused by the existence of `gst_buffer_get_meta` as it suggested
to me that you should only attach one of any type of GstMeta to a buffer.
It's perfectly fine to attach multiple from a single API so I'm
documenting that here.

https://bugzilla.gnome.org/show_bug.cgi?id=737129
2014-09-23 19:30:15 +03:00
Marcin Kolny
4707c0410c datetime: added missing include directives
https://bugzilla.gnome.org/show_bug.cgi?id=737133
2014-09-23 19:27:25 +03:00
Thibault Saunier
97a6bb377b queue: Do not forget to release the QUEUE_LOCK in the out_flow_error path
Avoiding deadlocks!
2014-09-23 14:45:43 +02:00
Stefan Sauer
feeb2902da docs: fix a small contradition in the docs
The vmethod get_size() shall return the size in 'format' as configured by
_set_format().
2014-09-23 12:53:18 +02:00
Thibault Saunier
38657bff51 queue: Do not hold GST_QUEUE_LOCK while posting ERROR messages
This might create deadlocks and we need to avoid holding element
specific lock while posting messages

For example a deadlock will happen if while posting the message,
someone connected on the bus (sync) tries to DOT the pipeline.

https://bugzilla.gnome.org/show_bug.cgi?id=737102
2014-09-22 16:13:44 +02:00
Thiago Santos
ecf479e3d1 queue2: do not post buffering messages holding the lock
It might cause deadlocks to post messages while holding the queue2
lock. To avoid this a new boolean flag is set whenever a new
buffering percent is found. The message is posted after the lock
is released.

To make sure the buffering messages are posted in the right order, messages
are posted holding another lock. This prevents 2 threads trying to post
messages at the same time.

https://bugzilla.gnome.org/show_bug.cgi?id=736969
2014-09-19 20:35:29 -03:00
Ravi Kiran K N
7a93e6b005 gsturi: Remove unnecessary code
gst_uri_handler_set_uri() function has new_uri, location and colon
are not necessary, they can be removed.

https://bugzilla.gnome.org/show_bug.cgi?id=736877
2014-09-19 10:42:03 +01:00
Tim-Philipp Müller
eefe8be9fe docs: pwg: fix some links to the API docs
https://bugzilla.gnome.org/show_bug.cgi?id=736762
2014-09-19 00:33:58 +01:00
Tim-Philipp Müller
3c4567f591 filesrc: remove FIXME
https://bugzilla.gnome.org/show_bug.cgi?id=735878
2014-09-18 18:57:05 +01:00
Olivier Crête
e87660425c gst: Fix spelling error
Thank to Adrian Owen for reporting this error.

https://bugzilla.gnome.org/show_bug.cgi?id=736839
2014-09-17 21:49:47 -04:00
Ognyan Tonchev
cf04dc0486 typefindelement: do not leak sticky events in flush_stop
https://bugzilla.gnome.org/show_bug.cgi?id=736813
2014-09-17 17:39:10 +01:00
Stefan Sauer
a528dadb98 info: avoid global variable for log_file
Use user_data to pass the log_file handle to the logger-function.

If one wants to change the log target (e.g. GST_DEBUG_FILE), simply call
gst_debug_remove_log_function() and re-add the handler with the new log-target
using gst_debug_add_log_function ().
2014-09-17 09:47:36 +02:00
Ognyan Tonchev
343007894e event: add annotations to gst_event_parse_toc_select()
https://bugzilla.gnome.org/show_bug.cgi?id=736739
2014-09-17 09:51:45 +03:00
Thiago Santos
3f83ca9c43 multiqueue: do not post messages holding the lock
It might cause deadlocks to post messages while holding the multiqueue
lock. To avoid this a new boolean flag is set whenever a new buffering percent
is found. The message is posted after the lock can be released.

To make sure the buffering messages are posted in the right order, messages
are posted holding another lock. This prevents 2 threads trying to post
messages at the same time.

https://bugzilla.gnome.org/show_bug.cgi?id=736295
2014-09-16 16:56:53 -03:00
Wim Taymans
a7d7d9305f docs: fix typo 2014-09-16 16:08:08 +02:00
Ognyan Tonchev
3f19a75d63 query: Add annotations to gst_query_add_allocation_pool()
https://bugzilla.gnome.org/show_bug.cgi?id=736736
2014-09-16 14:44:12 +03:00
Aurélien Zanelli
fefd6d06a1 basesrc: handle reference in set_allocation rather than in prepare_allocation
Otherwise we can forget to unref objects in error cases.

https://bugzilla.gnome.org/show_bug.cgi?id=736680
2014-09-16 10:17:28 +03:00
Sebastian Dröge
84c6e885f1 check: Use the name parameter of gst_check_setup_src_pad_by_name() and the sink variant
This was hardcoded to "sink" / "src" by accident in previous refactoring.
2014-09-15 13:08:09 +03:00
Tim-Philipp Müller
49c6f923de coreelements: mark properties with MUTABLE_PLAYING 2014-09-14 16:08:07 +01:00
Thibault Saunier
87a79673b0 check: Add a function to check destruction of objects
Add a method letting people to ensure that unreffing one object
leads to its destruction, and possibly the destruction of more object
(think destruction of a GstBin etc...).

https://bugzilla.gnome.org/show_bug.cgi?id=736477
2014-09-12 17:18:21 +02:00
Tim-Philipp Müller
d3de22d802 tools: gst-inspect: don't list pad functions
Don't print all the different pad functions, it's just
confusing and no one has ever needed to know this for
anything ever anyway, it's just useless information.
Besides, we also label the default implementations as
'custom' implementations (the code that tries to
prevent that doesn't actually work it seems).

https://bugzilla.gnome.org/show_bug.cgi?id=736377
2014-09-12 14:13:54 +01:00
Sebastian Dröge
126c511e62 pad: Make sure the buffer to get/pull_range() has at least the requested size
https://bugzilla.gnome.org/show_bug.cgi?id=735861
2014-09-12 15:22:19 +03:00
Tiago
076b83208a check: Adding documentation to the gst_check_setup_sink_pad_by_name function
https://bugzilla.gnome.org/show_bug.cgi?id=734190
2014-09-12 14:14:05 +03:00
Ognyan Tonchev
475f8e8cfb query: add annotations to gst_query_set_nth_allocation_pool()
https://bugzilla.gnome.org//show_bug.cgi?id=736424
2014-09-12 10:15:46 +01:00
Rémi Lefèvre
9b2231669f valve: fix typo in description
https://bugzilla.gnome.org/show_bug.cgi?id=736455
2014-09-11 11:09:41 +01:00
Tim-Philipp Müller
d4a4a96f82 baseparse: minor docs fix 2014-09-09 20:43:02 +01:00
Tim-Philipp Müller
c06d9f7b98 devicemonitor: fix typo in sample code in docs
https://bugzilla.gnome.org/show_bug.cgi?id=735975
2014-09-03 19:55:07 +01:00
Wim Taymans
7e33f52961 tests: add flush-stop on inactive pad test
Check that pushing flush-stop on an inactive pad does not clear the
flushing flag.
2014-09-02 12:04:15 +02:00
Wim Taymans
060b16ac75 pad: don't accept flush-stop on inactive pads
Inactive pads should at all times have the flushing flag set. This means
that when we get a flush-stop on an inactive pad we must ignore it.

On sinkpads, make this more explicit. We used to not clear the flush
flag but remove the events and then return an error because the flushing
flag was set. Now just simply refuse the event without doing anything.

On srcpads, check that we are trying to push a flush-stop event and
refuse it. We would allow this and mark the srcpad as non-flushing
anymore.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735357
2014-09-02 12:04:15 +02:00
Ravi Kiran K N
63a943aa82 output-selector: Send all events to active src pad and EOS to all src pads
Fixes tests/icles/output-selector-test

https://bugzilla.gnome.org/show_bug.cgi?id=729811
2014-09-02 12:33:56 +03:00
Guillaume Desmottes
692606bdd2 manual: fix typo in advanced-dataaccess.xml
https://bugzilla.gnome.org/show_bug.cgi?id=735609
2014-08-29 11:35:09 +03:00
Arnaud Vrac
f0deb37a86 buffer: do not touch memory tag flag when copying buffer flags
The tag memory flag will be set later if the memory is also copied. This
patch avoids buffers being freed needlessly in bufferpools.

https://bugzilla.gnome.org/show_bug.cgi?id=735574
2014-08-28 12:20:12 +03:00
Linus Svensson
b0fff643dc bus: gst_bus_add_watch() can return 0 on error
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=735195
2014-08-28 10:10:37 +03:00
Thiago Santos
59c34a8ff7 baseparse: handle streamheaders by prepending them to the stream
Add a first_buffer boolean state flag to have baseparse do actions
before pushing data. This is used to check the caps for streamheader
buffers that are prepended to the stream, but only if the first buffer
isn't already marked with the _HEADER flag. In this case, it is assumed
that the _HEADER marked buffer is the same as the streamheader.

https://bugzilla.gnome.org/show_bug.cgi?id=735070
2014-08-27 10:30:09 -03:00
Sebastian Dröge
ed15b30930 concat: Allow seeking on the currently playing stream
This is consistent with the stream time reporting.
2014-08-27 11:01:53 +03:00
Tim-Philipp Müller
b38264a9cb pad: add g-i 'transfer full' annotations to chain and chain_list functions
https://bugzilla.gnome.org/show_bug.cgi?id=735210
2014-08-23 12:24:27 +01:00
Guillaume Desmottes
a647d83267 pad: annotate GstPadEventFunction event with 'transfer full'
The callback is supposed to take ownership of the event so
best to be explicit about it.

https://bugzilla.gnome.org/show_bug.cgi?id=735210
2014-08-23 12:21:30 +01:00
Linus Svensson
ae74a1a83a tests: add test that triggers deadlock in state change of queue
When receiving FLASH_STOP in a state transition to READY, a queue
element can end up with an active task that will never end.

https://bugzilla.gnome.org/show_bug.cgi?id=734688
2014-08-23 12:03:38 +01:00
Tim-Philipp Müller
93d8679b00 queue: fix race when flush-stop event comes in whilst shutting down
Don't re-start the queue push task on the source pad when a
flush-stop event comes in and we're in the process of shutting
down, otherwise that task will never be stopped again.

When the element is set to READY state, the pads get de-activated.
The source pad gets deactivated before the queue's own activate_mode
function on the source pads gets called (which will stop the thread),
so checking whether the pad is active before re-starting the task on
receiving flush-stop should be fine. The problem would happen when the
flush-stop handler was called just after the queue's activate mode
function had stopped the task.

Spotted and debugged by Linus Svensson <linux.svensson@axis.com>

https://bugzilla.gnome.org/show_bug.cgi?id=734688
2014-08-23 11:43:20 +01:00
Tim-Philipp Müller
86d7a597f0 bytereader: add gst_byte_reader_peek_sub_reader() and _get_sub_reader()
Adds API to get or peek a sub-reader of a certain size from
a given byte reader. This is useful when parsing nested chunks,
one can easily get a byte reader for a sub-chunk and make
sure one never reads beyond the sub-chunk boundary.

API: gst_byte_reader_peek_sub_reader()
API: gst_byte_reader_get_sub_reader()
2014-08-15 10:03:26 +01:00
Aurélien Zanelli
b9fa37f074 docs: make explicit that the caps passed to gst_base_src_set_caps() are 'tranfer none'
https://bugzilla.gnome.org/show_bug.cgi?id=733741
2014-08-15 09:53:09 +01:00
Thiago Santos
3001f3b433 inputselector: always proxy caps query
Otherwise it would only be proxied for the active pad which can lead
upstream to use an incompatible caps for the downstream element.

Even if a reconfigure event is sent upstream when the pad is activated, this
will save the caps reconfiguration if it is already using an acceptable caps.
2014-08-14 19:16:43 -03:00
Tim-Philipp Müller
f88a981997 base: and fix build with new g-i again 2014-08-14 14:38:57 +01:00
Tim-Philipp Müller
55498523e4 base: remove g-i annotation that makes older g-ir-scanner crash
Just remove one skip annotation that causes this:

  ** (g-ir-compiler:12458): ERROR **: Caught NULL node, parent=empty

with older g-i versions such as 1.32.1.
2014-08-14 14:27:13 +01:00
Philippe Normand
b1f2359809 bus: destroy signal watch from the context it was mapped to
Don't rely on g_source_remove() because it operates on the main
context. If a signal watch was added to a new thread-default context
g_source_remove() would have no effect. So simply use
g_source_destroy() to avoid this problem.

Additionally the source_id was removed from GstBusPrivate because it
was redundant with the signal watch GSource also stored in that
structure.

https://bugzilla.gnome.org/show_bug.cgi?id=734716
2014-08-13 18:44:39 +03:00
Thibault Saunier
78e2264544 multiqueue: Not post BUFFERING message if one of the singlequeue doesn't need it
Imagine the following 'pipeline'

                --------------
            p1/| 'fullqueue'  |--- 'laggy' downstream
  ---------  / |              |
-| demuxer |   | multiqueue   |
  ---------  \ |              |
            p2\| 'emptyqueue' |--- 'fast' downstream
                --------------

In the case downstream of one single queue (fullqueue) has (a lot of) latency
(for example for reverse playback with video), we can end up having the other
SingleQueue (emptyqueue) emptied, before that fullqueue gets
unblocked. In the meantime, the demuxer tries to push on fullqueue, and
is blocking there.

In that case the current code will post a BUFFERING message on the bus when
emptyqueue gets emptied, that leads to the application setting the pipeline state to
PAUSED. So now we end up in a situation where 'laggy downstream' is
prerolled and will not unblock anymore because the pipeline is set to
PAUSED, the fullequeue does not have a chance to be emptied and
the emptyqueue can not get filled anymore so no more BUFERRING message
will be posted and the pipeline is stucked in PAUSED for the eternity.

Making sure that we do not try to "buffer" if one of the single queue
does not need buffering, prevents this situtation from happening though it lets the
oportunity for buffering in all other cases.

That implements a new logic where we need all singlequeue to need
buffering for the multiqueue to actually state buffering is needed,
taking the maximum buffering of the single queue as the reference point.

https://bugzilla.gnome.org/show_bug.cgi?id=734412
2014-08-13 18:25:12 +03:00
Sebastian Dröge
3032a369a7 multiqueue: Only handle flow returns < EOS as errors, not e.g. flushing 2014-08-13 13:01:23 +03:00
Sebastian Dröge
2f33fd5c19 bin: Use allow-none instead of nullable until we depend on a new enough GI version 2014-08-13 12:40:37 +03:00
Sebastian Dröge
9b96d4c7cd bin: gst_bin_new() can accept NULL as name 2014-08-13 12:39:47 +03:00