On Mon, Oct 17, 2016 at 12:13 PM, wm4 <nfx...@googlemail.com> wrote:
> On Sun, 16 Oct 2016 22:11:03 +0200
> Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote:
>
>> The problem was introduced in commit 1273bc6.
>>
>> Signed-off-by: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
>> ---
>> libavformat/matroskadec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 8847c62..a5d3c0e 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -1759,7 +1759,7 @@ static int mkv_field_order(MatroskaDemuxContext
>> *matroska, int64_t field_order)
>>
>> /* workaround a bug in our Matroska muxer, introduced in version 57.36
>> alongside
>> * this function, and fixed in 57.52 */
>> - if (sscanf(matroska->muxingapp, "Lavf%d.%d.%d", &major, &minor, µ)
>> == 3)
>> + if (matroska->muxingapp && sscanf(matroska->muxingapp, "Lavf%d.%d.%d",
>> &major, &minor, µ) == 3)
>> bttb = (major == 57 && minor >= 36 && minor <= 51 && micro >= 100);
>>
>> switch (field_order) {
>
> Why do we even have this dumb check?
>
> The files that have already produced will be misinterpreted by
> compliant demuxers, and adding ugly workarounds is unfair to those
> compliant demuxers.
This way you can at least fix it by remuxing with a newer ffmpeg,
instead of it being broken forever.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
