Because in contrast to the decoder, the parser does not setup low_delay, the code in parse_nal_units would always end up setting has_b_frames to 1 (except when stream is explicitly marked as low delay). Since the parser itself would create extradata, simply reopening the parser would cause this. This happens for instance in estimate_timings_from_pts(), which causes the parser to be reopened on the same stream.
This fixes Libav #22 and FFmpeg (trac) #360 CC: [email protected] Based on a patch by Reimar Döffinger <[email protected]> (commit 31ac0ac29b6bba744493f7d1040757a3f51b9ad7) Comments and description adapted by Reinhard Tartler. Signed-off-by: Reinhard Tartler <[email protected]> --- libavcodec/h264_parser.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) I have tested this patch against the provided sample in bug #22. This patch makes the following error messages go away in avplay: [mpegts @ 0x1911d80] invalid dts/pts combination 2.20 A-V: -0.070 s:3.3 aq= 0KB vq= 0KB sq= 0B f=0/0 f=0/0 Last message repeated 39 times diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c index bcaa04a..48215c5 100644 --- a/libavcodec/h264_parser.c +++ b/libavcodec/h264_parser.c @@ -251,6 +251,13 @@ static int h264_parse(AVCodecParserContext *s, h->got_first = 1; if (avctx->extradata_size) { h->s.avctx = avctx; + // must be done like in the decoder. + // otherwise opening the parser, creating extradata, + // and then closing and opening again + // will cause has_b_frames to be always set. + // NB: estimate_timings_from_pts behaves exactly like this. + if (!avctx->has_b_frames) + h->s.low_delay = 1; ff_h264_decode_extradata(h); } } -- 1.7.5.4 _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
