Freesat issues

[PerryM]

A curious experience for others to benefit:
I use TS Doctor on recordings made from 'FreeSat' in UK. At some stage a few months ago, Channel 4 recordings became very slow to process. I have just changed my anti-virus from AVG to Avast (both free versions) and the processing speed has returned to normal (ie same as ITV & BBC). Go figure!
Whilst I have the stage, a couple of moans concerning the navigation in the editor. The forward jump to the next I frame often doesn't work - it effectively goes into 'play'. I have an effective workaround but it is annoying. The rearward jump always works fine. Also the navigation during the title segments of a movie on BBC HD becomes so slow as to be unusable. I'm using the LAV decoder. I have just noticed the latest update to v 1.2.162 so maybe that will work better.
FWIW

[Djfe]

general:
have you used the avg remover to correctly remove everything left from your old antivirus programm?

maybe AVG causes issues (I have switched to Avast some time ago as well, so I don't know), but since it works fine now with Avast, you have no issues anymore, right? (could be that AVG slows down the io speed of the tsd somehow by checking ts files or the tsd itself for viruses)

if the jumping doesn't work correctly, then often the cause is the splitter
mostly the haali works (default setting for automatic) but sometimes you can test out the LAV Splitter
if both of them cause issues it might help to fix the file first (no cutting at all), then reopening and cutting the fixed file

if that doesn't work it might help to use the TS Remuxer (I think you need to have the tsmuxer installed (supported tools))
tools -> expert tools -> TS Remuxer (remux to ts)

maybe that helps, if not we will try to help you from there

I don't know anything about how the navigation in BBC recordings is, because I don't record freesat, but I have heard similar stuff from other people in this forum
maybe @Mam knows something about it/is able to help you

it's good that you use the lav decoder (works best of all decoders)

[Mam]

@MAM only records BBC now and then, not ITV or any other stations. so @MAM cannot really compare.

But of course @MAM could point out that "*.ts" should be surely one file ending you should deny to ANY virus scanner. It makes no sense to scan these files, and because they are usually really huge, they can make a system slow as a dog when a rogue scanner tries to find anything evil in those innocent movies...
Any scanner has a whitelist somewhere, use it!

But back to BBC Navigation... yeah, its very very annoying. Cutting BBC is bad too with the doc, some constellations of hard/software seems to produce artifacts at cutting points, others seem to work flawlessly (of course, like Murphy told us, MY do always produce problems  )
The navigation problem is depending on the content of the film. Good old Mother BBC is nice and usually shows slowly scrolling backtitles at the end. This looks good and "serious" but it also is very well compressable because there is not a big and fast change between two frames. This leads to much smaller files but has the drawback that the navigation seek also has a lot of stress to find the next point it can resync to the film. Remember, the videostream has no real timing encoded, its just a series of encoded frames where sometimes a "full" frame (complete picture, a point where you can (re)join playback) is shown and in between only "differential" frames are send (only the changes to the last frame, no point to start).
The navigation "seek" function is just a bit more than an educated guess. It looks at the frames before, calcs how many (and how big) the difference between two full frames is, lowers this value a bit, add the result to the current file position, reads from the new position and reads as long, as a full frame appears.
Sounds complicated? yes it is, and its really JUST A GUESS!
So after the add it starts reading SOMEWHERE, and there is a very good chance that it ends up in the middle of something, it may take a while until it can resync, its not guaranteed to always be able to catch the next frame simply because it is still out of sync at that time.
And now remember the slowly changing backtitles... good compression means that there is no need for many "full frames", they only appear after "enough" has been changed in the picture to make it worth to spend the bytes for a full frames.
So this two things come together usually at the end of a movie and they add up, sometimes so much that you are unable to use the navigation keys at all.

The only help I found so far in this situation is to go backwards as far as navigation is still possible. Then I playback the rest until I am close to the desired cutting point (or slightly over it already). Quickly jump on the STOP button and then hit "-1I" to go back to the last full frame. This usually works because those frames are still fully decoded in the play buffer and (backward) seeking works. But it can take a few approaches and kill your nerves.
But with less coffee and more Beta Blockers you can come to a fairly nice result 

[Cypheros]

But with less coffee and more Beta Blockers you can come to a fairly nice result

Yes, he knows what he's talking about 

[PerryM]

Thanks guys - much appreciated.
As a matter of passing interest, the video encoding is a little more complicated than that! Essentially the encoder has the full ('I') frame and a set of vectors that represent pixel movement in the picture for the next frame. It uses these to generate a predicted frame and then compares it to the real frame and computes an error map. Clearly the more accurate the prediction then the smaller the error and thus the smaller the required data, especially after compression that effectively discards insignificant results. This is why H.264 is more efficient than MPEG2, it has a much more accurate vector system. The decoder is presented with the same I frame and vectors and thus computes the same predicted frame, which it can then modify with the supplied error map in the TS data stream. This clearly results in a more complicated processor load for the decoder than the simple differential model suggested by MAM.
The real H.264 protocol is somewhat (!!) more complicated but this is the jist of it.