[playback] Emit missing-plugin codec descriptions as QMediaPlayer::FormatErrors. JB#47099
Remove the old vague message on playback failure, as it's no longer needed. And a duplicated include.
Change-Id: I0c515bd8e4de6d2e2c5966aa776219f5200353a9
updateZoom() is supposed to notify the change in maximum digital zoom.
Instead of emitting "currentDigitalZoomChanged", it emits "maximum
OpticalZoomChanged" signal instead.
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.
A camera source may reject changing the mode while it is busy leaving
the the camerabin plugin in a state inconsistent with the gstreamer
pipeline which can lead to attempts to record video in the image
capture mode and ultimately a lockup.
Changing any of the source resolutions requires putting the pipeline
into the the READY state to apply the changes. If this happened during
a capture the state change was deferred and the internal plugin state
was restored to active before the capture finished and the state changes
were treated as a no-op and the resolution change wasn't applied leading
to an attempt to record video with an unsupported resolution set for
the image capture mode. So if a change to a lower state is requested
and the plugin is unable to process it immediately still defer the
change but ensure the pipeline is still dropped to the lowest requested
state before being restored to the current requested state so that
any changes made on state transitions are applied.
==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
