Opened 5 years ago
Closed 5 years ago
#8001 closed defect (fixed)
FFmpeg fails to read MKV after 2GiB
| Reported by: | Anton1699 | Owned by: | |
|---|---|---|---|
| Priority: | important | Component: | avformat |
| Version: | git-master | Keywords: | mkv |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | yes |
Description
Summary of the bug: FFmpeg & FFplay display a freeze frame after 2GiB of an MKV until 4GiB, then decides correctly again after 6GiB until 8GiB and so on
How to reproduce: Play/Transcode an MKV-file larger than 2GiB.
Log file included as attachment
Attachments (1)
Change History (4)
by , 5 years ago
| Attachment: | ffmpeg-20190706-094239.zip added |
|---|
comment:1 by , 5 years ago
Replying to Anton1699:
Summary of the bug: FFmpeg & FFplay display a freeze frame after 2GiB of an MKV until 4GiB, then decides correctly again after 6GiB until 8GiB and so on
How to reproduce: Play/Transcode an MKV-file larger than 2GiB.
Log file included as attachment
Upon further investigation, this only seems to happen when using rawvideo inside an MKV-file.
comment:2 by , 5 years ago
| Analyzed by developer: | set |
|---|---|
| Component: | undetermined → avformat |
| Reproduced by developer: | set |
Regression since a569a7b3bb017315b954ca686e1e8add05f07f09
An overflow happened in "res = avio_skip(pb, length);" if the new position was >= 2 GB and < 4 GB etc. because res is an just an int. This happens when there are elements to be skipped, like the CRC-32 elements that our Matroska muxer adds by default; files created by mkvmerge don't have such elements, which explains the result of your further investigation.
This line has been changed in ff5ea59f7b05cb4d37ba9e2c3ee383ff24a10ae0, too, but the overflow is still there.
Sorry for this.
comment:3 by , 5 years ago
| Keywords: | matroska removed |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Should be fixed in eb33be188d2acb99e8f0f6a5cb45c931ed947cd0.
zipped log file