On Fri, Jan 19, 2018 at 08:30:59PM -0300, James Almer wrote: > On 1/19/2018 5:06 PM, wm4 wrote: > > On Fri, 19 Jan 2018 16:51:45 -0300 > > James Almer <jamr...@gmail.com> wrote: > > > >> Attempting full frame reconstruction is unnecessary for containers > >> like Matroska, so just skip it altogether. > >> > >> Signed-off-by: James Almer <jamr...@gmail.com> > >> --- > >> libavcodec/mlp_parser.c | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c > >> index 3c0330f777..4827354f18 100644 > >> --- a/libavcodec/mlp_parser.c > >> +++ b/libavcodec/mlp_parser.c > >> @@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s, > >> if (buf_size == 0) > >> return 0; > >> > >> + if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) { > >> + next = buf_size; > >> + } else { > >> if (!mp->in_sync) { > >> // Not in sync - find a major sync header > >> > >> @@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s, > >> } > >> > >> mp->bytes_left = 0; > >> + } > >> > >> sync_present = (AV_RB32(buf + 4) & 0xfffffffe) == 0xf8726fba; > >> > > > > Not so sure about this. I think some mkv TrueHD files contain packets > > that are not properly starting on frame boundaries. But I don't really > > remember. > > As in badly muxed files? Couldn't the same thing happen with any other > codec? We're not bothering to consider such cases in other parses as far > as i could see.
I agree, also IIRC we generally put workarounds for this kind of thing in demuxers. there both demmuxer and codec is known [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel