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>

fix ticket #2024

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Other solutions welcome

Fixes Ticket3711

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes Ticket3715

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes Ticket3658

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This fixes the interactively enabled encoder debug by pressing 'D'

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Found-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-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>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-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>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Simplifies code and should correct timing values when -*sync drop is used

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes memleak

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

dts is not optional, its required for muxing,
previously it was set from AVStream.pts

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes 1 frame error in the duration and derived values,
introduced by not using AVStream.pts in the previous commit

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.

Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This avoids misleading encoder names like "encoder = prores"

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Alternatively every fate test could be changed to pass both fflags and flags +bitexact

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>

This is purely a cosmetic change
Suggested-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Found-by: jamrial
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes Ticket3477

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes Ticket3344

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This reverts part of 41e7e46cac

See: http://thread.gmane.org/gmane.comp.video.ffmpeg.user/51229
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fix trac ticket #3420.

This is unsafe and can deadlock amongth other things

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes Ticket3427

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

If a packet is not ready on the input selected by ffmpeg,
it will read from another input instead. If that happens
repeatedly, frames will accumulate somewhere later in the
processing to ensure streams synchronization. It can happen
in particular when reading from a slow medium or an
expensive lavfi filter graph.

Make reading from normal demuxers on non-streamed data and
from the lavfi pseudo-device blocking to avoid that.

Should fix trac ticket #3079.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Broken by: 394fb56c29
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Help with debugging timestamp issues.

Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>