Using "--irefresh-type 1" (open gop) results in video that has poor seeking performance in all web browsers and various media players
Created by: Neltulz
What steps will reproduce the problem?
- Download the included y4m file in 7z file (Extract it) https://www.dropbox.com/s/m7vu0eycpjd47aq/Ted_2012_REMUX_SAMPLE.y4m_EXTRACT_ME.7z?dl=0
- Using SvtAv1EncApp.exe (SVT [version]: SVT-AV1 Encoder Lib v0.8.5-39-g3fbd1ee9) (SVT [build] : GCC 10.2.0 64 bit) (LIB Build date: Sep 30 2020 19:30:58)
- encode using these settings:
SvtAv1EncApp.exe --irefresh-type 1 --keyint 48 -q 25 -b Ted_2012_SAMPLE_av1-svt_irefresh-type-1_keyint-48.ivf -i Ted_2012_REMUX_SAMPLE.y4m
-
Using MKVToolnix version 51.0.0.0, drag drop the .ivf file onto the MKVToolNix GUI, rename the output from .mkv to .webm (this will automatically enable webm compatability mode), then save the file as a .webm You may download mkvtoolnix here: https://mkvtoolnix.download/downloads.html
-
(Optional) Upload the WebM to web server of your choosing
-
If skipped step 5, drag drop the WebM onto Google Chrome to open the video in a new tab. If NOT skipped step 5, open the URL of the WebM file in Google Chrome. Here is a URL for your convenience: http://logichaos.com/neil_tmp/ted_sample_bug_report_svtav1/Ted_2012_SAMPLE_av1-svt_irefresh-type-1_keyint-48.webm
-
Click anywhere on the seekbar to seek to a position of your choosing. If you click closer towards the beginning, the video will seek fairly quickly. If you click closer towards the end of the video, the video will take a long time to seek (presumably because the video is decoding from the beginning of the video, and not the nearest keyframe).
-
You may compare to this video, which uses
--irefresh-type 2
(closed gop) http://logichaos.com/neil_tmp/ted_sample_bug_report_svtav1/Ted_2012_SAMPLE_av1-svt_irefresh-type-2_keyint-48.webm -
Click anywhere on the seekbar to seek to a position of your choosing. You will notice that seeking performance is dramatically improved.
-
You may test this on longer sample videos to see the problem amplified. If using
--irefresh-type 1
(open gop) -- the longer the sample, the longer it will take for the video to seek to the position.
What is the expected output?
- User should be able to click anywhere on the seek bar and be able to seek to that position without any issues.
What do you see instead?
- Poor seeking performance when user clicks anywhere on the seek bar, but the performance is worse if the user clicks closer towards the end of the video.
Tested in:
- Windows 10 Pro 64bit
- Edge Chromium Version 86.0.622.48 (Official build) (64-bit)
- Google Chrome
- Firefox 82.0 (64-bit)
- Firefox Nightly 84.0a1 (2020-10-24) (64-bit)
- MPV.net version 5.4.8.0
- MPC-BE version 1.5.5 x64
- VLC Portable version 3.0.11 Vetinari
All of the tested applications have difficulty seeking.
Please provide any additional information below.
- Using "--irefresh-type 2" always results in a file that is able to properly seek properly without any issues;
therefore: the issue is limited to
--irefresh-type 1
This works great every time, able to seek with no issues what-so-ever: http://logichaos.com/neil_tmp/ted_sample_bug_report_svtav1/Ted_2012_SAMPLE_av1-svt_irefresh-type-2_keyint-48.webm
This one has problem with seeking, poor performance, or complete refusal to seek (already linked this one above in the step by step process): http://logichaos.com/neil_tmp/ted_sample_bug_report_svtav1/Ted_2012_SAMPLE_av1-svt_irefresh-type-1_keyint-48.webm
Please note, that I have also opened a similar issue for aomenc regarding poor seeking performance. Perhaps this issue is related. I highly advise checking out this issue and reading the comments from the project members. Hopefully a solution can be found. https://bugs.chromium.org/p/aomedia/issues/detail?id=2862