including the following supports and fixes:
* Create DirectFB surfaces from GstBufferPool
* Add NV12 pixel format support
* Don't use the cursor in the exclusive mode
- EnableCusor() can be only used when the administrative mode is set
in DirectFB 1.6.0 and later.
* Support multiple plane rendering for planar color formats
- This accommodates the chroma plane offsets of the framebuffer
in planar formats.
* Invoke SetConfiguration regardless of video mode setting in setcaps()
- SetConfiguration() method should be invoked regardless of
the result of gst_dfbvideosink_get_best_vmode(), since the two are
unrelated.
* Disable DirectFB signal handler
- "--dfb:no-sighandler" option is passed to DirectFBInit().
This prevents DirectFB from trying to kill the process and allows
GStreamer's termination sequence to proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=703520
The prog-map property of mpegtsmux only allows you to group pids together in a program.
The program number set in the PAT/PMT tables cannot be set explicitly.
This patch will set the program number according to the prog-map.
If a program id of 0 is given, the first vacant program number starting from 1 will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=697239
While it was a great idea, various g-i based bindings don't support
GArray with entries greater than sizeof(gpointer) :(
So let's just make everybody happy by just using GPtrArray.
And since we're breaking the API, also rename the various descriptor fields
to no longer have the descriptor_ prefix.
It does cost a bit more in terms of memory/cpu usage, but makes it usable
from bindings.
It appears that the Logitech C920 sometimes drops the next
to last segment of RAW aux data contained within the MJPEG
container. H264 data that is multiplexed with in the same
container does not appear to be affected. This appears to
be a bug in the Logitech C920 firmware and uvch264src should
not error out in this case.
Sometimes it can take 24 hours of continuous streaming for
the problem to occur, but sometimes it takes only a couple
of hours.
https://bugzilla.gnome.org/show_bug.cgi?id=706276
Do state changes from sink to src. Fixes race condition in
pull mode test where the source will start up and push buffers
to queue/identity or aiffparse before the main thread has
managed to set them to playing yet.
For SegmentTemplate elements containing a startNumber attribute, the
`number' member of GstMediaSegments should be offset by the value of
startNumber; however, this is not currently the case. As a result, the
first URI(s) requested by the download loop will be wrong.
This commit ensures that segment numbers will be offset by startNumber
when one is present in a SegmentTemplate element.
https://bugzilla.gnome.org/show_bug.cgi?id=705661
When using a SegmentTemplate element, the timestamps of the buffers
output by dashdemux are incorrect, causing problems downstream.
The reason is that GstMediaSegment start times are calculated (in
gst_mpdparser_get_chunk_by_index) by multiplying segment index by
segment duration and then scaling the result according the `timebase'
attribute from the MPD. However, the segment duration is already a
GstClockTime (i.e., it has already been scaled according to the timebase
from the MPD and converted to a nanosecond value), so multiplying it by
the segment index will give the correct timestamp without the need for
any further scaling.
https://bugzilla.gnome.org/show_bug.cgi?id=705679
