We need to reset the elements from the video recording branch, including
the queue and capsfilter in order to clear the eos state and activate
the pads.
This makes it possible to record multiple videos with camerabin2 in a
sequence, otherwise the source would get a unexpected return and
push EOS, stopping the whole pipeline.
As video recording bin's state is locked, we should always
remember of setting it to NULL when camerabin2 goes to NULL
Be more careful when using elements that might not
have been created yet
And do not set location property recursively on videorecordingbin
Adds a location property to enable applications to select
the captured files names. Locations are handled just like
multifilesink ones
Also disables -Wformat-nonliteral to allow to use non-literals
on g_strdup_printf on camerabin and generate a sequence of
locations for captures.
Keep vidbin state locked to avoid it going to playing without
being used and leaving an empty file created.
Check the docs on the code for details on the handling.
Adds property that informs if v4l2camerasrc is available
for starting a new capture.
It is useful for applications to know (via deep-notify) when the
property changes and a new capture is possible. Note, however, that
starting a new capture from the notify callback will cause a deadlock.
Removes the old logic for v4l2camerasrc that used the mode
property switching to start/stop captures to make it identical
to camerabin2 behavior and to allow the future addition of
pausing a video recording.
This also removes the MODE_PREVIEW as it became useless.
Implements video capture on v4l2camerasrc by using the mode property,
when mode is set to video, the pad probe pushes a new segment
and starts pushing buffers on the pad, when it the property is
sent back to preview, the pad probe pushes an EOS and stops
pushing buffers.
This is controlled by a Recording State variable, that is protected
by the GST_OBJECT_LOCK. I don't think locking for every buffer is
nice, so we could find an alternative lockless way here.
Use 'mode' enum definition from gstcamerabin-enum file to avoid
conflicts between v4l2camerasrc and gstcamerabin2 modes.
For now there is a MODE_PREVIEW there that is only used on the
camerasrc, not sure if we are keeping it at the future, but for
now this works.
Adds mode property to camerabin2, allowing users to
select between video and stills capture. Also adds
start/stop capture actions to trigger and stop
capturing
Adds an bin that is responsible for encoding and saving video
streams to files.
For now it is simply a ffmpegcolorspace ! theoraenc ! oggmux !
filesink bin.
Still uncapable of recording audio.
Adds viewfinder bin element, one of the modules of camerabin2
that is responsible for displaying the video from the camera.
For now it is only a bin with ffmpegcolorspace ! videoscale !
autovideosink
This holds all newsegement and most other events till there is enough
data to set srcpad caps, so that the downstream link is properly
negotiated before data starts flowing.
https://bugzilla.gnome.org/show_bug.cgi?id=635204
This holds all newsegement and most other events till there is enough
data to set srcpad caps, so that the downstream link is properly
negotiated before data starts flowing.
https://bugzilla.gnome.org/show_bug.cgi?id=635205
* libdvbsub gives us alpha channel already, not transparency level, so
don't do another "alpha = 255 - alpha", this is done by libdvbsub.
* Fix alpha channel handling in interpolation - assrender had an additional
1bpp alpha bitmap as a possible mask, we don't. So don't use the palette
index array as alpha values; bug from quick code porting long ago to
changing pixel colors (assrender has a single pixel color for whole
regions or something, unlike dvbsub, which has indexed colors).
* Don't forget to reassign our YUV and other local pixel color variables
after shifting to work on the bottom part of a 2x2 subsample block, or
it's obviously very blocky.
Remaining issues in blending:
* Should probably be interpolating or doing something else useful with the
resulting U and V channels, so that most of the source pixel UV values would
actually be actually cared about, except for just one out of possibly four.
* Don't convert AYUV to ARGB in libdvbsub, and then back from ARGB to AYUV in
dvbsuboverlay for no reason
* Re-factor the whole thing to something more like textoverlay blending
* Related to that, perhaps cache the current spu in a good format for quick
blending on each frame, after which the more often called blending parts
might become more straightforward
The spec has a page_time_out in the page composition segment to ensure
subtitles don't get stuck on screen for too much longer than intended,
when future page composition segments get lost on bad reception, or other
problems. Honor it in the gst plugin side.
Push incoming subtitle pages in a FIFO queue (pending_subtitles)
and dequeue the head when it's time to show it (when video running
time reaches the subtitle page running time).
Keep the subtitle page, that is supposed to be blended on top of video
currently, in a separate object variable (current_subtitle). As a
next step we can then pre-render current_subtitle to a better to blend
format.
Eases holding onto the information in gst plugins side queue of
DVBSubtitles, so we won't need to create yet another temporary struct
to keep the pts and page_time_out too.
And this really logically belongs at the toplevel information set anyway
and in that struct...
We want to allow queueing of raw region image data in the gst plugin side,
and keep the data around until we pop the item from the queue. So make
the callback handler responsible for memory cleanup, if one is installed.
Abuse libdvbsub PTS tracking to just store our running time in it, to get
it back in the callbacks. As GStreamer does its own PTS handling behind our
back (especially for video), we should just sync with video per running time,
not try to do it with PTS, which doesn't seem well accessible for video chain.
We can later relabel dvb-sub.c pts naming convention if wanted, it's just
passing along guint64 values, which GstClockTime fortunately is too.
The current idea is to collect the regions returned by the callback into
a FIFO buffer and pop and pre-render the top one into a separate
quick-to-blend cached format, which is then appropriately blended in the
video chain until the next one on top of the stack reaches the video chains
running time (or the fallback timer hits).
<tpm> leio, what's the mpegts demux hack about?
<leio> my libdvbsub code can't handle cut packets
<leio> so the hack instructs the demuxer to gather full packets before pushing down, but it applies that to more PES packet types than just dvbsub, but I'm not sure if that's a bad thing
<leio> either way, needs a cleaner solution, either in demuxer, or I need to handle cut packets
<tpm> ok, but really it should be fixed in the overlay, right?
<tpm> or a parser be inserted
<leio> the problem is that I don't know from the first packet beforehand if it is a cut one or no
<leio> not
<leio> err, first buffer
<leio> just when I receive the next one I see if it has a valid timestamp on it or not
<leio> so I can't very well queue it up in the chain either, I might be blocking the very last subtitle for no reason or something
<tpm> but you could just drop/ignore packets until you find one, right?
<leio> find what?
<tpm> a complete packet?
<leio> the problem isn't that they aren't complete
<leio> the problem is that they are cut across multiple GstBuffers by the demuxer without the hack
<tpm> sure, I understand that
<tpm> but you can't easily determine if a GstBuffer contains he start fragment of a packet or not?
<leio> I guess I could parse the packet and see if its length is enough, just like the libdvbsub code eventually does too
<leio> I can, it has a timestamp if it's the first chunk
<leio> I just never know if I need to wait for more, without some parsing
<tpm> ah ok
<leio> while the demuxer could just give me an uncut one in the first place
<leio> like it always does for program streams
<leio> that gather_pes is always set in gstmpegdemux, but not in gstmpegtsdemux
As imgbin_finished() is scheduled from g_idle_add, it might
be run a little later than expected, this can lead to the application
setting camerabin to ready before imgbin_finished() runs. In this case,
the processing counter goes to 0 and an assertion happens.
This patch relaxes the imgbin_finished() check on the processing
counter.
This property allows one to start at any point within the field pattern after
a discontinuity (whenever gst_interlace_reset () is called). Thus with the
2:3:3:2 pattern, for example, one can start at offset 2 and achieve 3:2:2:3
or offset 1 and achieve 3:3:2:2.
This patch refactors imagebin element creation and linking into separate functions,
and adds re-using also for imagebin internally created elements.
So this refactoring allows creating imagebin elements already in NULL state when
application sets the image mode, and next state change from NULL to READY will be faster.
This reduces first capture latency.
Earlier the elements were both created and linked in NULL to READY state change.
This patch makes outputselector take an extra ref when pushing
the last_buffer to avoid it losing it during the switch function.
This makes resend-latest properly work if the active-pad is changed
during the switch function buffer pushing (on a pad probe, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=629917
This patch makes output-selector always recheck if there's a
pending pad switch after pushing a buffer, preventing that
it pushes a buffer on the 'wrong' pad.
https://bugzilla.gnome.org/show_bug.cgi?id=629917
In this mode, an initial empty moov (containing only stream metadata) is written,
followed by fragments containing actual data (along with required metadata).
New fragments are started either at keyframe (if such are sparse) or when
property configured duration exceeded.
Based on patch by Marc-André Lureau <mlureau@flumotion.com>
Fixes#632911.
TDT and TOT sections, with PID=0x14, doesn't extend to several packets
and the section filter is not needed here and shouldn't be used at all
for these tables because the have a different structure.
For example, TDT tables were not parsed for odd hours because this bit
is the 'current_next_indicator' bit for the other sections, and the table
was discarded.
That is, as such formats allow subclass to extract position from frame,
it is possible to extract duration (if not otherwise provided)
from (near) last frame, and a seek can fairly accurately target the required
position.
Fixes#631389.
Arrange for upstream as well as downstream flushing when seeking.
Also determine upstream size as well as seekability. Adjust some comments
to reality and employ debug statement in proper order.
Adds 'idle', a read-only boolean property that tells applications
if there is any capturing/saving/encoding going on in camerabin. If
not, it is safe to set it to NULL and release resources without
losing data.
Add "ready-for-capture" property to indicate if preparing a new
capture is possible.
"ready-for-capture" changes before the 'image-done' signal, so
the application can be notified that it can do a new capture
even before the previous one has finished encoding/saving.
Use information from the gop header and picture
header to calculate the picture timestamp. (time_code
and temporal_reference) and adapt to upstream timestamps if
provided.
https://bugzilla.gnome.org/show_bug.cgi?id=632222
When switching between video/still modes the pre-night-mode fps
should be reset to prevent it being used in the incorrect mode, causing
the videosource to fail configuring itself
Store width/height/fps for video captures in a separate variable
than the one that stores the currently used value.
This prevents the user preferences to be lost when resetting
the currently used dimensions for night mode, for example
Resets used caps so that camerabin doesn't try to use them
when restarting, where elements/properties might have changed
and the old caps be incompatible
Adds a higher priority to the idle_add function for when
the image bin finished the image capture. This reduces the
delay for the application to be notified about this.
As camerabin only gets notified of the changes from the
video source element, it should query the initial value
once the source is created so it initializes itself
correctly.
