Cypheros Multimedia Forum

Hello, first of all my compliments for this extremely useful tool.

Now the matter: i'm having some random stuttering issues in playback, after cuts.

To watch all my recordings i mainly use my Xiaomi google TV-BOX 3rd generation hardware device, wich has an high quality embedded media player that never gave me issues like audio/video off synch or playback hesitation/stuttering. In my PC i use VLC media player, with no problems as well, so far.

Now i bought this fancy tool, TS Doctor v4.2.20 to edit my FullHD (1920*1080) H264 / H265 DVB-T recordings here in Italy and i'm very happy with it (it works flawlessy) but the resulting files randomly (not all the recordings) suffer of hesitation/stuttering problems during playback only at cutpoints, on the Xiaomi Google TV box, with both Xiaomi mediaplayer and Kodi. All the rest of the recording looks fancy, flawlessy with 0 defects.

I specify that my DTT decoder (DigiQUest Twin Tuner REC small edition) has a 100% strenght signal with a 100% quaity level.

Also, i always select my in/out cuts manually and only at I frames.

I tried a lot of options combinations in the "correction behavior" tab, but with the same results.
Sometimes on the PC with VLC mediaplayer, cutpoints stutter and on the Xiaomi TV box they do not, and sometimes it's just the contrary.

Usually, after producing the desired .TS file with TS Doctor (with commercials removed), i use the TS demuxer function and then remux everything with my favourite MKV tool, MKVtoolnix.

However, the playback stuttering problems at cutpoints remains even after remuxing in MKV.

I include a logfile and a snapshot of my settings.

Thank you.

Is it only a short stuttering or permanent?
Can you pinpoint if it's H264, H265 or both?

You can save the cutting point in the cutting window, so you can have the same cutting points for all tests.

Try to remove the checks in the checkboxes for "Remove adaptation field video filler data" and "Remove filler data (NALU12)" as a very few mediaplayers get problems at very low video bitrates.

If this is not changing anything, try to remove the check for "Remove disturbing B-Frames", too.

Hello,

it is a short stuttering only at cutpoints, but very annoying. First, the last frame of the previous section freezes for a few moments while the audio still goes on, then the following section starts with the stuttering, the stuttering only affects video, not audio. The strange thing is that this phenomenon doesn't happen with all the recordings.
 
I'll try tests with your suggestions.

90% of my recordings are H264, i'll try with those first.

Thank you very much.

Ok, tests done, unfortunately no improvements.

I tried to disable all the options you said, one at time, ending up with disabling all of them, with no results.

I'm sad...

 

Maybe we should note, that you can cut H264/H265 ONLY at specific points, called "I Frames"
These are the start of a picture, further frames only contain the difference to the last.
I-Frames are repeated at a certain schedule ( which varies a lot between devices and encoders).

The Doc offers a special feature in the cutting window. The Buttons "+If" and "-If" jump to the next and the last I-Frame (do not mix it up with "+1F" and "-1F" which means just "one frame for or back". THIS WILL NOT WORK!!!)

Scanning I Frames backwards can be tricky. The best way to find them is to jump back quite a bit, press PLAY and stop after the wanted Frame has passed. Then the picture buffer is filled with decoded frames and you can use -IF (Capital I not ONE!!!) to go back to the point you are interested.

Cutting here will produce flicker/noisefree cutted scenes.

(It is harder to describe but to do, give it a try)

Thank you, i only select I-frames for cutting, using just the "+IF" and "-IF" buttons as you said. Thanks for the buffering suggestion.

Is it possible for me to send the problematic test video for you to analyse? It's about 28MB.

Another finding: i see there are 2 typical types of commercial insertion on the TV stations i record from. Here they are: let's say i'm recording a movie:

Type *1* commercial insertion: (it gives me no playback problems on cuts): the movie part ends directly and abrubtly with a black I-frame, like if the movie segment is truncated, than the next I-frame is the first I-frame of the commercial.

Type *2* commercial insertion (the problematic one): the movie segment fades gradually to black and the last available I-frame is not a black frame, but still a picture from the movie, then the next I-frame is already the commercial.

Only commercial insertion Tyoe 2 give me the stuttering problem on playback. Dont know why since i only select I-frames, in both cases.

Also, at movie reprise, the first available I-frame is always a completely black frame, wich i select.

Thank you again, i hope we can resolve this problem.

Yes, if you can offer a sample, we can analyze the file.

