The previous condition of 0 page size was wrong,
that would disable the mechanism for all frames at
a start of a page, thus some keyframes still would not
get their own granule.
The real problem is that header packets must not be flushed,
but they have (and must have) 0 granule and thus would
be detected as keyframes.
Add a separate parameter to mark header packets.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
In order to match Linux behaviour better our
Windows-specific open() replacement should disable
Windows default file locking.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This needs the extradata to be extracted.
The approach used is the one MPlayer uses, though it is
unclear whether the 4 bytes extradata that are skipped
should be skipped always or only for AAC.
The AAC parser must be disabled, too, otherwise playback
still does not work.
Fixes trac issue #547.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This allows handling matroska files with errors.
Fixes test4.mkv and test7.mkv from the official Matroska test suite.
These are also trac issues #544 and #545.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Seek beyond the end will now directly return an error instead
of claiming to succeed and then return EOF immediately on next read.
This change is because before 47e015e6f1
mkv seek incorrectly never failed.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
In particular, detect when the index is obviously broken.
This fixes the worst symptoms of trac issue #958 and makes
sense to allow seeking in files without index.
However it is possible that there still is an index parsing bug
with that file.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Otherwise when we run into levels beyond the max. allowed
playback will be permanently broken.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
To make seeking work correctly, we must write a new granule for
each keyframe.
Unfortunately we currently have no regression tests due to no
included Theora encoder.
A test based on -vcodec copy from a Theora FATE sample should
probably be added.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The DC coefficient should be included, too.
This probably was missed because DC quantizer is always
even for MPEG-1/2 but this function is also used for MPEG-4.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
A lot of files do not mark keyframes correctly via
granule, so detect keyframe or not based on data
and complain if it mismatches.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
It would never be called when the searched-for position
was already in the index.
In the other cases, the ogg_reset at the end of the
read_timestamp function handled it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
In this case, the pts values will be delayed by one, but
at the same time pts values might only be supplied for e.g.
keyframes.
This results on only the frame after the keyframe having a
pts value.
As a hack, make read_timestamp return the keyframe position
together with the pts from a following frame when seeking
to a keyframe.
Fixes trac issue #438.
However it causes the read_timestamp function to return a
pos value that is actually before the packet with the
indicated pts.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
We can handle v4 just fine, the parts we currently use
are the same for v3 and v4.
v4 can in addition contain an index which we so far do
not use though.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Fixes trac issue #438.
Seeking in that sample would cause ogg_read_timestamp to fail
because ogg_packet would go into a state where all packets
of stream 1 would be discarded until the end of the stream.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Line sizes are only 8-byte aligned, so use unaliged loads
for add_bytes_l2 pointers.
Increasing the alignment requirement to 16 seemed a bit extreme
(png may be used for rather small sizes).
Also fix a mov that had its arguments swapped, leading
add_bytes_l2 being applied on up to 8 bytes too few.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
I have no idea what the idea was behind the original code,
but the new code is equivalent to it.
In that loop that places the new node nodes[j] contains
always the data of the new node (since the steps are always
in order: FFSWAP copies node[j] to node[j-1], j is decremented).
Thus nodes[j].no == i and nodes[j].sym == HNODE.
make fate still passes and contains VP6 samples which use
FF_HUFFMAN_FLAG_HNODE_FIRST.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Offsets are relative to the end of the header, not the
start of the buffer, thus the buffer size needs to be subtracted.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Codec is too simple to gain much from it at lower resolutions,
but should help at very high resolutions, particularly for
v3 and v5 where a not too optimized pseudo-YUV to RGB
is done in the codec.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
With gcc 4.6 this part of the code is ca. 4x faster, resulting
in an overall speedup of around 5% for fate-fraps-v5 sample.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Codec has only I- and skip-frames, so there is no
need for reget_buffer, change it so it works with
get_buffer.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Causes FFmpeg to pass through the correct pts values,
instead of clobbering all to AV_NOPTS_VALUE (the av_init_packet
default) to then make up new ones based on only fps when muxing.
Included are also the related FATE ref changes, which all
some reasonable on quick investigation.
Also set all H.264 references to us -vsync drop to reduce the
diff for the ref files.
Otherwise almost all H.264 references need to change, mostly due
to now starting with negative pts values.
About 20 additional H.264 conformance tests needed -vsync
drop anyway because they create pts values that are out of
order and thus not possible to mux otherwise.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Move libgsm_encode_close before its first use and call it
with the correct number of arguments.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This allows to work around any non-monotonic time-stamp errors
by just discarding all time stamps.
This will be necessary to allow H.264 conformance tests to pass
after fixing time stamps to be passed through rawenc.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
We may or may not be able to play the latter parts
but not demuxing at all seems like the worst possible behaviour.
Fixes playback of e.g.
http://playlist.yahoo.com/makeplaylist.dll?sid=128114687&sdm=web&pt=rd
As a proper solution either multiple video streams should
be exported or side data should be used to update extradata
if necessary.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Since it is set for e.g. webm muxer we should make it possible
to test such streams with framecrc, too.
Though the primary reason is that this allows the H.264 tests
to not run into this check when fixing raw video encode to
pass pts values on.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The tests work fine without it, and it will cause issues when the
rawvideo decoder is changed to properly handle pts values.
The H.264 conformance tests however are still broken, usually losing
the first frames without it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This fixes the video frame pts (off by one for each MVIh)
and makes the "key frames" decode stand-alone (MVIh
contains only palette, such a palette-only frame being
marked as key frame is not really correct).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Previously the decoder would raise an error.
The end result is the same, the time stamps only change
because regression tests create time stamps incorrectly.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This one was missed in the previous fraps fix, the
allocation is exactly the same in both cases.
Fixes fraps-v5 under valgrind.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This fixes parallel FATE (make fate -j4) failing under valgrind with:
Syscall param ioctl(TCSET{S,SW,SF}) points to uninitialised byte(s)
at 0x5D98B23: tcsetattr (tcsetattr.c:88)
by 0x43D66C: term_init (ffmpeg.c:734)
by 0x43CD8D: main (ffmpeg.c:5071)
Address 0x7fefffdd0 is on thread 1's stack
Uninitialised value was created by a stack allocation
at 0x43D5B0: term_init (ffmpeg.c:716)
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The same as av_fast_malloc but uses av_mallocz and keeps extra
always-0 padding.
This does not mean the memory will be 0-initialized after each call,
but actually only after each growth of the buffer.
However this makes sure that
a) all data anywhere in the buffer is always initialized
b) the padding is always 0
c) the user does not have to bother with adding the padding themselves
Fixes another valgrind warning about use of uninitialized data,
this time with fate-vsynth1-jpegls.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This reworks the frame skipping code such that the reference
buffers are still updated according to the header.
However it also ensures that the current frame will not end
up in any reference buffer.
Also fixes a hang with frame-multithreading, probably because
get_buffer was already called and would have reset the progress,
however the frame could remain in framep due to the missing update
(or it could be assigned to next_framep and a skip_frame skip would
then write it into framep - there might be even more failure modes).
Sample might become available at samples/nsv/vp8.nsv
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Current code would just return uninitialized data with no way
to detect this condition.
Instead, fill the whole GUID with 0 in that case.
Fixes valgrind uninitialized data errors in fate-seek-lavf_asf.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This is not a real error and memsetting always even when the
size did not change is overkill, but it still should be
an acceptable trade-off.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
At the very least this should fix warnings about unused static
functions if one or more of these is not defined.
However even compilation might be broken if the compiler does
not optimize the function away completely.
This actually happens in case of the AVX function, since the
function pointer is used in an assignment that is not under
an #if and thus probably only optimized away after the function
was already marked as used.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
While we correctly "register" the side data when we split it,
the application (in this case FFmpeg) might not update the
AVPacket pool it uses to finally free the packet, thus
causing a leak.
This also makes the av_dup_packet unnecessary which could
cause an even worse leak in this situation.
Also change the code to not modify the user-provide AVPacket at all.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Using the double variant causes several pointless conversions between
double and int.
Worse, one of the conversions is in an inner loop together with a
function using MMX, resulting in undefined behaviour.
Based on debugging by Ray Simard.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Tested-by: Ray Simard <rhs.ffmpeg@sylvan-glade.com>
Using an always_inline function makes the memcpy length a constant,
any reasonable compiler will replace it by a single mov instruction
without us having to duplicate the actual code.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This fixes reads of uninitialized data by the parser when running
FATE sample h264-conformance/SL1_SVA_B.264.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The decoders should not only be flushed on EOF or error, but also when
e.g. probe size was reached.
It is best to just always flush by default and only disable it
explicitly when we know that we have everything we need.
Fixes trac ticket #879.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This issue was discovered while decoding the FATE sample vqa/ws_snd.vqa.
For some unknown reason only audio decoding is tested by FATE for that file,
but not video.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Not all applications (e.g. MPlayer) set block_align, and
when using a different demuxer it might not even be
easily available.
So fall back to selecting mode based on bit rate as before
if block_align has not useful value.
It can't be worse than failing to decode completely.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This only happens for a "back" value of 0 which is invalid anyway,
but lcldec does not properly validate input.
Also extend the documentation to specify valid values.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
As far as I could see the only change is increased pos values,
which is as expected with additional metadata in the files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reimar Döffinger
