Previously GstCurlSmtpSink could cause the pipeline thread to end up
waiting for a stopped thread to perform work.
The scenario was that the sink could be rendering a buffer and waiting
for the curl transfer thread to have sent the data. As soon as the
transfer thread has copied all data to curl's data buffer in
gst_curl_base_sink_transfer_read_cb() then the render call would stop
waiting and return GST_FLOW_OK. While this takes place the transfer
thread may suffer from an error e.g. due gst_poll_wait() timing out.
This causes the transfer thread to record the error, claim (it is not
really true since there was an error) that the data has been sent and
that a response has been received by trying to signal the pipeline
thread (but this has already stopped waiting). Finally the transfer
thread stops itself. A short while later the pipeline thread may attempt
to push an EOS event into GstCurlSmtpSink. Since there is no check in
gst_curl_smtp_sink_event() to check if the sink has suffered from any
error it may attempt to add a final boundary and ask the, now deceased,
transfer thread to transfer the new data. Next the sink element would
have waited for the transfer to complete (using a different mechanism
than normal transfers through GstCurlBaseSink). In this case there was
an error check to avoid waiting if an error had already been seen.
Finally GstCurlSmtpSink would chain up to GstCurlBaseSink which would
then block waiting for a response (normally this would be prevented by
the transfer thread suffering the error claiming that it had been
received, but GstCurlSmtpSink clobbered this flag after the fact).
Now GstCurlSmtpSink avoids this by locking over the entire event handing
(preventing simultaneous changes to flags by the two threads) and also
by avoiding to initiate transfer of final boundary if an error has
already been seen.
Also add GST_FIXME() for remaining similar issue where the pipeline
thread may block indefinitely waiting for transfer thread to transfer
data but the transfer thread errors out and fails to notify the pipeline
thread that the transfer failed.
https://bugzilla.gnome.org/show_bug.cgi?id=767501
And always set the sampling field on the src caps, if necessary guessing a
correct value for it from the colorspace field.
Also, did some cleanup: removed sampling enum - redundant.
https://bugzilla.gnome.org/show_bug.cgi?id=766236
Use namespace only after it was actually defined by a header.
gstfacedetect.cpp:79:17: error: using directive refers to implicitly-defined namespace 'std' [-Werror]
using namespace std;
^
Replace the type and function prefix to follow the conventions:
- Use `GST_TYPE_DC1394_SRC` instead of `GST_TYPE_DC1394`.
- Use `GstDC1394Src` and `GstDC1394SrcClass` instead of
`GstDc1394` and `GstDc1394Class`.
- Use `gst_dc1394_src` instead of `gst_dc1394`.
https://bugzilla.gnome.org/show_bug.cgi?id=763026
The dc1394src is a PushSrc element for IIDC cameras based on libdc1394.
The implementation from the 0.x series is deffective:
caps negotiation does not work, and some video formats
provided by the camera are not supported.
Refactor the code to port it to 1.X and enhance the support
for the full set of video options of IIDC cameras:
- The IIDC specification includes a set of camera video modes
(video format, frame size, and frame rates).
They do not map perfectly to Gstreamer formats, but those that
do not match are very rare (if used at all by any camera).
In addition, although the specification includes a raw format,
some cameras use mono video formats to capture in Bayer format.
Map corresponding video modes to Gstreamer formats in capabilities,
allowing both gray raw and Bayer video formats for mono video modes.
- The specification includes scalable video modes (Format7),
where the frame size and rate can be set to arbitrary values
(within the limits of the camera and the bus transport).
Allow the use of such mode, using the frame size and rate
from the negotiatied caps, and set the camera frame rate
adjusting the packet size as in:
<http://damien.douxchamps.net/ieee1394/libdc1394/faq/#How_do_I_set_the_frame_rate>
The scalable modes also allow for a custom ROI offset.
Support for it can be easily added later using properties.
- Camera operation using libdc1394 is as follows:
1. Enumerate cameras on the system and open the camera
identified the enumeration index or by a GUID (64bit hex code).
2. Query the video formats supported by the camera.
3. Configure the camera for the desired video format.
4. Setup the capture resources for the configured video format
and start the camera transmission.
5. Capture frames from the camera and release them when not used.
6. Stop the camera transmission and clear the capture resources.
7. Close the camera freeing its resources.
Do steps 2 and 3 when getting and setting the caps respectively.
Ideally 4 and 6 would be done when going from PAUSED to PLAYING
and viceversa, but since caps might not be set yet, the video mode
is not properly configured leaving the camera in a broken state.
Hence, setup capture and start transmission in the set caps method,
and consequently clear the capture and stop the transmission
when going from PAUSED to READY (instead of PLAYING to PAUSED).
Symmetrycally, open the camera when going from READY to PAUSED,
allowing to probe the camera caps in the negotiation stage.
Implement that using the `start` and `stop` methods of `GstBaseSrc`,
instead of the `change-state` method of `GstElement`.
Stop the camera before setting new caps and restarting it again
to handle caps reconfiguration while in PLAYING (it has no effect
if the camera is not started).
- Create buffers copying the bytes of the captured frames.
Alternatively, the buffers could just wrap the bytes of the frames,
releasing the frame in the buffer's destroy notify function,
if all buffers were destroyed before going from PLAYING to PAUSED.
- No timestamp nor offset is set when creating buffers.
Timestamping is delegated to the parent class BaseSrc,
setting `gst_base_src_set_live` TRUE, `gst_base_src_set_format`
with GST_FORMAT_TIME and `gst_base_src_set_do_timestamp`.
Captured frames have a timestamp field with the system time
at the completion of the transmission of the frame,
but it is not sure that this comes from a monotonic clock,
and it seems to be left NULL in Windows.
- Use GUID and unit properties to select the camera to operate on.
The camera number used in version 0.X does not uniquely identify
the device (it depends on the set of cameras currently detected).
Since the GUID is 64bit identifier (same as MAC address),
handle it with a string property with its hexadecimal representation.
For practicality, operate on the first camera available if the GUID
is null (default) and match any camera unit number if unit is -1.
Alternatively, the GUID could be handed with an unsigned 64 bit
integer type property, using `0xffffffffffffffff` as default value
to select the first camera available (it is not a valid GUID value).
- Keep name `GstDc1394` and prefix `gst_dc1394` as in version 0.X,
although `GstDC1394Src` and `gst_dc1394_src` are more descriptive.
- Adjust build files to reenable the compilation of the plugin.
Remove dc1394 from the list of unported plugins in configure.ac.
Add the missing flags and libraries to Makefile.
Use `$()` for variable substitution, as many plugins do,
although other plugins use `@@` instead.
https://bugzilla.gnome.org/show_bug.cgi?id=763026
The heuristic to choose between packetise or not was changed to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
The heuristic to choose between packetise or not was changed to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
Move calling gst_vtdec_push_frames_if_needed from ::set_format to ::negotiate so
that we always drain even when renegotiation is triggered by downstream.
vtdec specifies sysmem; GLMemory as template caps. When negotiating, we used to
call gst_pad_peer_query_caps (..., filter) with our template caps as filter. The
query does gst_caps_intersect (filter, peercaps) internally which gives
precedence to the order of the filter caps. While we want to output sysmem by
default, when negotiating with glimagesink which returns GLMemory; sysmem; we
do want to do GL, so we now query using a NULL filter and intersect the result
with our template caps giving precedence to downstream's caps.
tl;dr: make sure we end up negotiating GLMemory with glimagesink
A simple fix for the problem of creating new pads with duplicate
names when switching program, easier than the alternative of
trying to work out which pads might persist and manage that.
See https://bugzilla.gnome.org/show_bug.cgi?id=758454
If for some reason the avdtpsink element can't go READY then the
gsta2dpsink can't either and so should release the ressources it
allocates when trying to do so.
Fix a leak with the generic/states test.
https://bugzilla.gnome.org/show_bug.cgi?id=767161
Similar to vtdec_hw, this commit adds a vtenc_h264_hw element that fails
caps negotiation unless a hardware encoder could actually be acquired.
This is useful in situations where a fallback to a software encoder
other than the vtenc_h264 software encoder is desired (e.g. to x264enc).
https://bugzilla.gnome.org/show_bug.cgi?id=767104
When renegotiating mid stream - for example with variable bitrate
streams - and therefore destroying and recreating VTSessions, the
hw decoder might become temporarily unavailable.
To deal with this and avoid erroring out on bitrate changes,
vtdec_hw now falls back to using the software decoder if the hw
one was available at some point but isn't anymore. At
renegotiation/bitrate change time, it will still retry to open
the hardware one.
::negotiate can be called several times before the CAPS event is sent downstream
so use the currently configured output state caps instead of the pad current
caps when deciding whether to recreate the VTSession or not.
This leads to creating/destroying less VTSessions which makes renegotiation more
reliable especially when using hw decoding.
There's no need for an end-of-list marker in the filter
PIDs array if full, as the absolute maximum number of
elements (MAX_FILTERS) is known.
CID #1362441
Use new gst_h264_video_calculate_framerate() API instead of fps_n/fps_d
fields in SPS struct which are to be removed.
Apparently H264 content in MSS is always non-interlaced/progressive,
so we can just pass 0 for field_pic_flag and don't need to parse any
slice headers first if there's no external signalling. But even if
that's not the case the new code is not worse than the existing code.
https://msdn.microsoft.com/en-us/library/cc189080%28VS.95%29.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=723352
