The issue is that, when the main packet data buffer is changed, streamcopy
uses a temporary new packet to store that buffer, frees the old packet, and
replace it with the new packet.
However, in doing so, it forgets about the side data, which gets freed, but
is still needed and referenced. Then, when the packet gets freed again in
the normal code path, it attempts to free its side data which has already
been freed.
Therefore, simply avoid the first free on side data by removing that side
data from the packet.
Fixes ticket #3773.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3f3232a371cc88696184d9aef1f812656264e56c':
avconv: set the output stream timebase
Conflicts:
ffmpeg.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Commit fc9c857c introduced deadlock regression when processing too many inputs:
ffmpeg $(seq -f " -f lavfi -i aevalsrc=0:d=%.0f" 70) -vf concat=n=70:v=0:a=1 -f null -
Happens for different number of inputs, depending on available memory size,
overcommit settings, ulimits, etc. Easily noticeable for 32-bit builds,
that exhaust address space allocating 8-10 MB stack for each thread.
Earlier ffmpeg versions exited with unhelpful "Conversion failed!" message.
This patch fixes both problems: it frees the queue to prevent deadlock
and adds a meaningful error message if pthread_create() fails.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With threads the decoder has a delay and will thus have multiple
frames at EOF left in its buffers which will be returned when flushing
the decoder. The code that extracts such frames from the decoder at the
end does not pull frames from the filtergraph, thus when one of these
frames causes the filtergraph to be reinited, the frames still inside
the graph at that point re lost
This commit changes the flushing to be more similar to normal decoding
and 1 frame at a time
Fixes hqx fate with threads
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '452860d7e056f9a894cac2fe52cdedeae4c38251':
Use av_packet_rescale_ts() to simplify code.
Conflicts:
doc/examples/muxing.c
ffmpeg.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '48e50921337984ba4ec2c1cafe45d43787f84498':
avconv: make -shortest work with streamcopy
Conflicts:
ffmpeg.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '39ec5e1cf8444f827c42effb76e5694e091bbff3':
avconv: Report the codec and the encoder separately
Merged-by: Michael Niedermayer <michaelni@gmx.at>
We cannot use avpriv_request_sample() as this is private to the libs
or rather it would be a bad usage example
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It seems working without this now for the files i tested it with, if this causes
a regression, dont hesitate to put the line back or open a ticket or fix (if possible)
the parser
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '383136264ef40452efd86cafb2d7221cd3830b3d':
avconv: do not use the stream codec context for encoding
Conflicts:
ffmpeg.c
ffmpeg_opt.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The demuxer needs this value to generate correct timestamps in some corner cases
Ideally the parser would always set this correctly, but some parsers lac support
for extracting this value, also its not trivial.
This fixes a regression
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '41776ba9c0ebbb71394cefdf7dd1b243e6c852d5':
avconv: do not use the stream codec context for decoding
Conflicts:
ffmpeg.c
ffmpeg_filter.c
ffmpeg_opt.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
