liveadder sometimes calculates the offsets incorrectly before adding. The
resulting errors can easily be heard when mixing silence with a sine.
I'm not sure what the exact conditions are to trigger this, but it definitively
happens when the buffers of two streams have a different duration and buffer
length and duration don't match exactly for one stream because of rounding
errors (e.g. duration=0:00:00.021333333)
I have to admit, I got lost in the math somewhere but it seems that not
rounding in gst_live_adder_length_from_duration() causes 1 sample overlaps in
consecutive buffers from the same stream.
When using gst_util_uint64_scale_int_round() instead of just truncating the
sine sound correctly again.
https://bugzilla.gnome.org/show_bug.cgi?id=708345
It is quite possible that we might get PTS/DTS before the first
PCR/Offset observation.
In order to end up with valid timestamp we wait until at least one
stream was able to get a proper running-time for any PTS/DTS.
Until then, we queue up the pending buffers to push out.
Once we see a first valid timestamp, we re-evaluate the amount of
running-time elapsed (based on returned inital running-time and amount
of data/DTS queued up) for any given stream.
Taking the biggest amount of elapsed time, we set that on the packetizer
as the initial offset and recalculate all pending buffers running-time
PTS/DTS.
Note: The buffer queueing system can also be used later on for the
dvb fast start proposal (where we queue up all stream packets before
seeing PAT/PMT and then push them once we know if they belong to the
chosen program).
This allows:
* Better duration estimation
* More accurate PCR location
* Overall more accurate running-time location and calculation
Location and values of PCR are recorded in groups (PCROffsetGroup)
with notable PCR/Offset observations in them (when bitrate changed
for example). PCR and offset are stored as 32bit values to
reduce memory usage (they are differences against that group's
first_{pcr|offset}.
Those groups each contain a global PCR offset (pcr_offset) which
indicates how far in the stream that group is.
Whenever new PCR values are observed, we store them in a sliding
window estimator (PCROffsetGroupCurrent).
When a reset/wrapover/gap is detected, we close the current group with
current values and start a new one (the pcr_offset of that new group
is also calculated).
When a notable change in bitrate is observed (+/- 10%), we record
new values in the current group. This is a compromise between
storing all PCR/offset observations and none, while at the same time
providing better information for running-time<=>offset calculation
in VBR streams.
Whenever a new non-contiguous group is start (due to seeking for example)
we re-evaluate the pcr_offset of each groups. This allows detecting as
quickly as possible PCR wrapover/reset.
When wanting to find the offset of a certain running-time, one can
iterate the groups by looking at the pcr_offset (which in essence *is*
the running-time of that group in the overall stream).
Once a group (or neighbouring groups if the running-time is between two
groups) is found, once can use the recorded values to find the most
accurate offset.
Right now this code is only used in pull-mode , but could also
be activated later on for any seekable stream, like live timeshift
with queue2.
Future improvements:
* some heuristics to "compress" the stored values in groups so as to keep
the memory usage down while still keeping a decent amount of notable
points.
* After a seek compare expected and obtained PCR/Offset and if the
difference is too big, re-calculate position with newly observed
values and seek to that more accurate position.
Note that this code will *not* provide keyframe-accurate seeking, but
will allow a much more accurate PCR/running-time/offset location on
any random stream.
For past (observed) values it will be as accurate as can be.
For future values it will be better than the current situation.
Finally the more you seek, the more accurate your positioning will be.
The previous code could enter an infinite loop because the adapter state
could get out of sync with its mapped data state after sync was lost.
The code was pretty confusing so it's been rewritten to be clearer.
The easiest way to reproduce the infinite loop is to use the breakmydata
element before tsdemux to trigger a resync.
https://bugzilla.gnome.org/show_bug.cgi?id=708161
When outputting in AVC3 stream format, the codec_data should not
contain any SPS or PPS, because they are embedded inside the stream.
In case of avc->bytestream h264parse will push the SPS and PPS from
codec_data downstream at the start of the stream, at intervals
controlled by "config-interval" and when there is a codec_data change.
In the case of avc3->bytstream h264parse detects that there is
already SPS/PPS in the stream and sets h264parse->push_codec to FALSE.
Therefore avc3->bytstream was already supported, except for the stream
type.
In the case of bystream->avc h264parse will generate codec_data caps
from the parsed SPS/PPS in the stream. However it does not remove these
SPS/PPS from the stream. bytestream->avc3 is the same as bytestream->avc
except that the codec_data must not have any SPS/PPS in it.
|--------------+-------------+-------------------|
|stream-format | SPS in-band | SPS in codec_data |
|--------------+-------------+-------------------|
| avc | maybe | always |
|--------------+-------------+-------------------|
| avc3 | always | never |
|--------------+-------------+-------------------|
Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation
data (e.g. SPS, PPS). In AVC1 this data is placed in the initial MOOV box
(moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data goes in the
first sample of every fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
The prog-map property of mpegtsmux only allows you to group pids together in a program.
The program number set in the PAT/PMT tables cannot be set explicitly.
This patch will set the program number according to the prog-map.
If a program id of 0 is given, the first vacant program number starting from 1 will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=697239
Some streams had wrong values for the stream_id_extension, make sure
we only remember the valid ones.
For streams with PES_extension_field_length == 0, assume there's nothing
else.
For streams that state they have a TREF extension but don't have enough
data to store it, just assume it was produced by a non-compliant muxer
and skip the remaining data.
Only store remaining data in stream_id_extension_data instead of storing
data we already parse.
The Sequence Header Data Structure STRUCT_C for Advanced Profile
has only a one valid field which is the profile indicator. Don't
use the reserved fields for fps update like Simple/Main profile.
https://bugzilla.gnome.org/show_bug.cgi?id=705667
The Sequence Header Data Structure STRUCT_A for advanced profile
may be eight consecutive zero bytes.Don't try to override the
width and height values in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=705667
AIFF chunk size does not include the chunk header size (8 bytes), so the
SSND data size is equal to the chunk size minus the SSND header size (8
bytes).
https://bugzilla.gnome.org/show_bug.cgi?id=705675
Updating caps results in downstream elements potentially reconfiguring themselves
(such as decoders). If we do this in the middle of keyframes, we would result
in those elements being reconfigured and handling garbage until the next keyframe.
Instead of this only send (potentially) new codec_data when we have *both* SPS and
PPS.
https://bugzilla.gnome.org/show_bug.cgi?id=705333
If ever we lose sync, we were just checking for the next 0x47 marker ...
which might actually happen within a mpeg-ts packet.
Instead check for 3 repeating 0x47 at the expected packet size interval,
which the same logic we use when we initially look for the packet size.
We were only resetting the first 512 values of the lookup table instead
of the whole 8192.
This resulted in any PCR PID over 0x0200 ... ending up taking the first PCR
table around :(
ATSC ac3 streams are always guaranteed to be AC3 if EAC3 descriptor
is not present
If stream registration id is 'AC-3' then it's also guaranteed to be AC3.
Finally if AC3 descriptor is present it's guaranteed to be AC3.
Only silences a warning, but still.
We know we will not overflow 64 bits, therefore just use direct
multiplication/division instead of the scale method (trims usage from
50 instruction calls to 2/3).
Helps with debugging issues. And also remove unused variable (opcr)
This will also allow us in the future to properly detect:
* random-access location (to enable keyframe observation and
potentially seeking
* discont location (to properly handle resets)
* splice location (to properly handle new stream changes)
If a buffer was entirely clipped out (ie, it's out of the segment
entirely), we'll end up with a NULL buffer, which we don't want
to process/dereference.
The new seek handling re-creates the segment time information once it
has enough information after a seek.
The problem was that we'd completely ignore the requested rate. So store
that and use it in the newly created segment.
https://bugzilla.gnome.org/show_bug.cgi?id=694369
Make videotestsrc ! interlace ! $anything work again. Problem
was that upstream filter caps were passed which contained
interlace-mode=progressive, which doesn't intersect too well
with interlace's source pad template caps, leading to
not-negotiated errors.
The program_number attribute was overloaded, trying to indicate both
the currently playing program, and the program requested via the
"program-number" property. The end result was that setting the
property didn't work (see #690934).
I added a new requested_program_number field rather than reviving the
current_program_number field because it seemed this would result in
fewer changes overall and be less confusing. It breaks symmetry with
the "program-number" property, but it retains parallels with the likes
of program->program_number.
Because gst_ts_demux_reset is called after the properties have been
parsed, requested_program_number is initialised in gst_ts_demux_init.
Whether this is exactly the right place, I don't know.
Setting the program-number property does not affect which program
is actually being demuxed.
Moving the initialization of the program_number from
gst_ts_demux_reset to gst_ts_demux_init seems to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=690934
* Avoids handling twice the same seek (can happen with playbin and files
with subtitles)
* Set the sequence number of the segment event to the sequence number of
the seek event that generated it (-1 for the initial one).
The seeking start time is approximated from the seek offset in bytes
using the accumulated PCR observations, so on a VBR stream there might
be a big difference between the actual PCR and the estimated one after
the seek. This might result in a long wait to skip all out of segments
packets.
Instead we just recalculate the new segment to start at the first PTS
after the seek, so that playback starts immediatly.
The caps should always represent what the user is supposed to see.
So if there is a sequence_display_extension associated with the
stream then use the display_horizontal_size/display_vertical_size
to update the src caps (if they are less than the values provided
by sequence header).
https://bugzilla.gnome.org/show_bug.cgi?id=704009
This is actually a workaround (we'll be skipping the upcoming section)
This will only happen for sections where the beginning is located within
the last 8 bytes of a packet (which is the minimum we need to properly
identify any section beginning).
Later we should figure out a way to store those bytes and mark that
some analysis needs to happen. The probability of this happening is
too low for me to care right now and do that fix. There is a good chance
that section will eventually be repeated and won't end up on such border.
* packet.origts is no longer used since the PCR refactoring done ages ago
* known_packet_size is a duplicate of packet_size != 0
* caps was never used outside of the packetizer
Restore the original h264parser behaviour to report cropped dimensions
in size caps.
https://bugzilla.gnome.org/show_bug.cgi?id=694068
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
We had two issues with the previous code:
1) We were badly handling PUSI-flagged packets. We were discarding the
initial data (if pointer != 0) whereas we should have been accumulating
it with the previous data (if there was a continuity of course).
=> First series of information loss
2) We were not checking whether there were more sections after the end
of one (i.e. when the following byte was not a stuff byte).
This fixes those two issues.
Fixes#677443https://bugzilla.gnome.org/show_bug.cgi?id=677443
Until now we simply ignored those streams (since we couldn't do anything
with it anyway). Now that we have the mpegts library and we offload the
section handling to the application side we can properly identify and
extract them.
By default it is disabled for tsparse and enabled for tsdemux, but there is
a property to change that.
This should open the way to properly handle all private section streams,
including:
* DSM-CC
* MHEG
* Carousel data
* Metadata streams (though I haven't seen any of those in the wild)
* ... And all other specs/protocols making use of those
Partially fixes#560631
Migrate the code to use the new parser API based on GstMpegVideoPacket.
Also try to optimize gst_mpegv_parse_process_config() by using more of
GstMpegVideoPacket and determining the extension_start_code_identifier
prior to calling the parser function for that extension packet.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Since we now send all sections to the packetizer, we no longer need to do
anymore in-depth checks for the validity of a section.
The choice boils down to:
1) Is it from a known PES pid ? If so pass it on (which might be just pushing
downstream in the case of tsparse, or accumulating PES data for tsdemux)
2) Is it from a known SI pid ? If so pass it to the section packetizer
We still have some other stream types which haven't been ported, but
we will do so once we have defined the enums in the mpegts library.
Also add some FIXMEs regarding items discovered during analysis
* Only mpeg-ts section packetization remains.
* Improve code to detect duplicated sections as early as possible
* Add FIXME for various issues that need fixing (but are not regressions)
https://bugzilla.gnome.org/show_bug.cgi?id=702724
We use add_stream(stream_type:-1) to ensure a programs' PCR Stream is
also taken into account. For most programs this will re-use an
existing ES stream.
So only warn that we are re-adding a stream if it was already present
AND it is not to ensure the PCR stream is taken into account.
Only create subtables when needed. It was previously creating one every
single time ... to check if one was present.
And speed up code to detect whether a subtable was already present or not.
Overall makes section pushing 2 times faster.
In some cases (NIT on highly-populated DVB-C operator for example), there
will be more than one section emitted for the same subtable and version
number.
In order not to lose those updates for the same version number, we checked
against the CRC of the previous section we parsed.
The problem is that, while it made sure we didn't lose any information, it
also meant that if the same section came back (same version, same CRC) later
on we would re-process it, re-parse it and re-emit it.
This version improves on that by keeping a list of previously observed CRC
for identical PID/subtable/version-number and will only process sections if
they really were never seen in the past (as opposed to just before).
On a 30s clip, this brings down the number of NIT section parsing from 4541
down to 663.
https://bugzilla.gnome.org/show_bug.cgi?id=614479
First send stream-start, then caps, then segment.
The segment we push is from upstream in push-mode. If we work in pull-mode
then we initialize the base segment to BYTES.
https://bugzilla.gnome.org/show_bug.cgi?id=702422
Sync byte scan is incorrect for M2TS streams because the timestamp 4
bytes were not included in the flush size. This can result in an
infinite loop.
Rework the scan code to be clearer and work in all cases.
By adding the video-source-filter during construction time, rather then
patching it in later (*), we can greatly reduce the amount of caps involved
in negotation, speeding up pipeline creation.
I wrote this while working on speeding up the startup of cheese. My cheese
has been modified to add a capsfilter, filtering for only the configured
resolution, with that cheese patch + this patch, the pipeline creation time
goes from aprox 1.1 seconds to aprox 350ms. This is with a Logitech 9000
pro camera, which supports lots of different resolutions at many different
framerates per resolution, causing a caps "explosion" if not filtered.
*) Note the code for this is left in, as it is still necessary if the
video-source-filter is changed between a stop + re-start.
https://bugzilla.gnome.org/show_bug.cgi?id=701953
check_and_replace_src() was setting self->app_vid_src to NULL, which
means that an app setting the video-source property, and then starting,
stopping and re-starting the pipeline (ie to make changes to the
video-source-filter property) would after the restart no longer have
a video-source.
This patch fixes this by making gst_camerabin_setup_default_element return a
ref to the passed in user_element, rather then returning the user_element as
is, so that that ref can be passed on to the bin, and the app_vid_src ref
stays valid.
https://bugzilla.gnome.org/show_bug.cgi?id=701915
Current fallback to lost_sync seems to impede a delay to restore
sync. Let the parser parse and skip the private stream.
Here it contains the digital camera brand (in 2010 bytes)
and is repeated twice.
https://bugzilla.gnome.org/show_bug.cgi?id=697283
descriptors are stored as a GValueArray of GString. The downside is
that there is no way to "pass" ownership of a GValue to a GValueArray
which previously resulted in expensive copy/free of the (already expensive)
GString.
Here we estimate first the size of the GValueArray, then create it,
then directly use the GValue of that array.
Speeds up total SI parsing by ~30%
If rfb_decoder_new() allocates the decoder sructure, rfb_decoder_free()
should free the structure. We should not free the decoder when an
error occurs during connection - it holds lots of configuration/state
and will be freed later in finalize.
prepare_func will allocate a new buffer to replace the original
one. Instead of using gst_buffer_replace (which causes an extra
refcount increment on the new buffer), we just unref the original
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=699786
Don't send any source caps yet if we're still in
drop-buffers-until-we-get-a-sequence-header mode.
Fixes transmuxing of many MPEG-TS/PS streams into
formats which require things like width, height or
codec_data on the input caps.
Also fixes issues when using playbin with decoder
sinks that want width/height etc.
https://bugzilla.gnome.org/show_bug.cgi?id=695879
Since there is a conflict between the DCII stream type and BluRay
stream types, moved the processing of BluRay-specific stream types
to the beginning of the function. Only if a BluRay stream type
IS NOT found do we proceed to check the rest of the stream type
identifiers
Previous code was also "sort-of" handling a similar conflict between
BluRay AC3 audio and standard AC3 audio. Moved the special case BluRay
AC3 handling in the main switch statement to the new BluRay-specific
switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697892
The src element may not include information about whether
the data is parsed or not. Hence do not require parsed=false.
Fixes multipartdemux ! jpegparse ! ...
https://bugzilla.gnome.org/show_bug.cgi?id=697884
And if we detect a discontinuity there (like... when losing packets
or having MPEGTS over raw UDP with out-of-order packets) we just
drop the corresponding packet.
A future version could try to implement a re-ordering algorithm based
on that, similar to what rtpjitterbuffer does.
Backport fix for crashes and invalid writes in totem from libvisual
in -base, to minimise differences to version in -base and to make
sure the bug doesn't sneak back in later when the base class is
made public.
The shader code looks like it makes assumptions that are not
necessarily always true, even if they're true for now for the
existing elements, namly that pixel stride is 4, for example.
See https://bugzilla.gnome.org/show_bug.cgi?id=683527
gst_query_set_nth_allocation_pool() requires there to be a pool in the
query already. This is not always the case when we get the query from
upstream. Use gst_query_add_allocation_pool() instead in such case.
https://bugzilla.gnome.org/show_bug.cgi?id=681719
When converting the incoming segment from byte to time format,
don't just convert the start/stop/time values, but also change
the segment format to TIME.
https://bugzilla.gnome.org/show_bug.cgi?id=696361
Rework things a bit so that we can run over the midi events and fire callbacks
for each of them. We can then use that for calculating the duration and also for
doing playback.
Only parse as many tracks as specified in the header.
Fix default tempo;
Send MIDI tick events every 10ms
This filter converts interlaced content that was originally
telecine'd from 24 fps (or similar) progressive content. It works
approximately like videorate, but with awareness of interlacing.
It merges neighboring fields in the input interlaced stream with
the goal of minimizing combing artifacts, while keeping the output
framerate constant. If it cannot avoid combing artifacts, it will
reconstruct the image from a single field. Note that this filter
does not autodetect the framerate, but will automatically fixate
at 24 fps.
A non-live element is supposed to continue streaming in the paused state so
don't stop the tasks when going to paused.
We also always want to start the update task after we prerolled enough data,
not only in the playing state.
The current code is memsetting the GstVideoFrame.data address to 0s (which
causes a segfault). This member is actually an array of data buffers (one for
each plane). This fix iterates over each data plane to clear them all.
https://bugzilla.gnome.org/show_bug.cgi?id=695655
API is now in baseparse in gstreamer.
Timestamps in MPEG-TS streams are based on the last timestamp
before the start code of the picture. GstBaseParse sets the
timestamp based on the beginning of the sequence header, if
one exists before the picture. This fixes the case where the
timestamp occurs in the MPEG-TS stream between the seq header
and picture start code.
Timestamps in MPEG-TS streams are based on the last timestamp
before the start code of the picture. GstBaseParse sets the
timestamp based on the beginning of the sequence header, if
one exists before the picture. This fixes the case where the
timestamp occurs in the MPEG-TS stream between the seq header
and picture start code.
In the sink event handler we end up sending multiple EOS
events per pad. Don't return FALSE when sending the
second EOS on an already-EOS pad fails. Not sure if there
was a reason for sending a second EOS, so leaving the
code in there for now, but assume all went fine if there
are source pads, which is slightly less wrong than before.
This function needs work.
Otherwise we will intersect with the srcpad template caps and add all the caps fields
that the parser will ever set, no matter if downstream restricts this field or not.
This requires upstream to set this field on the caps to successfully negotiate.
https://bugzilla.gnome.org/show_bug.cgi?id=690184
This allows filtering out videos for hardware decoders that do not
support GMC at all or only support a limited number of sprite warping
points (usually 1).
A crash occured after pushing buffers and changing mpegtsmux state to
NULL/READ and then back to PLAYING/PAUSED.
The crash was caused by holding a dangling pointer in the MpegTsMux
program table.
Additionally stream headers were leaked when resetting the element:
mux->streamheader set to NULL in mpegtsmux_reset() before it's released
later in the same function.
Added a unit test: test_multiple_state_change
https://bugzilla.gnome.org/show_bug.cgi?id=689107
Right now decodebin will concider the pad template caps as fixed and if a decoder
has restriction on for example height/width it won't be autoplugged because
gst_caps_is_subset fails as those fields are missing from the pad template caps.
We fix the issue here making sure that the pad caps are fixed using data from
the stream.
Also reset segment info and drop the segment event when demuxer is
flushed.
Restore demuxer segment with the info stored in base when demuxer is
going to push data again if needed.
Drop code to recover the segment info from base in the initial program
becauses it's superseded by the new code.
Ensure the chain is not running before reset the state to avoid race
conditions and random corruptions downstream.
Also fixes segfaults in the packetizer due wrong available values that
causes gst_adapter_map to return a NULL pointer.
This reverts commit e14e310f71.
Would be better move the packetizer flushing to FLUSH_STOP and avoid
the race that way. Without introducing a memory barrier that could
have impact in the performance.
When dealing with non-time based push-mode streams, we need to revert
to using the offset-based PCR/PTS estimation logic of packetizer.
This solves uses cases such as:
pushfile:// ! tsdemux
src ! queue ! tsdemux
https://bugzilla.gnome.org/show_bug.cgi?id=687178
Sometimes the codec_data buffer for simple/main pushed by asfdemux is 5 bytes
instead of 4. When that happens, codec_data is still valid but it seems to have
one 0x00 trailing byte. Might be a bug in the demuxer, needs more investigation.
additional_copy_info: need to get rid of the highest
bit, not the lowest one
program_packet_sequence_counter: also need to get rid
of the highest bit instead of multiplying with a random
value
original_stuff_length: want to AND 0x3f to extract the
lowest 6 bits, not multiply by it.
None of these fields are actually used though, so these
should not have caused any issues.
This will deadlock. Also make sure to always post an error message
if required before pausing tasks from the task function.
Should fix another bunch of deadlocks.
Conflicts:
gst/hls/gsthlsdemux.c
... to use the src_segment as a basis for the sent segment,
thereby properly conveying accumulated base_time etc.
Also ensure src_segment is only adjusted once, so that
all downstream segments are identical to avoid stream
misalignment.
The name was updated on the 0.10 -> 1.0 transition, but the
gst_bin_remove was still using the old name, causing an assertion
when replacing video-source-filter
https://bugzilla.gnome.org/show_bug.cgi?id=681564
I was also vaguely forced to overhaul some bits and pieces and mess with
the data structures. This was mostly due to caps not being part of
buffers and so I had to switch to using GstVideoFrame and GstVideoInfo.
All these formats have re-ordered PTS which the base class gets
wrong. It's better to leave them blank and let the decoder sort it
out. Better yet would be to track and interpolate the timestamps
in the subclasses (FIXME)
Handle Gap events the way we used to handle segment updates
and advance/fill in the video stream accordingly. Fixes
'still' menus which aren't DVD still frames, but are just a
single frame with accompanying audio.
Change the way the pixel-aspect-ratio is computed by
interpreting the sequence header aspect ratio info
as MPEG-1 values until a sequence extension or
sequence display extension is seen, and then updating
the sequence header struct accordingly.
Fixes incorrect anamorphic display on some MPEG-2 (DVD)
sequences.
Anonymous union is an ISO C (2011) feature that is not exposed in
compilers strictly conforming to the previous standard.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
opus + jpegformat plugin builds fail when gstreamer is configured with
--disable-gst-debug as they are checking the GST_DISABLE_DEBUG symbol
instead of GST_DISABLE_GST_DEBUG.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
https://bugzilla.gnome.org/show_bug.cgi?id=683850
We have removed things like protocol=gdp in the tcp elements
in favour of explicit gdppay/depay elements, so there's no need
to keep a public API and library for now. We can still add it
back later. Someone needs to think hard about 0.11 and gdp
anyway one of these days.
Make a new method to allocate a buffer + memory that takes the allocator and the
alignment as parameters. Provide a macro for the old method but prefer to use
the new method to encourage plugins to negotiate the allocator properly.
Improve GstSegment, rename some fields. The idea is to have the GstSegment
structure represent the timing structure of the buffers as they are generated by
the source or demuxer element.
gst_segment_set_seek() -> gst_segment_do_seek()
Rename the NEWSEGMENT event to SEGMENT.
Make parsing of the SEGMENT event into a GstSegment structure.
Pass a GstSegment structure when making a new SEGMENT event. This allows us to
pass the timing info directly to the next element. No accumulation is needed in
the receiving element, all the info is inside the element.
Remove gst_segment_set_newsegment(): This function as used to accumulate
segments received from upstream, which is now not needed anymore because the
segment event contains the complete timing information.
Hide the GstStructure of the event in the implementation specific part so that
we can change it.
Add methods to check and make the event writable.
Add a new method to get a writable GstStructure of the element.
Avoid directly accising the event structure.
So run-time bindings can introspect the names correctly (we abuse this
field as description field only in elements, not for public API
(where the description belongs into the gtk-doc chunk).
https://bugzilla.gnome.org/show_bug.cgi?id=629946
Adds that warning to configure.ac
Includes a tiny change of the GST_BOILERPLATE_FULL() macro:
The get_type() function is no longer declared before being defined.
https://bugzilla.gnome.org/show_bug.cgi?id=611692
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
Don't write to the same region of memory as a uint64 and uint16
as this breaks strict aliasing rules and apparantly breaks on PPC
and s390. Thanks to Sjoerd Simons for analysing. Fixes bug #348114.
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
(gst_dp_packet_from_event_1_0):
When calculating GDP body CRC, use the correct pointer.
Fixes part of #522401.
Original commit message from CVS:
2006-08-11 Andy Wingo <wingo@pobox.com>
* configure.ac:
* libs/gst/dataprotocol/dataprotocol.c: (gst_dp_packetizer_new):
* tests/check/libs/gdp.c: (gst_dp_suite): GST_DISABLE_DEPRECATED
is only for users of API that don't want to see deprecated
functions in the headers; people that want to compile out
deprecated code should pass -DGST_REMOVE_DEPRECATED into the
CFLAGS. Fixes the build of multifdsink, or will soon..
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
(gst_dp_header_from_buffer_any), (gst_dp_packet_from_caps_any),
(gst_dp_crc), (gst_dp_header_payload_length),
(gst_dp_header_payload_type), (gst_dp_packet_from_event),
(gst_dp_packet_from_event_1_0), (gst_dp_buffer_from_header),
(gst_dp_caps_from_packet), (gst_dp_event_from_packet_0_2),
(gst_dp_event_from_packet), (gst_dp_validate_header),
(gst_dp_validate_payload):
Make debug category static
Constify the crc table.
Do some more arg checking in public functions.
Fix some docs and do some small cleanups.
* tests/check/libs/gdp.c: (GST_START_TEST), (gst_dp_suite):
Add some more checks to see if GDP deals with bogus input.
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
(gst_dp_event_from_packet_1_0):
Fixes#347337: failure to deserialize event packets with
empty payload (only event type)
Original commit message from CVS:
* docs/README:
* docs/images/gdp-header.svg:
add a gdp image
* docs/libs/Makefile.am:
* docs/libs/gdp-header.png:
* libs/gst/dataprotocol/dataprotocol.c:
add it to the API docs
* docs/manual/intro-motivation.xml:
fix typo
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
(gst_dp_header_from_buffer), (gst_dp_packet_from_caps),
(gst_dp_packet_from_event):
factor out CRC code
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
(gst_dp_header_from_buffer), (gst_dp_packet_from_caps),
(gst_dp_packet_from_event):
factor out some common header init code
Original commit message from CVS:
* docs/libs/gstreamer-libs-sections.txt:
* docs/libs/tmpl/gstdataprotocol.sgml:
* libs/gst/dataprotocol/dataprotocol.c: (gst_dp_crc):
* libs/gst/dataprotocol/dataprotocol.h:
API: make gst_dp_crc() public
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c: (gst_dp_packet_from_event),
(gst_dp_event_from_packet):
Fixes in reading/writing events over GDP (not currently used?) -
dereferencing NULL events for unknown/invalid event types, memory
leak, and change g_warning to GST_WARNING.
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
Fix docs for dataprocotol to not get the return types completely
wrong for a few functions.
Original commit message from CVS:
2005-10-13 Andy Wingo <wingo@pobox.com>
* libs/gst/dataprotocol/dataprotocol.c (gst_dp_packet_from_caps):
Fix Timmeke Waymans bug.
(gst_dp_caps_from_packet): Make sure we pass a NUL-terminated
string of the proper length to gst_caps_from_string. There's a
potential for, before this fix, that this could cause someone
connecting over the network to cause a segfault if the payload is
not NUL-terminated.
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c:
(gst_dp_header_from_buffer), (gst_dp_packet_from_caps),
(gst_dp_packet_from_event):
* libs/gst/dataprotocol/dataprotocol.h:
* libs/gst/dataprotocol/dp-private.h:
It's about time we bump the version number.
Since event types don't fit in the guint8 anymore describing
the payload type, make payload type 16 bits wide.
Original commit message from CVS:
* libs/gst/dataprotocol/dataprotocol.c: (gst_dp_packet_from_event),
(gst_dp_event_from_packet):
Fix serialization of seek events.
Original commit message from CVS:
Next big merge.
Added GstBus for mainloop integration.
Added GstMessage for sending notifications on the bus.
Added GstTask as an abstraction for pipeline entry points.
Removed GstThread.
Removed Schedulers.
Simplified GstQueue for multithreaded core.
Made _link threadsafe, removed old capsnego.
Added STREAM_LOCK and PREROLL_LOCK in GstPad.
Added pad blocking functions.
Reworked scheduling functions in GstPad to prepare for
scheduling updates soon.
Moved events out of data stream.
Simplified GstEvent types.
Added return values to push/pull.
Removed clocking from GstElement.
Added prototypes for state change function for next merge.
Removed iterate from bins and state change management.
Fixed some elements, disabled others for now.
Fixed -inspect and -launch.
Added check for GstBus.
Original commit message from CVS:
First THREADED backport attempt, focusing on adding locks and
making sure the API is threadsafe. Needs more work. More docs
follow this week.
Original commit message from CVS:
2005-02-18 Zaheer Abbas Merali <zaheerabbas at merali dot org>
* libs/gst/dataprotocol/dataprotocol.c: (gst_dp_dump_byte_array):
Allocate the 1 byte more memory that was forgotten!!!!!
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the
needed Android.mk files.
Androgenizer can be found here:
http://git.collabora.co.uk/?p=user/derek/androgenizer.git
There's not much point in using GST_DEBUG_FUNCPTR with GObject
virtual functions such as get_property, set_propery, finalize and
dispose, since they'll never be used by anyone anyway. Saves a
few bytes and possibly a sixteenth of a polar bear.
Original commit message from CVS:
Patch by: Antoine Tremblay <hexa00 at gmail dot com>
* gst/gdp/gstgdppay.c: (gst_gdp_pay_reset):
Fix a buffer memleak and remove a confusing and wrong debug output.
Fixes bug #538663.
Original commit message from CVS:
Patch by: Antoine Tremblay <hexa00 at gmail dot com>
* gst/gdp/gstgdppay.c: (gst_gdp_pay_reset_streamheader):
Don't set caps on the buffers that contain a copy of the buffer
including the caps of them resulting in an always increasing refcount
of the caps and insanely large caps. Instead include a buffer without
caps in the new caps. Fixes bug #536475.
Original commit message from CVS:
Patch by: Antoine Tremblay <hexa00 at gmail dot com>
* gst/gdp/gstgdppay.c: (gst_gdp_pay_chain):
Close a buffer memory leak. Fixes bug #534071.
Original commit message from CVS:
* gst/gdp/gstgdppay.c (gst_gdp_pay_chain):
* tests/check/pipelines/streamheader.c (tag_event_probe_cb,
GST_START_TEST, buffer_probe_cb, GST_START_TEST):
Fix a bug where serialized IN_CAPS buffers needed to be set IN_CAPS.
Original commit message from CVS:
* gst/gdp/gstgdppay.c: (gst_gdp_pay_chain),
(gst_gdp_pay_sink_event):
Make sure we set the IN_CAPS flag correctly.
* gst/tcp/gstmultifdsink.c: (gst_multi_fd_sink_render):
Get the IN_CAPS flag before we call functions that mess with the flags.
Original commit message from CVS:
* gst/gdp/gstgdppay.c (gst_gdp_pay_reset_streamheader,
gst_gdp_pay_chain, gst_gdp_pay_sink_event):
Only stamp buffers with offset/offset_end right before they get
pushed. This ensures offset continuity, which was not the case
before as shown by
gst-launch -v -m audiotestsrc num-buffers=10 ! audioconvert ! vorbisenc ! gdppay ! identity check-imperfect-offset=TRUE ! fakesink silent=TRUE
Original commit message from CVS:
* gst/gdp/gstgdppay.c: (gst_gdp_pay_reset),
(gst_gdp_pay_reset_streamheader), (gst_gdp_pay_chain):
Fix memory leaks and misleading debug messages, add a couple of
comments.
* gst/tcp/gstmultifdsink.c: (gst_multi_fd_sink_get_stats),
(gst_multi_fd_sink_render):
Do not use gst_buffer_make_writable() in a basesink render method,
as it may incorrectly unref the buffer. Instead, use convoluted
dance to avoid copying the buffer except when we need to.
Original commit message from CVS:
2006-08-04 Zaheer Abbas Merali <zaheerabbas at merali dot org>
* gst/gdp/gstgdpdepay.c: (gst_gdp_depay_chain):
Fix event parsing by gdpdepay. Fixes#349916.
Original commit message from CVS:
* gst/gdp/gstgdpdepay.c: (gst_gdp_depay_init),
(gst_gdp_depay_sink_event), (gst_gdp_depay_chain):
Consume all events except EOS because we generate events from
the gdp payload instead. Fixes#349204
Original commit message from CVS:
* gst/gdp/gstgdpdepay.c: (gst_gdp_depay_init):
proxying get/set caps is the wrong thing to do, since we really
do change caps quite fundamentally
* tests/check/elements/gdpdepay.c:
* tests/check/elements/gdppay.c:
remove declaration of buffers, it's already done in gstcheck.h
Original commit message from CVS:
2006-07-17 Thomas Vander Stichele <thomas at apestaart dot org>
* gst/gdp/gstgdpdepay.c: (gst_gdp_depay_class_init):
* gst/gdp/gstgdppay.c: (gst_gdp_pay_class_init),
remove parent_class setting, BOILERPLATE does this
(gst_gdp_pay_reset_streamheader):
fix typo in comment
Original commit message from CVS:
* docs/plugins/Makefile.am:
* docs/plugins/gst-plugins-bad-plugins-docs.sgml:
* docs/plugins/gst-plugins-bad-plugins-sections.txt:
add more plugins and elements to docs
* gst/gdp/gstgdpdepay.c: (gst_gdp_depay_chain):
fix segfaults due to wrong g_free
add example
* gst/gdp/gstgdppay.c:
add example
Original commit message from CVS:
* configure.ac:
enable building of GDP elements
* gst/gdp/gstgdpdepay.c: (gst_gdp_depay_chain):
* gst/gdp/gstgdppay.c: (gst_gdp_pay_class_init),
(gst_gdp_pay_init), (gst_gdp_buffer_from_caps),
(gst_gdp_pay_buffer_from_buffer), (gst_gdp_buffer_from_event),
(gst_gdp_pay_reset_streamheader), (gst_gdp_pay_sink_event),
(gst_gdp_pay_set_property), (gst_gdp_pay_get_property),
(gst_gdp_pay_change_state):
* gst/gdp/gstgdppay.h:
add version 1.0
Original commit message from CVS:
* gst/gdp/gstgdppay.c: (gst_gdp_pay_class_init),
(gst_gdp_pay_init), (gst_gdp_buffer_from_caps),
(gst_gdp_pay_buffer_from_buffer), (gst_gdp_buffer_from_event),
(gst_gdp_pay_reset_streamheader), (gst_gdp_pay_chain),
(gst_gdp_pay_sink_event), (gst_gdp_pay_set_property),
(gst_gdp_pay_get_property):
add crc-header and crc-payload properties
don't error out on some things that are recoverable
* tests/check/elements/gdppay.c: (GST_START_TEST), (gdppay_suite):
add test for crc
This property causes hlssink to push a force key unit event upstream
every target-duration seconds. This is for simple automatic segmenting.
To disable it, set the property to 0 and push the force key unit event
manually.
Reply with ANY caps to ensure linking the internal src pad. This
might need more attention later, to reply with the real upstream caps
for the currently active element.
Change all the gst_pad_get_parent() calls to a cast to the
passed parent variable where appropriate, and don't unref,
including the extra unref in the
gst_flups_demux_sink_activate_push() function.
Add support for GstVideoMeta and GstVideoFrame. Remove some redundant fields
that are also in GstVideoInfo. Don't disable the shader code, it does not
look broken.
This can be used to notify subclasses no more data is expected this
round.
tsparse will use it to push whole buffers (without copy) on the main
source pad.
It could also be used later to decide whether to push pending data
in order to reduce latency.
When there is no extension header, the repeat_count variable is left to 0 and
then the duration on the output buffers is calculated wrongly. Because the
duration is used to interpolate output timestamps, the output timestamps are
also wrong, causing bad framerates.
See https://bugzilla.gnome.org/show_bug.cgi?id=681535
Add a src pad event handler function that filters reconfigure events to
trigger the renegotiation code paths in the mode-specific start-capture
phase.
This is to work towards fixing unit tests but more work is needed.
need to pass a GstSample to the utilitary preview buffer post functions
as a GstBuffer doesn't have caps anymore. The GstSample has the GstCaps
and it is used to inform the preview's pipeline about the format of the
input, before it gets converted to the user's requested output format.
Avoids consistently failing to detect that a packet is complete, which
would then only be pushed upon the start of a next packet, which leads
to quite a delay in case of a sparse (subtitle) stream.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=666674
gstdvbsuboverlay.c:772:15: error: pointer targets in passing argument 5 of 'gst_segment_clip' differ in signedness
/home/tpm/gst/0.11/gstreamer/gst/gstsegment.h:192:14: note: expected 'guint64 *' but argument is of type 'gint64 *'
gstdvbsuboverlay.c:772:15: error: pointer targets in passing argument 6 of 'gst_segment_clip' differ in signedness
In particular, pass buffer timestamp (pts) to dvb_sub, and then clip
and convert to running time when the duration (timeout) is known after
decoding it.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=660233
Conflicts:
gst/dvbsuboverlay/gstdvbsuboverlay.c
... which is upon receiving new data with different PTS spec-wise,
or optionally upon each packet of subtitle data if desired by property.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=669310
Conflicts:
gst/dvbsuboverlay/gstdvbsuboverlay.c
The check for when to not memset was checking on an undeterministic 'bits' variable value,
which is only meant to be used inside the loop earlier when it is supposed to check if
clut_index is 1 together with non_mod set, as per spec:
"non_modifying_colour_flag: If set to '1' this indicates that the CLUT entry value '1'
is a non modifying colour. When the non modifying colour is assigned to an object pixel,
then the pixel of the underlying region background or object shall not be modified. This
can be used to create "transparent holes" in objects."
https://bugzilla.gnome.org/show_bug.cgi?id=666352