Thank you, sent via PM.

Hello, happy Easter to everyone.

Remaining in wait for updates from you side, after a lot of hard testing sessions on another segment of the same recording i sent you, i have updates on my side; here are the news:

1) leaving or removing the filler datas (adaption field and NALU12) doesn't seems to change anything for me, so i decided to remove the filler datas. I always leave off the "Prefer cut befor cut-out point" function because i like to chose the cutpoints by myself.

2) I'd like to know if i read the logfiles correctly, because it seems that (no matter what) even if i always manually chose (with markers) only I-Frames for cut-in and cut-out points for every segment, the program cuts at B-frames. Even if you select "CONSIDER I/P FRAMES FOR CUTTING" + "I-FRAME ONLY CUTTING", the program perhaps cuts at B-Frames for all cut-in and cut-out points.

Here's the log:

Cutting areas (I-Frame aligned)
Cut 1 In : 17:00:06.717 (AUD|SEI|B-SLICE|)
Cut 1 Out: 17:00:36.817 (AUD|SEI|B-SLICE|)
Cut 1 PCR/PTS/DTS offset: 00:00:00.000

Cut 2 In : 17:05:27.757 (AUD|SEI|B-SLICE|)
Cut 2 Out: 17:05:58.417 (AUD|SEI|B-SLICE|)
Cut 2 PCR/PTS/DTS offset: -00:04:50.940


Intersections
Intersection 1 at 00:00:30.100

does it "B-SLICE" means it cuts at B-frame?

It seems That for I-frame cutting you have to select "CONSIDER I/P FRAMES FOR CUTTING" + "I-FRAME ONLY CUTTING" + "REMOVE DISTURBING B-FRAMES", so the log becomes:

Cutting areas (I-Frame aligned)
Cut 1 In : 17:00:06.277 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 1 Out: 17:00:36.417 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 1 PCR/PTS/DTS offset: 00:00:00.000

Cut 2 In : 17:05:27.317 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 2 Out: 17:05:57.977 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 2 PCR/PTS/DTS offset: -00:04:50.880


Intersections
Intersection 1 at 00:00:30.160

Now it says "I-SLICE"; is it I-Frame cutting? I don't understand what the other writings on the same line (AUD|SPS|PPS|SEI|) are.


3) I've seen that when i reload a saved cutpoints file (.tsdcuts), the cutpoints are no longer the same for at least one position: in my case, the cut-in position of the second segment was moved forward by one I-frame.

4) In the end i momentarily ended up chosing 2 main strategies, one best for watching with VLC on PC, and the other for watching on my Xiaomi TV Box connected to my TV. Still no good unique configuration for both:

a) For PC vision i chose "CONSIDER I/P FRAMES FOR CUTTING" + "I-FRAME ONLY CUTTING" + "REMOVE DISTURBING B-FRAMES", but the resulting .TS file is bad at cutpoints, so i demux it with the expert tool and then i remux with MKVtoolnix in MKV format. The cuts are now almost perfect on the PC, but you have to to turn off the deinterlace feature of VLC mediaplayer. If i watch this .MKV file on the TV with the Xiaomi, it stutters badly on cuts.

b) For my favourite vision experience (the Xiaomi TV box connected to my 65"TV) i select none of the special H264 features except for the NALU12, which i turn on. I leave the file in .TS format, no deuxing+remuxing in MKV. This .TS file freezes/stutters a bit at cutpoints on the Xiaomi. It's slighty better than before, but not yet a satisfying result.
the same file produces artifacts at cutpoints when played with VLC mediaplayer on PC.

Thank you again for this magnificent tool, i hoepe we can get rid of these problems.

Zitat von: Paolo Tex am April 05, 2026, 08:36:501) leaving or removing the filler datas (adaption field and NALU12) doesn't seems to change anything for me, so i decided to remove the filler datas. I always leave off the "Prefer cut befor cut-out point" function because i like to chose the cutpoints by myself.

2) I'd like to know if i read the logfiles correctly, because it seems that (no matter what) even if i always manually chose (with markers) only I-Frames for cut-in and cut-out points for every segment, the program cuts at B-frames. Even if you select "CONSIDER I/P FRAMES FOR CUTTING" + "I-FRAME ONLY CUTTING", the program perhaps cuts at B-Frames for all cut-in and cut-out points.

