Set the data field in the flush_pkt to the pointer to the actual packet.
The field needs to contain a valid unique pointer, no read nor writes
are ever made to it.
If there is a sample_aspect_ratio in the stream, then apply it to every
decoded frame in the same way as avconv does. This also makes sure that
the avfilter chain has access to the aspect ratio.
Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Currently it takes a mask and value, such that options for which
(flags & mask) == value.
Change it to take required flags and forbidden flags instead. This is
shorter and simpler to understand.
For reading from normal files on disk, the queue limits for
demuxed data work fine, but for reading data from realtime
streams, they mean we're not reading from the input stream
at all once the queue limit has been reached. For TCP streams,
this means that writing to the socket from the peer side blocks
(potentially leading to the peer dropping data), and for UDP
streams it means that our kernel might drop data.
For some protocols/servers, the server initially sends a
large burst with data to fill client side buffers, but once
filled, we should keep reading to avoid dropping data.
For all realtime streams, it IMO makes sense to just buffer
as much as we get (rather in buffers in avplay.c than in
OS level buffers). With this option set, the input thread
should always be blocking waiting for more input data,
never sleeping waiting for the decoder to consume data.
Signed-off-by: Martin Storsjö <martin@martin.st>
Do not assume avpacket and the decoded frames are independent.
To be absolutely sure and not sprinkle av_free_packet around the code
the call had been placed before getting the frame and on the error path.
This allows passing the right options to encoders when there's more
than one encoder for a certain codec id.
Signed-off-by: Martin Storsjö <martin@martin.st>
We do not allow user filters, so avtools shouldn't use them either.
It also allows to reuse buffer management code from avconv, thus
reducing duplication.
SDL only supports s16 sample format and a limited number of channel layouts.
Some versions of SDL on some systems support 4-channel and 6-channel output,
but it's safer overall to downmix any layout with more than 2 channels to
stereo.
This way we don't require a clearly defined corresponding input stream.
The result for the xwd test changes because rgb24 is now chosen instead
of bgra.
