Droidmedia supports a callback to indicate the exact moment when the shutter fires, and this is passed on as a GstMessage by Gst-droid. There is already an imageExposed signal being emitted from QGstreamerCaptureSession, but it's only sent when the image is finished, right before imageCaptured. This class already parses GstMessages, so we can move the imageExposed signal to be sent when the shutter actually fires. This can trigger the shutter sound and animation in camera apps as intended.
==25456== 83 bytes in 1 blocks are definitely lost in loss record 7,587 of 8,690
==25456== at 0x483F3EC: malloc (vg_replace_malloc.c:299)
==25456== by 0x5AF00DF: g_malloc (gmem.c:94)
==25456== by 0x5B07185: g_strdup (gstrfuncs.c:363)
==25456== by 0x5A87EC3: value_lcopy_string (gvaluetypes.c:312)
==25456== by 0x5A6B607: g_object_get_valist (gobject.c:2234)
==25456== by 0x5A6B7F3: g_object_get (gobject.c:2322)
==25456== by 0x10241575: QGstreamerPlayerSession::playlistTypeFindFunction(_GstTypeFind*, void*) (qgstreamerplayersession.cpp:1901)
The element name needs to be released when we're done with it.
Change-Id: I650671288bd143551188094b0d934e7da2028a2d
Reviewed-by: VaL Doroshchuk <valentyn.doroshchuk@qt.io>
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
[qtmultimedia] Don't append suggested extension if filename includes extension. Contributes to JB#36676
Commit 6b19a24b58 changed the way that the file name is composed
for a video recording, so that a suggested extension for the given
media format is appended to the file name. That introduced a bug
in the case where the correct extension was already part of the
output location (filename) set for the sink, by causing a second
(and possibly incorrect) extension to be appended to the filename.
This commit ensures that if the filename already has a suffix, no
suggested extension is appended.
Contributes to JB#36676
See merge request !12
Commit 6b19a24b58 changed the way that the file name is composed
for a video recording, so that a suggested extension for the given
media format is appended to the file name. That introduced a bug
in the case where the correct extension was already part of the
output location (filename) set for the sink, by causing a second
(and possibly incorrect) extension to be appended to the filename.
This commit ensures that if the filename already has a suffix, no
suggested extension is appended.
Contributes to JB#36676
On some Android adaptation based devices (Like Jolla1) accessing v4l2 devices
can cause crashes.
Since we don't use V4L for anything and our media pipelines depend on GStreamer, it should
be safe to disable V4L.
There are errors which can occur during manipulating camera HW.
camerabin does not relay any errors and it is the responsibility of camerabin
user to handle those errors. We just react to them and propagate them farther.
This property is provided and controlled by the camera source and should be used to tell
whether the camera source can capture more or not
Conflicts:
src/plugins/gstreamer/camerabin/camerabinsession.h
There is no need to do any seeking since we will restart the pipeline which will
cause GStreamer to start playback from the beginning. We just invalidate any potential
pending seek request.
stopping video recording is asynchronous. Aan EOS event gets sent from camera source,
travels across the whole pipeline until it reaches the muxer which then finalizes the
file by writing the mov atom and friends and then pushes the EOS event farther downstream
until it reaches our file writer (multifilesink in our case).
The sink sends an EOS _message_ which is then caught by camerabin and causes it to flip the
idle property from FALSE to TRUE.
Any attempt to stop the pipeline before this property gets flipped will cause corrupted videos.
Probably because the muxer gets shut down before it gets the EOS event so it does not write the
needed header.
When we are unloading camera we stop video recording and immediately switch camera bin to NULL state.
This can lead to corrupted files. A more proper solution would be to postpone this pipeline tear down
until we are idle.
Since an application can attempt to start the pipeline again before it's completely unloaded, I have added
a check to make sure we never tear down the pipeline if we are not in unloaded state. This check is also needed
because we will be notified about the idle property change while we are loading the camera and we should
not unload it when that happens.
This also required removing the pipeline state change to NULL when we are loading camera.
Our camera source does not yet support generating previews thus enabling it without
a proper support from the source leads to issues with processing counter and camerabin
never reaching idle state.
I cannot find a reason why someone would flip sync to false and git history
does not say much but in general. Just don't play with it as it can cause
an av desync in case we are using a live source
Add proper application pid for VideoResource upon resource object
creation. Also handle VideoResource when removing resource client.
Change-Id: I1c19c875c2d7d3d29aa9426b092081e3fdf47588
Previously when releasing resources when resources were in "acquiring"
state left the internal status in broken state. Because of this calling
acquire() would not really call acquire from Resource Policy. Change the
implementation so that client state is always set to Initial when
calling release(), but call Resource Policy release() only when no clients
are in acquiring or granted state.
Change-Id: I7fb84aefb64da84808375515950a28331531a71e
They are unsupported and cause the search and lock status to always be set to unlocked
We disable it now until we implement it later in droidcamsrc
Conflicts:
src/plugins/gstreamer/camerabin/camerabinlocks.cpp
If we do not apply those then setting camerabin to READY will fail on SailfishOS because
our camera source does not produce standard YUV data and the default constructed camerabin
encoding profile will not work. This will lead to a situation where camera will never work
If media is paused, stopped, or end of media, if state hasn't changed to
playing state, release the resources. The idea with the timer is that if
for example media player is playing one song which ends, there won't be
release()/acquire() unnecessarily if next song is immediately set as
media and started playing.
This enables applications to selectively use platform specific or
unusual (video4linux perhaps) gstreamer sink elements to render video.
Change-Id: Ife2c2f9b2149d6b598c69a78f1e116ba05b46e10
Conflicts:
src/gsttools/gsttools.pro
(cherry picked from ccb985990880717f29fdec16f119b0c02b93d643)
Change-Id: I94d970cb51202d35d894503b1fa5c342b8e8ae44
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
This makes sure all mediaStatus changes are emitted, even when some
action is done on the media player as a result of a state change.
Task-number: QTBUG-49578
Change-Id: I60153cd8e1d665797a25549ab81afcfb553ce2cc
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
The test is flaky and running it 300 times didn't reproduce the
failure.
Change-Id: Ib03722579dbe58c05cb324fdca37eb7e5b732e33
Reviewed-by: Yoann Lopes <yoann.lopes@qt.io>
