#8084(undetermined:new): Seeking backwards with large mkv files broken
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------- Reporter: Kanehekili | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- 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}... }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------ Reporter: Kanehekili | Owner: Type: defect | Status: new Priority: important | Component: avformat Version: unspecified | Resolution: Keywords: mkv | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Changes (by mkver): * keywords: => mkv * priority: normal => important * component: undetermined => avformat Comment: Can you upload a sample file e.g. [https://streams.videolan.org/upload/ here]? In your case, you would have to split it (without remuxing). -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------ Reporter: Kanehekili | Owner: Type: defect | Status: new Priority: important | Component: avformat Version: unspecified | Resolution: Keywords: mkv | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Comment (by 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 -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------ Reporter: Kanehekili | Owner: Type: defect | Status: new Priority: important | Component: avformat Version: unspecified | Resolution: Keywords: mkv | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Comment (by 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. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------ Reporter: Kanehekili | Owner: Type: defect | Status: new Priority: important | Component: avformat Version: unspecified | Resolution: Keywords: mkv | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Comment (by cehoyos): 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. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------ Reporter: Kanehekili | Owner: Type: defect | Status: new Priority: important | Component: avformat Version: unspecified | Resolution: Keywords: mkv | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Changes (by mkver): * reproduced: 0 => 1 Comment: I can reproduce this locally, i.e. you don't need to upload your big file. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------ Reporter: Kanehekili | Owner: Type: defect | Status: new Priority: important | Component: avformat Version: unspecified | Resolution: Keywords: mkv | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Comment (by cehoyos): Please post an explanation how to reproduce. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#8084: Seeking backwards with large mkv files broken -------------------------------------+------------------------------------ Reporter: Kanehekili | Owner: Type: defect | Status: closed Priority: important | Component: avformat Version: unspecified | Resolution: fixed Keywords: mkv | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Changes (by mkver): * status: new => closed * resolution: => fixed Comment: 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.) -- Ticket URL: <https://trac.ffmpeg.org/ticket/8084#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg