A context can create a GLsync object that can be waited on in order
to ensure that GL resources created in one context are able to be
used in another shared context without any chance of reading invalid
data.
This meta would be placed on buffers that are known to cross from
one context to another. The receiving element would then wait
on the sync object to ensure that the data to be used is complete.
gst_video_info_set_format() will reset the complete video-info, but
we want to keep values like the PAR, colorimetry and chroma site.
Otherwise we risk setting different values on the srcpad caps than
what is actually inside the buffers.
Otherwise we might negotiate from the sinkpad streaming threads at
the same time as on the srcpad streaming thread, and then all kinds
of crazy bugs happen that don't make any sense at all.
This gives more flexibility to the subclasses and permits to remove the
GstVideoAggregatorClass->disable_frame_conversion ugly API.
WARNING: This breaks the API as it removes the disable_frame_conversion
field
API:
+ GstVideoAggregatorClass->find_best_format
+ GstVideoAggregatorPadClass->set_format
+ GstVideoAggregatorPadClass->prepare_frame
+ GstVideoAggregatorPadClass->clean_frame
- GstVideoAggregatorClass->disable_frame_conversion
https://bugzilla.gnome.org/show_bug.cgi?id=740768
With the current code, we will end up setting the preferred downstream
format as the srcpad format, and it might not be accepted by the next
sinkpad to be added. We should instead let the next sinkpad reconfigure
everything.
Floating point numbers are written differently in different
locales, e.g. in many countries 1/2 = 0,5 instead of 0.5, and
strtod will not be able to parse "0.5" correctly in such a
locale.
Otherwise the caps of the pad might change while the subclass still works with
a buffer of the old caps, assuming the the current pad caps apply to that
buffer. Which then leads to crashes and other nice effects.
https://bugzilla.gnome.org/show_bug.cgi?id=740376
Otherwise interesting things will happen in Cocoa applications, like
infinite event loops that block the NSApplication loop forever.
This was only needed for GNUStep and thus can safely be removed now.
Until gcc and GNUStep properly support Objective-C blocks and other
"new" features of Objective-C we can't properly support them without
making the code much more ugly.
https://bugzilla.gnome.org/show_bug.cgi?id=739152
It's architecture dependent and should not be placed into the include
directory as the assumption is that all those headers are architecture
independent.
https://bugzilla.gnome.org/show_bug.cgi?id=739767
Otherwise when resizing the window you will also get messages like:
class NSConcreteMapTable autoreleased with no pool in place - just leaking
class NSConcreteValue autoreleased with no pool in place - just leaking
class NSConcreteValue autoreleased with no pool in place - just leaking
class __NSCFDictionary autoreleased with no pool in place - just leaking
Need to set the ':' as the reshape method now takes one parameter.
For the story, the GstGLNSView was previously inheriting from
NSOpenGLView which has a reshape function without any parameter.
Now the GstGLNSView inherits from NSView and we re-use the reshape
function manually.
Use the reshape function after being defined. The other way
would have been to declare the reshape function in the header.
gstglwindow_cocoa.m: In function '-[GstGLNSView drawRect:]':
gstglwindow_cocoa.m:555: warning: 'GstGLNSView' may not respond to '-reshape'
gstglwindow_cocoa.m:555: warning: (Messages without a matching method signature
gstglwindow_cocoa.m:555: warning: will be assumed to return 'id' and accept
gstglwindow_cocoa.m:555: warning: '...' as arguments.)
GTK-Doc uses a special syntax for code documentation. A multiline comment that
starts with an additional '*' marks a documentation block that will be processed
by the GTK-Doc tools. So GTK-Doc is confused if a comment block starts with that
additional '*' but isn't meant to be processed. Removing this additional '*'.
https://bugzilla.gnome.org/show_bug.cgi?id=739444
Both _parse_atsc_mgt() and _parse_atsc_vct () change the value of the variable
data just before returning. The new value is never used since data is a pointer
declared at the beginning of the function and going out of scope just after the
new value is stored.
https://bugzilla.gnome.org/show_bug.cgi?id=739404
Identify SVC NAL units and tag them as such. This is necessary for
gst_h264_parser_parse_slice_hdr() to fail gracefully, if the user
did not perform the check himself.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix copy-paste error in gst_h264_sps_mvc_copy() where num_anchor_refs_l0
and num_non_anchor_refs_l0 were incorrectly initialized from list1.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Always set a default NALU extension type, and override it
when we find a supported extension, to avoid having it unset/random
for unsupported NALU extensions
This parses the frame_packing_arragement() payload in SEI message.
This information can be used by decoders to appropriately rearrange the
samples which belong to Stereoscopic and Multiview High profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=685215
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
gstglwindow_cocoa.m: In function '-[GstGLNSView drawRect:]':
gstglwindow_cocoa.m:555: warning: 'GstGLNSView' may not respond to '-reshape'
gstglwindow_cocoa.m:555: warning: (Messages without a matching method signature
gstglwindow_cocoa.m:555: warning: will be assumed to return 'id' and accept
gstglwindow_cocoa.m:555: warning: '...' as arguments.)
Audiomixer blocksize, cant be 0, hence adjusting the minimum value to 1
timeout value of aggregator is defined with MAX of MAXINT64,
but it cannot cross G_MAXLONG * GST_SECOND - 1
Hence changed the max value of the same
https://bugzilla.gnome.org/show_bug.cgi?id=738845
In simple profile, level set to 0 or 2 indicate low and medium level
respectively. In main profile, level set to 0, 2 or 4 indicate low,
medium and high level respectively.
Level values are defined in Annex J.1.2 of the SMPTE 421M.
https://bugzilla.gnome.org/show_bug.cgi?id=738230
Using NSApp directly seems to confuse something, as the compiler
was expecting an id<NSFileManagerDelegate>. Switched to using
[NSApplication sharedApplication], and specified the delegate
protocol on the window class as well.
https://bugzilla.gnome.org/show_bug.cgi?id=738740
Determines the amount of time that a pad will wait for a buffer before
being marked unresponsive.
Network sources may fail to produce buffers for an extended period of time,
currently causing the pipeline to stall possibly indefinitely, waiting for
these buffers to appear.
Subclasses should render unresponsive pads with either silence (audio), the
last (video) frame or what makes the most sense in the given context.
- The shader was outputing the wrong values compared with raw
videotestsrc.
- deal with the texture edge properly.
- properly sample the 2x1 rectangle for the u and v values
- don't double sample the y value
The previous implementation kept accumulating GSources,
slowing down the iteration and leaking memory.
Instead of trying to fix the main context flushing, replace
it with a GAsyncQueue which is simple to flush and has
less overhead.
https://bugzilla.gnome.org/show_bug.cgi?id=736782
The aggregator.segment is not to be initialized by the subclasses but
by the aggregator itself. Moreover, initializing it on start would make
us loose the information coming from the initial seek.
Without a lock that is taken in FLUSH_START we had a rare race where we
end up aggregating a buffer that was before the whole FLUSH_START/STOP
dance. That could lead to very wrong behaviour in subclasses.
We should be able to always keep the VIDEO_AGGREGATOR_LOCK while
negotiating caps, this patch introduce that change.
That also implies that we do not need the SETCAPS_LOCK anymore because
now VIDEO_AGGREGATOR_LOCK guarantees that setcaps is not called from
several threads and the gst_aggregator_set_caps method is now
protected.
https://bugzilla.gnome.org/show_bug.cgi?id=735042
Avoiding to be in an inconsistent state where we do not have
actual negotiate caps set as srccaps and leading to point where we
try to unref ->srccaps when they have already been set to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=735042
This is about converting the format, not about converting any widths and
heights. Subclasses are expected to handler different resolutions themselves,
like the videomixers already do properly.
The visible rect and bounds might be the same as before, but Cocoa
might've changed our viewport without us nothing. This happens if
you hide the view and show it again.
This is only for non-Cocoa apps but previously caused a 2 second
waiting during startup for Cocoa apps. This is unacceptable.
Instead we now check a bit more extensive if something actually
runs on the GLib default main context, and if not don't even
bother waiting for something to happen from there.
Otherwise we could pass on a RGBA formatted buffer and downstream would
misinterpret that as some other video format.
Fixes pipelines of the form
gleffects ! tee ! xvimagesink
Allows callers to properly reference count the buffers used for
rendering.
Fixes a redraw race in glimagesink where the previous buffer
(the one used for redraw operations) is freed as soon as the next
buffer is uploaded.
1. glimagesink uploads in _prepare() to texture n
1.1 glupload holds buffer n
2. glimagesink _render()s texture n
3. glimagesink uploads texture n+1
3.1 glupload free previous buffer which deletes texture n
3.2 glupload holds buffer n+1
4. glwindow resize/expose
5. glimagesink redraws with texture n
The race is that the buffer n (the one used for redrawing) is freed as soon as
the buffer n+1 arrives. There could be any amount of time and number of
redraws between this event and when buffer n+1 is actually rendered and thus
replaces buffer n as the redraw source.
https://bugzilla.gnome.org/show_bug.cgi?id=736740
sequence-layer is serialized in little-endian byte order except for
STRUCT_C which is serialized in big-endian byte order.
But since STRUCT_A and STRUCT_B fields are defined as unsigned int msb
first, we have to pass them as big-endian to their parsing function. So
we basically use temporary buffers to convert them in big-endian.
See SMPTE 421M Annex J and L.
https://bugzilla.gnome.org/show_bug.cgi?id=736871
