<jamrial> durandal_1707: 8088b5d69c broke the acrossfade test
<@durandal_1707> jamrial: there was test?
<jamrial> durandal_1707: fate-filter-acrossfade
<@durandal_1707> what broke?
<jamrial> what used to be one frame is now two
<@durandal_1707> ahh, just update test
Signed-off-by: James Almer <jamrial@gmail.com>
It tests a useless profile which sounds no better than regular aac and which
takes extremely long to encoder something. Also it has been behind experimental
flag for as long as it has been supported.
Should be removed altogether sometime in the future.
The twoloop coder sounds decent at low bitrates, however at higher bitrates
it sounds worse than the fast coder (which used to be the old twoloop coder
before October 2015) and needs quite a lot more CPU.
Change the default to fast. It has been well tested and has had little changes
over the years so its been confirmed to be quite stable.
Also change its description (not valid for more than a year) and the
documentation.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The framerate filter was quite convoluted with some filter_frame /
request_frame logic bugs. It seemed easier to rewrite the whole filter_frame /
request_frame part and also the frame interpolation ratio calculation part in
one step.
Notable changes:
- The filter now only stores 2 frames instead of 3
- filter_frame outputs all the frames it can to be able to handle consecutive
filter_frame calls which previously caused early drops of buffered frames.
- because of this, request_frame is largely simplified and it only outputs
frames on flush. Previously consecuitve request_frame calls could cause the
filter to think it is in flush mode filling its buffer with the same frames
causing a "ghost" effect on the output.
- PTS discontinuities are handled better
- frames with unknown PTS values are now dropped
Fixes ticket #4870.
Probably fixes ticket #5493.
Signed-off-by: Marton Balint <cus@passwd.hu>
The PERSIST_RPARAM_A_RExt_Sony_1 bitstream has an out-of-range value
and has therefore been superseded.
It is otherwise identical, and decodes the same.
Signed-off-by: James Almer <jamrial@gmail.com>
It was truncated to int later on anyway. Fate test changes are due to rounding
instead of truncation.
Fixes fate test failures on x86-32 (gcc 4.8 (Ubuntu 4.8.5-2ubuntu1~14.04.1))
after 090b740680.
Signed-off-by: Marton Balint <cus@passwd.hu>
- normalize score to [0..100] instead of [0..85]
- change the default score to 8.2 to roughly keep existing behaviour
- take into account bit depth
- do not truncate to integer
Signed-off-by: Marton Balint <cus@passwd.hu>
Check fread return value to fix build warning as "ignoring
return value of ‘fread’"
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Resulted in valgrind errors due to uninitialized memory.
Also updates fate and makes it use the tron sample result.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.
Signed-off-by: James Almer <jamrial@gmail.com>
Also change note to say that we compare against the officially decoded
samples rather than our own, this was changed long ago.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The current edit unit cannot be reliably determined for the last packet of a
video stream, because we can't query the start offset of the next edit unit
from the index. This caused missing timestamps for the last video packet.
Therefore from now on, we allow setting the PTS even if we are not sure of the
current edit unit if mxf_set_current_edit_unit returned a specific failure, and
the assumed current edit unit is the last.
Fixes last packet timestamp of:
ffprobe -fflags nofillin -show_packets tests/data/lavf/lavf.mxf -select_streams v
Signed-off-by: Marton Balint <cus@passwd.hu>
Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.
Unfortunately the OpenDML v1.02 document is not very specific on what
value to use for start_line when frame data is not coming from a
capturing device, so this is just using 0/1 depending on the field order
as a best-effort guess.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
