==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>
Don't wait after resume(); the test is meant to check the state of the
QAudioOutput right after the call, not later. The state and the error
status are supposed to change immediately, even if the backend runs in
another thread.
Ignore any state change that can happen because of underrun errors
(likely to happen on CI).
Removed the test from blacklist.
Change-Id: Idaef6a9e0dfcfc89424fb2383cf3830a3184f975
Reviewed-by: Milla Pohjanheimo <milla.pohjanheimo@qt.io>
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
Don't create the camera service when the camerabin plugin is not
available on the system and print a warning.
Task-number: QTBUG-50775
Change-Id: I56c7e6297bebe4b90596cb3c0323f1d38231bceb
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
Some asynchronous operations return a pa_operation pointer, which can
be null if the operation fails. In some cases we were not checking that
the returned object was non null, leading to some asserts being raised
in pa_operation_unref.
Change-Id: Iff1cc67b7f79b758fa81d79e658debb1d737b29f
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
Rather than expecting a certain amount of signals to be fired within
a fixed period, check that all the required signals are emitted and
that it doesn't take longer than expected. Use a margin of error to
take into account timers firing later because of high system load.
Change-Id: I1569ce524e87efc47eb8d11066e509e5dc90f6f8
(cherry picked from commit 586abbd9732f9ccce127429fe0698c25a09ecefb)
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
Map MEDIASUBTYPE_MJPG to QVideoFrame::Format_Jpeg, which makes sure
that cameras that only support MJPEG are configured properly.
Task-number: QTBUG-55359
Change-Id: I732c56afc51109aba0231c8537f795e8d276c194
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
