Seeking backwards with large mkv files broken

[Kanehekili]

Summary of the bug:
The update of ffmpeg 4.2 has a regression when seeking mkv containers larger than 2GB.
The codecs tested were VC-1 and h264.
How to reproduce:
1)Seeking forward/backwards takes a long time , receiving an error like:

[matroska,webm @ 0x801b86f40]Element at 0x81e78160 ending at 0x81ff3e32 exceeds containing master element ending at 0x7e2ea500

Opencv and direct usage of av_seek_frame on large mkv files show this behavior.
av_seek_frame(...AVSEEK_FLAG_BACKWARD) does not work at all, the stream position does not go backwards.
Works with previous version 4.1

ffmpeg version n4.2 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9.1.0 (GCC)
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

[mkver]

Can you upload a sample file e.g. ​here? In your case, you would have to split it (without remuxing).

[Kanehekili]

Update: This happens only in a Matroska Version 2 Container.
Using

ffmpeg -i input.mkv -codec copy output.mkv

changes the format version to 4 - no seeking problems

The test file has the size of 16 GB. I'll try to split a part of it. It had been generated by makemkv, in case that helps

[mkver]

I don't think that the version number has anything to do with it (It does not affect seeking or demuxing. It is just used for an initial check whether the file requires a version ffmpeg doesn't support. The version number is not even kept after parsing the header.); but the remuxing definitely might have.

[Carl Eugen Hoyos]

To make this a valid ticket, please test current FFmpeg git head, provide the command line you tested together with the complete, uncut console output and upload a sample to your favorite hosting site.

[mkver]

I can reproduce this locally, i.e. you don't need to upload your big file.

[Carl Eugen Hoyos]

Please post an explanation how to reproduce.

[mkver]

Fixed in c294f38c91f440880ffd28fda0eeb1154431ab7e (299e0dff1fbc3594eca9e67e18a28331892c23fb in the 4.2 branch).

@cehoyos: Use ffplay to play a Matroska file that is bigger than 2GB. (Using ffmpeg with input seeking (which is what I tested originally) is fine though.)