Bad combination...
You need to turn on "Prefer cut before..." because only then the (previous) IFrame will be searched and used.
Without it you will override each others I think (but I am not the programmer, all those settings go together rather mystically...)

Zitat von: Mam am April 05, 2026, 09:01:02Bad combination...
You need to turn on "Prefer cut before..." because only then the (previous) IFrame will be searched and used.
Without it you will override each others I think (but I am not the programmer, all those settings go together rather mystically...)

Ok, tested. In effects it seems that selecting "Prefer cut before cut out point" cause an I-Frame cut, even without the "Remove disturbing B-Frames" option enabled, the logs and timings are the same of "Prefer cut before cut out point" uncheked and "Remove disturbing B-Frames" checked.

Cutting areas (I-Frame aligned)
Cut 1 In : 17:00:06.277 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 1 Out: 17:00:36.417 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 1 PCR/PTS/DTS offset: 00:00:00.000

Cut 2 In : 17:05:27.317 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 2 Out: 17:05:57.977 (AUD|SPS|PPS|SEI|I-SLICE|)
Cut 2 PCR/PTS/DTS offset: -00:04:50.880


Intersections
Intersection 1 at 00:00:30.160

However i don't understand this behavoir, because, if i uncheck all "automatic" options and i am in full control (the mode i like) and i chose cutopints based only on I-Frames for all the segments, i don't understand why the program cuts at B-frames by its own. I think it should respect the cutpoints choices i made.

I recommend you try FFmpeg, which rebuilds the entire video, skipping or smoothing out defective parts. TS → FFmpeg (CRF 18–21) TV recording → TS-Doctor → FFmpeg → MP4
Note! The file size will become larger this way!

Zitat von: Paolo Tex am April 05, 2026, 10:53:20However i don't understand this behavoir, because, if i uncheck all "automatic" options and i am in full control (the mode i like) and i chose cutopints based only on I-Frames for all the segments, i don't understand why the program cuts at B-frames by its own. I think it should respect the cutpoints choices i made.

It likes to and tries hard. But sometimes it is not possible for some specific reasons only the MASTER here can tell you 

But one of the main reasons is, I think, that the returned file position for a certain frame is not always really accurate depending on the type of decoder. HW decoders (GPUs and IGPUs) do an internal buffering to uncompress and decode the stream and they often hold back a bunch of bytes before they give back a pic. Depending on the original encoding and method used, this maybe quite a bit away from the real thing. So your "full manual control" often leads to "full manual failure".

Therefore the automatics helps you to play it safe.

Zitat von: Mam am April 05, 2026, 12:43:50It likes to and tries hard. But sometimes it is not possible for some specific reasons only the MASTER here can tell you 

But one of the main reasons is, I think, that the returned file position for a certain frame is not always really accurate depending on the type of decoder. HW decoders (GPUs and IGPUs) do an internal buffering to uncompress and decode the stream and they often hold back a bunch of bytes before they give back a pic. Depending on the original encoding and method used, this maybe quite a bit away from the real thing. So your "full manual control" often leads to "full manual failure".

Therefore the automatics helps you to play it safe.

The automatic settings haven't worked for me since the beginning. I'm not here to criticize, but to get help.

I paid a regular license for this program (and i will pay again for future versions, if necessary) - so it is my peronal interest to have it working fine for me. I need it.

------------------------------

New updates:

I discovered that when you insert a segment to keep (via markers) in the cutlist with the thumbnails clicking the "+" button, the timings (with relative corresponding frames) are displayed and saved incorrectly. Example:

selected cutin for segment 1: 2:15:20.460 (I frame) -> actual saved selection: 2:15:20.480

selected cutout for segment 1: 2:15:49.620 (I frame)-> actual saved selection: 2:15:49.600

selected cutin for segment 2: 2:20:40.540 (I frame) -> actual saved selection: 2:20:40.560

selected cutout for segment 2: 2:21:08.300 (I frame)-> actual saved selection: 2:20:40.320

I closed and reopened the recording file to see if the preview window works correctly, with the I-Frames reported again at the same timecode, and that is!, so the preview and I-Frame identification work correctly (i think).

So i manually edited the .tdscuts file inserting the correct times, and when i load it, the cutpoints loads correctly!, at the correct times & frames (all I-Frames).

Is it possible to correct this bug?

Hope these findings may help.

Sorry, during the holidays we have not the time to look into this, because the analysis of such problems is a bit complicated and time consuming.