It's impossible to create another pipeline with d3dvideosink after disposing
the previous one due to some problem in d3dvideosink. The message is: "Unable
to register Direct3D hidden window class".
I've evaluated the problem and it's that UnregisterClass() in working thread is
called before DestroyWindow() and UnregisterClass() does nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=722622
If the first buffer that we handle for a stream has no timestamp, we
would never consider this pad again for muxing which causes queues to
fill up and pipelines to stall. Instead, try to mux pads with -1
timestamps as soon as possible.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722330
This will be incredible slow if the upstream block size is very small. Instead
continue scanning for the header where we previously stopped.
For the standard filesrc block-size this made decoding a file about
3 times faster.
https://bugzilla.gnome.org/show_bug.cgi?id=719890
Merge various changes and fixes from the master mpegdemux
Performance improvement from the way streams are organised,
return flow combining, language tag event generation,
adjustments and fixes in debug output, and things like that.
Maybe testing the version is clearer, but testing for < 5 is not
enough, my version is 5.4 and does not yet have those new enums.
If you git blame to this and have a version > 5.4 that does not
either, please feel free to join along and bump the version.
Previously faces would only be detected if they were at least 30x30 pixels
large and at most 32x32 pixels. We keep the minimum setting (maybe needs
a property as in facedetect) but disable the maximum feature size.
See https://bugzilla.gnome.org/show_bug.cgi?id=722158
This disables the "max feature size" feature. The current configuration
is totally busted: The max feature size is hard-coded to 2 pixels more
than the user-supplied min feature size which pretty much means you need
to guess the size of the person's face to within a few pixels to get the
code to find it.
https://bugzilla.gnome.org/show_bug.cgi?id=722158
Remove the dashdemux seeking function to use the one implemented
in mpdparser as it is more complete. This also makes dashdemux not
crash when seeking on streams that use segment templates.
mpeg4videoparse might not push buffers while parsing. If those buffers
contain the DISCONT flag, it gets lost and downstream won't get any
buffer with the flag.
Fix it by adding the DISCONT to the next pushed buffer.
This makes backwards playback work.
The original size of 256k was too small for anything where
one would want to use shm. If the buffer's size needs to be limit, it is
better to use buffer-time in most cases anyway.
-add delsys property
-add delivery system capability to the gstreamer adapter structure
-ready for add new delivery systems
Application must ask the adapter structure to know which delivery systems are avaible.
The property delsys must be set.
https://bugzilla.gnome.org/show_bug.cgi?id=709414
Add a new color format seen on my Galaxy S3
(OMX_SEC_COLOR_FormatNV12Tiled = 0x7fc00002) to the table,
but don't actually implement it - the decoder doesn't choose it.
Remove an assert that makes the plugin fail noisily and take the app down
if it sees a color format it doesn't recognise (just skip the codec instead)
Modify the debug output when plugin scanning to print color format info to
make this sort of thing easier in the future.
Collectpads assumes that it can pass any buffer to the clip function
for adjustment, some of which are artificially injected - so don't
adjust global timestamp tracking there. Instead, only adjust the
buffer timestamps and use them directly in the collection function.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=698748
