reverts one hunk from 7966ddfc0bb7ee87dc2606b7b146701db6f6c717
The new code from 7966ddfc0bb7ee87dc2606b7b146701db6f6c717 only covers extradata based SPS
Fixes: ffplay -ss 13 58af5798-fa2c-42a2-997d-dc8e49de2d8a.flv
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'a7829a2a3f8e6ec0b9f2673c11f56916800aeb33':
h264: reimplement 3aa661ec5 in a more explicit way
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'e481458bc308ee838deaeacac51929514762e7a7':
h264: factor out pred weight table parsing into a separate file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Sometimes video fails to decode if H.264 configuration changes mid stream.
The reason is that configuration parser assumes that nal_ref_idc is equal to 11b
while actually some codecs but 01b there. The H.264 spec is somewhat
vague about this but it looks like it allows any non-zero nal_ref_idc for sps/pps.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Instead of handling the problem inside NAL decoding code, add a higher
level wrapper function. This should be more robust against future
changes (and easier to read).
get_ue_golomb() cannot decode values larger than 8190 (the maximum
value that can be golomb encoded in 25 bits) and produces the error
"Invalid UE golomb code" if a larger value is encountered. Use
get_ue_golomb_long() instead (which supports 63 bits, up to 4294967294)
when valid h264/hevc values can exceed 8190.
This updates decoding of the following values: (maximum)
first_mb_in_slice 36863* for level 5.2
abs_diff_pic_num_minus1 131071
difference_of_pic_nums_minus1 131071
idr_pic_id 65535
recovery_frame_cnt 65535
frame_packing_arrangement_id 4294967294
frame_packing_arrangement_repetition_period 16384
display_orientation_repetition_period 16384
An alternative would be to modify get_ue_golomb() to handle encoded
values of up to 49 bits as was done for get_se_golomb() in a92816c.
In that case get_ue_golomb() could continue to be used for all of
these except frame_packing_arrangement_id.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'b09ad37c83841c399abb7f2503a2ab214d0c2d48':
h264: derive the delay from the level when it's not present
Merged without changing the strict_std_compliance check, as it breaks FATE
and changes decoding behavior.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
In the merge commit 78265fcfeee153e5e26ad4dbc7831a84ade447d6 this behaviour
was broken and the CORRUPT flag would never ever be set on a frame. However
the flag on the AVCodecContext was taken into account properly, including
AV_CODEC_FLAG2_SHOW_ALL.
The reason for this was that the recovered field of the next output picture
was always set to TRUE whenever one of the two AVCodecContext flags was set,
which made it impossible to detect later, before outputting, if the frame was
really recovered or not. Now don't set it to TRUE unless the frame is really
recovered and check the AVCodecContext flags right before outputting.
Signed-off-by: Sebastian Dröge <sebastian@centricular.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fall back to maximum DPB size if the level is unknown.
This should be more spec-compliant and does not depend on the caller
setting has_b_frames before opening the decoder.
The old behaviour, when the delay is supplied by the caller setting
has_b_frames, can still be obtained by setting strict_std_compliance
below normal.
This makes the h.264 decoder threadsafe to initialize.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
There is not much reason to generate such a small table at runtime.
Signed-off-by: Derek Buitenhuis <derekb@vimeo.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
When compiled with --disable-pthreads, e.g
http://fate.ffmpeg.org/report.cgi?time=20150917015044&slot=alpha-debian-qemu-gcc-4.7,
a bunch of -Wunused-functions are reported due to missing header guards
around threading related functions.
This patch should silence such warnings.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Default field order to top field first when interlaced frame is detected and pic_struct_present_flag is not set.
Since bottom field first comes from the old NTSC standard and is not used with HD anymore I think it´s straight forward to favor the majority.
Signed-off-by: Thomas Mundt <loudmax@yahoo.de>
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
At least the new videotoolbox decoder does not actually set a frame if
end_frame fails. This causes the API to return success and signals that
a picture was decoded, even though AVFrame->data[0] is NULL.
Fix this by propagating end_frame errors.
When skip_frame is set to _NONKEY the decoder skips everything except intra
slices, which breaks frames that consist of an intra field together with any
other field type; half the frame becomes garbage. This patch fixes the issue by
letting non-intra slices through if they're part of a keyframe.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
