| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
flacparse)
|
|
Sending the flush-start event forward before taking the stream lock actually
works, in contrast to deadlocking in downstream preroll_wait (hunk 1).
After that we get the chain function being stuck in a busy loop. This is fixed
by updating the minimum frame size inside the synchronization loop because the
subclass asks for more data in this way (hunk 2).
Finally, this leads to a very probable crash because the subclass can find a
valid frame with a size greater than the currently available data in the
adapter. This makes the subsequent gst_adapter_take_buffer call return NULL,
which is not expected (hunk 3).
|
|
If newsegment is sent (too) early, caps may not yet be fixed/set,
and downstream may not have been linked.
|
|
Baseparse internaly breaks the semantics of a _chain function by calling it with
buffer==NULL. The reson I belived it was okay to remove it was that there is
also an unchecked access to buffer later in _chain. Actually that code is wrong,
as it most probably wants to set discont on the outgoing buffer.
|
|
Accordifn to docs for GstPadChainFunction buffer cannot be NULL. If we would
leave the check, we would also need more such check below.
|
|
Fix the return value of the default parse_frame function in both
copies of GstBaseParse
|
|
Original commit message from CVS:
* gst/aacparse/gstbaseparse.c:
* gst/amrparse/gstbaseparse.c:
Fix baseparse type name.
|
|
Original commit message from CVS:
* configure.ac:
* gst/aacparse/Makefile.am:
* gst/aacparse/gstaacparse.c:
* gst/aacparse/gstaacparse.h:
* gst/aacparse/gstbaseparse.c:
* gst/aacparse/gstbaseparse.h:
* gst/amrparse/Makefile.am:
* gst/amrparse/gstamrparse.c:
* gst/amrparse/gstamrparse.h:
* gst/amrparse/gstbaseparse.c:
* gst/amrparse/gstbaseparse.h:
Add two new baseparse based parsers (aac and amr) from Bug #518857.
|
