|
66 | 66 | # Performance: ``VideoDecoder`` creation |
67 | 67 | # -------------------------------------- |
68 | 68 | # |
69 | | -# In terms of performance, the ``seek_mode`` parameter ultimately affects the |
| 69 | +# In terms of performance, the ``seek_mode`` parameter mainly affects the |
70 | 70 | # **creation** of a :class:`~torchcodec.decoders.VideoDecoder` object. The |
71 | 71 | # longer the video, the higher the performance gain. |
72 | 72 |
|
@@ -104,7 +104,7 @@ def bench(f, average_over=50, warmup=2, **f_kwargs): |
104 | 104 | # --------------------------------------------- |
105 | 105 | # |
106 | 106 | # Strictly speaking the ``seek_mode`` parameter only affects the performance of |
107 | | -# the :class:`~torchcodec.decoders.VideoDecoder` creation. It does not have a |
| 107 | +# the :class:`~torchcodec.decoders.VideoDecoder` creation. It usually does not have a |
108 | 108 | # direct effect on the performance of frame decoding or sampling. **However**, |
109 | 109 | # because frame decoding and sampling patterns typically involve the creation of |
110 | 110 | # the :class:`~torchcodec.decoders.VideoDecoder` (one per video), ``seek_mode`` |
@@ -168,20 +168,21 @@ def sample_clips(seek_mode): |
168 | 168 | # duration), and also builds an internal index of frames and key-frames. This |
169 | 169 | # internal index is potentially more accurate than the one in the file's |
170 | 170 | # headers, which leads to more accurate seeking behavior. |
171 | | -# Without the scan, TorchCodec relies only on the metadata contained in the |
172 | | -# file, which may not always be as accurate. |
| 171 | +# Without the scan (in approximate mode), TorchCodec relies only on the metadata |
| 172 | +# contained in the file, which may not always be as accurate. In some rare |
| 173 | +# cases, relying on this less accurate data may also lead to slower frame |
| 174 | +# decoding, because it can involve unnecessary seeks. |
173 | 175 | # |
174 | 176 | # Which mode should I use? |
175 | 177 | # ------------------------ |
176 | 178 | # |
177 | 179 | # The general rule of thumb is as follows: |
178 | 180 | # |
179 | 181 | # - If you really care about exactness of frame seeking, use "exact". |
180 | | -# - If you can sacrifice exactness of seeking for speed, which is usually the |
181 | | -# case when doing clip sampling, use "approximate". |
182 | | -# - If your videos don't have variable framerate and their metadata is correct, |
183 | | -# then "approximate" mode is a net win: it will be just as accurate as the |
184 | | -# "exact" mode while still being significantly faster. |
| 182 | +# - If your videos are short (less then a few minutes) then "exact" will usually |
| 183 | +# be preferable, as the scan's fixed cost will be negligible. |
| 184 | +# - For long videos, if you can sacrifice exactness of seeking for speed, which |
| 185 | +# is usually the case when doing clip sampling, consider using "approximate". |
185 | 186 |
|
186 | 187 | # %% |
187 | 188 | shutil.rmtree(temp_dir) |
|
0 commit comments