Hi, On Fri, Dec 14, 2012 at 2:33 PM, Janne Grunau <[email protected]> wrote: > Hi, > On 2012-12-12 16:20:50 -0800, Ronald S. Bultje wrote: >> Hi, >> >> On Wed, Dec 12, 2012 at 12:30 PM, Janne Grunau <[email protected]> >> wrote: >> > --- >> > libavcodec/h264.c | 13 ++++++++++++- >> > libavcodec/h264.h | 1 + >> > 2 files changed, 13 insertions(+), 1 deletion(-) >> >> In what situation does this happen? > > One situation is data partitioning. NAL_DPA calls decode_slice_header > and can start a new frame but wasn't counted as needed frame. See > attached patch. With a little luck it make this patch and patch 12/15 > obsolete. > > Janne > > ---8<--- > > Since a NAL_DPA can start a new frame it has to be handled before > ff_thread_finish_setup is called. > --- > libavcodec/h264.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/h264.c b/libavcodec/h264.c > index b863c41..75192ac 100644 > --- a/libavcodec/h264.c > +++ b/libavcodec/h264.c > @@ -3929,6 +3929,7 @@ static int decode_nal_units(H264Context *h, const > uint8_t *buf, int buf_size) > case NAL_PPS: > nals_needed = nal_index; > break; > + case NAL_DPA: > case NAL_IDR_SLICE: > case NAL_SLICE: > init_get_bits(&hx->s.gb, ptr, bit_length); > -- > 1.7.12.4
That looks more in line with the intent of the current code, so is OK as a short-gap. Ideally, at some point we would add parsing for these kind of sequences, so they are input as 2 separate pkts to the decoder in 2 separate threads, thus running concurrently. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
