- 19 Jan, 2017 1 commit
-
-
Clément Bœsch authored
-
- 16 Jan, 2017 1 commit
-
-
Clément Bœsch authored
It is done unconditionally in ff_h264_field_end()
-
- 09 Dec, 2016 1 commit
-
-
Derek Buitenhuis authored
This could happen when there was a frame number gap and frame threading was used. This fixes #5458. Debugging-by: Ronald S. Bultje <rsbultje@gmail.com> Debugging-by: Justin Ruggles <justin.ruggles@gmail.com> Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
- 04 Aug, 2016 2 commits
-
-
Timothy Gu authored
This reverts commit e4af9be0 and redoes 796027f2. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
-
Timothy Gu authored
This reverts commit 796027f2, reversing changes made to bca30ed2. Preemptive revert before further testing has been done.
-
- 27 Jul, 2016 2 commits
-
-
Michael Niedermayer authored
-
Clément Bœsch authored
-
- 19 Jul, 2016 1 commit
-
-
Michael Niedermayer authored
This was missing from f512e4a3Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 15 Jul, 2016 1 commit
-
-
Anton Khirnov authored
This function's purpose is not very well defined. Currently it does two (only marginally related) things: selecting the next output frame and calling ff_thread_finish_setup() for frame threading. The first of those more properly belongs under field_start(), while the second can be called directly from decode_nal_units().
-
- 11 Jul, 2016 1 commit
-
-
Anton Khirnov authored
Currently, SPS.mb_height is actually what the spec calls PicHeightInMapUnits, which is half the frame height when interlacing is allowed. Calling this 'mb_height' is quite confusing, and there are at least two associated bugs where this field is treated as the actual frame height - in the h264 parser and in the code computing maximum reordering buffer size for a given level. Fix those issues (and avoid possible future ones) by exporting the real frame height in this field.
-
- 03 Jul, 2016 1 commit
-
-
Clément Bœsch authored
-
- 01 Jul, 2016 1 commit
-
-
James Almer authored
Changed by committer to ensure context_initialized is reset Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 30 Jun, 2016 2 commits
-
-
Benoit Fouet authored
-
Benoit Fouet authored
The MBS only flag was not taken into account when checking macroblock dimensions. Also removes the unneeded check in init_dimensions for slices.
-
- 29 Jun, 2016 3 commits
-
-
Clément Bœsch authored
Fixes ./ffmpeg -skip_frame nokey -i h264/h264_intra_first-small.ts Regression since c54e2740
-
Michael Niedermayer authored
This should not be needed anymore and simplifies the next merge Requested-by: Clément Bœsch <u@pkh.me> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
This should not be needed anymore and simplifies the next merge Requested-by: Clément Bœsch <u@pkh.me> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 23 Jun, 2016 1 commit
-
-
Diego Biurrun authored
libavcodec/h264_slice.c:1384:9: warning: variable 'droppable' set but not used
-
- 21 Jun, 2016 21 commits
-
-
Anton Khirnov authored
This is a more appropriate place for this. H264Context.recovery_frame is shared between frame threads, so modifying it where it is right now is invalid.
-
Anton Khirnov authored
Going through the whole decoder initialization process for a slice we are not going to decode is unnecessary and potentially dangerous.
-
Anton Khirnov authored
It is always checked in the surrounding code, so this make sure we don't see a value from an old slice.
-
Anton Khirnov authored
This is a more appropriate place for it.
-
Anton Khirnov authored
-
Anton Khirnov authored
This should make it more clear that this function does not need any decoder-global state other than the parameter sets.
-
Anton Khirnov authored
The code does some weird casting to a 2-dimensional sub-array of ref2frm. This is not necessary, since only one dimension is needed there.
-
Anton Khirnov authored
Those are unused remnants of the old SVQ3 code.
-
Anton Khirnov authored
This will prevent conflicts e.g. in code that deals with both h264 and hevc.
-
Anton Khirnov authored
The PS parsing code is independent from the decoder, so it makes more sense for it to have its own separate header.
-
Anton Khirnov authored
Move the NAL unit types into it. This will allow to stop including the whole decoder-specific h264dec.h in some code that is unrelated to the decoder and only needs some enum values.
-
Anton Khirnov authored
This is more consistent with the naming of other decoders.
-
Anton Khirnov authored
Right now this code is mixed with selecting the next output frame. Move it to a separate function called from h264_field_start(), which is a more appropriate place for this.
-
Anton Khirnov authored
This is a more appropriate place for it.
-
Anton Khirnov authored
Doing this after ff_thread_finish_setup() is called is invalid and can conflict with reads from the other thread.
-
Anton Khirnov authored
While the value of those variables will be constant for the whole frame, they are only used in two functions called from slice header decoding. Moving them to the per-slice context allows us to make the H264Context passed to slice_header_parse() constant.
-
Anton Khirnov authored
Copy them into the decoder-global context in field_start(). This avoids modifying the decoder-global context during bitstream parsing.
-
Anton Khirnov authored
Avoid unnecessary modification of the decoder-global state in per-slice code.
-
Anton Khirnov authored
There is no bitstream parsing in that block and messing with decoder-global state is not something that belongs into header parsing. Nothing else in this function depends on the value of current_slice, except for two validity checks. Those checks are also moved out of slice_header_parse().
-
Anton Khirnov authored
Replace the decoder-global nal_unit_type/nal_ref_idc variables with the per-NAL ones. The decoder-global ones still cannot be removed because they are used by hwaccels.
-
Clément Bœsch authored
-
- 20 Jun, 2016 1 commit
-
-
Clément Bœsch authored
-