IFrames move after working in cutting window

Begonnen von CookieJones, Juni 01, 2022, 02:06:04

« vorheriges - nächstes »


(TS-Doctor 3.2.25)
I don't know if this is a bug or my expectations are wrong, but sometimes after working in the TSD cutting window, some IFrames end up shifted to a different position from when I started working.

For example, if I step through a video using the "+IF" and "-IF" buttons, and land at the I-Frame at 1:00:00.000 and take a screeshot of it, then I jump around using play, pause, and the various "+" and "-" buttons, ...
when I get back to position 1:00:00.000, should it be the same IFrame, with exact same paused video frame as before - as in my screenshot?   Sometimes it isn't, sometimes the paused video at 1:00:00.000 has changed, and my screenshot now matches the next IFrame before or after 1:00:00.000.

Is this normal behavior?
Windows 10 x64 20H2, TS-Doctor 3


this is a bit complicated, but in general: yes, its normal  ;D

The problem is that videos are heavily compressed today. And depending on the used decoder, the playback does not return the correct file position when you decide to set a cutting point.

For example, you set a point and the doc gets the current position as "X".

Then you continue and the internal buffers are filled with other scenes.

If you later on try to get back to the position X, the doc sets the file position back to what it thinks the former X would be. But knowing that due to compression/buffering this wont be correct, it starts to seek for the closest I-Frame. In the options you can switch if it searches before or after X, thus finding the last or the next iframe then.

Its more or less an "educated guess".

You may get better results with different decoders (LAV Filters, no Hardware decoding and so on), try them out, maybe you find one that suits you better (the doc does not really need speedy decoders beside of the cutting window he does not use them at all)


Thanks so much for responding and for the very helpful explanation. It's taking me a while to process it all, but it sounds like
I shouldn't expect the cutting to be very precise, and there isn't a clear way around that.   
If you don't mind a few more questions ...

Is it the same case, even if you haven't made any cuts?  This happens even when I'm just looking for the IFrames to use, before I've even marked any cuts.

A couple of other strange behaviors that seem related:

Sometimes when I click a "+IF" or "-IF" button, the video barely moves, where earlier at the same location it had made a clear jump. Right after that, things seem to get out of sync.

Other times, if I switch to another application then return to TSD by clicking the cutting window (not near any buttons) the video sometimes moves a very tiny bit, and again, after that, the problem seems to appear.

Is that also expected behavior?

Again, thanks for the great explanation and suggestions. I'll try playing with the settings and maybe a different filter.
Windows 10 x64 20H2, TS-Doctor 3


ZitatIs it the same case, even if you haven't made any cuts?  This happens even when I'm just looking for the IFrames to use, before I've even marked any cuts.
Cut or No-Cut  8)
(yeah, not really awake now... need COFFEEEEEE!!!)
Since all video decoding has to start with an iframe, it does not matter. The doc (or better: the used decoder) needs to search for the next iframe before it can show a picture.
So if you have NO cuts, it has to start from the beginning, finding the NEXT I-Frame, if you have done cuts, it starts from the stored position and can move back or forth depending on the set option.

Thats why you sometimes dont end up at the same spot when you later on return to the cut point again. Usually you have found it by moving forward, but you may have selected to use the last iframe before this point for cuts (common setting).

The other things you are worrying about are all more or less related to this.

The only way to overcome this all is to use a "normal" cutting program like Adobe Premier or something. They work by fully decoding (and storing) the source video, letting you arrange the resulting still pics and finally encoding everything into a new video. But this take hours or even days. Compared to them the Doc is lightning fast with some minor drawbacks. And, like everywhere in life, it's not all black and white, its mostly grey. You have to decide if you are more into speed or more into accuracy. The doc tries his best, but he can't do miracles.

This is not usually a big problem and it heavily depends on the encoder of your source. Some broadcaster send out very few iframes, others do them every few ms.
And, of course, the more you have, the better the jump.

This is especially true for almost black backtitels, or, the extreme, I recently had a movie that started with a black screen and music for over 5mins! No way to set a cutting point!

What helps very often is to playback the desired region, then pause and go back with -IF until the desired point. The buffers are then still filled with the decoded video and the retured position is more accurate.

But, as I said, it mostly depends on the source and the used decoder.


This is great, I'm learning quite a lot!

The source in my case is TV/movies captured from a DVR using Hauppauge Capture. I have mostly default settings except video quality (7Mbps) chosen to save space. 

I will try your suggestion to do playback then step back with -IF, and if I can figure it out, also try different decoders.

Again, thanks so much for your truly excellent help.
Windows 10 x64 20H2, TS-Doctor 3


Hello CookieJones,

could you please tell us which CPU and which graphics card you are using in your system? Because I have two computers running TS-Doctor, and the Intel based (Intel HD Graphics) always does absolutely accurate cuts and jumps and plays from the very exact location which has been navigated to with the skip / cue buttons. But my second system is AMD Ryzen APU based (Vega 8 APU graphics) and shows the jumping and problems with the skip buttons exactly as you described. This is by no way a "that's the way it is" issue, but it might e.g. be a problem with the AMD graphics drivers. Therefore I'd like to know some details about your system. I already contributed my error report here in german: https://cypheros.de/forum_ger2/index.php/topic,5398.0.html, but it would be good to find other verified occurences of this problem to narrow down the analysis which will hopefully be done by the developer. Thank you!

cu, Steffen