[FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided
James Almer
jamrial at gmail.com
Sat Jan 20 01:30:59 EET 2018
On 1/19/2018 5:06 PM, wm4 wrote:
> On Fri, 19 Jan 2018 16:51:45 -0300
> James Almer <jamrial at gmail.com> wrote:
>
>> Attempting full frame reconstruction is unnecessary for containers
>> like Matroska, so just skip it altogether.
>>
>> Signed-off-by: James Almer <jamrial at 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.
More information about the ffmpeg-devel
mailing list