Cutting window freezing

Begonnen von jaydear, Juli 25, 2019, 23:42:24

« vorheriges - nächstes »

jaydear

The cutting window is intermittently freezing when I'm looking for an 'out' frame. This problem is becoming more frequent.

All controls work until I set an 'in' point. I can move the playback cursor manually whilst playing or paused and the picture changes as expected. If I then select a time shift button (+10s / +1m / +1s, -1m / -10s / etc.) the picture may continue to update or just freeze. Pressing the + or - IF button appears to unfreeze it, but if I press pause the picture jumps to some other time and freezes again.

If I press the Play button, the timer runs but the picture stays frozen. If I press the +1F button the timer runs but the picture stays frozen and it never finds another I-frame. HUGE problem!

TSD has done this before, but it always recovered if I jumped back and forth a few seconds. I'm using v2.2.21 to cut off-air h.264 TS files.

The.Doctor is the ants' pants :)

Cypheros

Change "Default Video Renderer" from "Haali Video Renderer" to "AUTOMATIC" or "Video Renderer" under Settings/Preferences/Preview.

jaydear

I have tried all the renderers as well as Automatic, but they made no difference to the problem. I locked in Haali because in Automatic I could see the Haali icon in my notification area.
The.Doctor is the ants' pants :)

jaydear

You will recall I was having cutting area issues with files from a certain broadcaster, and that TSD was generating huge logs. I don't have that particular problem now, but it is largely recordings from that broadcaster that are freezing during cutting. The recording that helped you find the "no cutting area" (huge log) problem may assist you with this. If not, I can send you a problematic one.

There is still something unusual about those recordings that causes problems in VRD v6, even though the files have been cleaned in TSD. In VRD v5 they won't open at all and just crash it. I've also tried opening them in Vegas v15 which does claim to support them, but they crash Vegas unless muxed to mkv. They are still uneditable in Vegas though. The audio is OK, but the video is just the station logo on a black background. I didn't know the logo has it's own stream, but it must because it fades in at the start, out at the end and any animation is viewable. MKVtoolnix doesn't seem to list a separate stream for the logo, but I'm not an expert with it yet.

The cleaned TS files do open in Ashampoo Movie Pro 3, but it struggles and is very slow even on a fast PC with heaps of RAM. Ultimately it just crashes when I try to export the edited result  ::)  I've also tried Open Shot, which does open them, but it has similar problems to Ashampoo Movie Pro 3.  DVB Inspector can load them, but it's like hacking through a jungle  ;D
The.Doctor is the ants' pants :)

Cypheros

Sorry, on vacation for 2 weeks. Will look into it, if I'm back.

jaydear

The.Doctor is the ants' pants :)

jaydear

Just an update on this problem... When it occurs I add a couple of +10 sec jumps to make sure I'm getting the end, but they may not make it into the saved file and it may take a few retries to get the whole program. I have to jump ahead far enough to see the video is playing.
The.Doctor is the ants' pants :)

jaydear

I think I've found the cause of this problem. It was always occurring near the gap between programs in the editor. I have never used the Auto-Cut feature so Auto-Cut was not selected. To investigate, I turned it on which revealed several more tabs. I entered each one and deselected everything I could. I think some of the settings were still active, probably the ones relating to the EPG, even though Auto-Cut was not being used. I Turned Auto-Cut back off and the problem seems to be gone  8)
The.Doctor is the ants' pants :)

jaydear

Nope... I was wrong. It still gets strange in the gaps - freezing and saving a shorter file than selected  >:(
The.Doctor is the ants' pants :)

jaydear

This problem is becoming a major nuisance now! After returning from my holidays I have a lot of recordings to process and most of them are having this freezing problem. I'm using v2.2.23. I'm happy to send you a recording.

I really need some help with this please Frank.
The.Doctor is the ants' pants :)

Cypheros

Sure, I will look into it. Please send me first an application report, so I can see your settings and maybe some error messages, giving a hint about the source of the problems. You can create the report under Help/Application report.

Please do not post the report here. Send the report to: support(at)cypheros.de

jaydear

I'm currently using the newer version of LAVlight instead of Haali splitter. LAVlight causes the cutting window to behave differently, but not what I'd call better, just different :( 

With my 'problem' recordings I'm having difficulty searching for I-frames. Just to remind you: I try to get close to 10 secs lead-in to help with muxing in the subs and if I don't select an I-frame as the first frame I usually get a file from TSD that is missing part of the wanted content - and now I think I know why that happens.

With LAVlight, the cutting window does not search backwards successfully with my 'problem' recordings, and forward is not much better, e.g. searching backwards will often stop without finding an I-frame, if it does find one and I search forward it may find the next one or some random one, if I search backward it should find the previous one again, but usually doesn't.

If I make a list of the timecodes found by I-frame searching it is obvious that +IF and -IF are quite random.

The freezing problem is different too. The cutting window does not freeze for 15 seconds, it is more like 1 or 2 seconds and it always freezes briefly after any jump, which makes searching for in- and out-points very tedious.

I started trying to research what might be the problem and discovered at streaminglearningcenter.com that IDR and I-frames are different things :o  IDR frames don't seem to be mentioned in TSD and I'm wondering if my problem recordings have some non-standard arrangement of IDR- and I-frames or if they are just too far apart?
The.Doctor is the ants' pants :)

PerryM

Just to say that if your broadcaster is the BBC then they are using a particularly aggressive compression protocol that results in it becoming almost impossible to find I-frames. This is particularly a problem with closing credits.
It often helps if you play this section at normal speed and then step back to find your cut point.
FWIW

jaydear

It's interesting to examine the data rate using the TS Bandwidth-Meter in Expert Tools - in the case of non-commercial channels there are huge dips (down to almost zero in AU) at the end of programs. The commercial channels do not do that as aggressively and the commercial channels' sequences of I- and IDR-frames are VERY different compared to non-commercial (why?).

Apparently, IDR-frames are essential for successful searching. My experience is that Haali is much better than LAVlight at finding I-frames, but it loses the plot when the data-rate drops. Then Haali takes around 15 seconds to get over it, after which, as you say, searching backwards can work. LAVlight doesn't freeze as long (about 2 seconds), but does not seem as competent at finding I-frames in the first place.
The.Doctor is the ants' pants :)

PerryM

Here is not the place for a lecture in compression protocols and algorithms! Suffice to say that the main idea is to remove redundant information, and in the case of a typical sequence of end credits (white on black lettering) then the video information is close to zero! It is only possible to utilise this by having a very long period between I frames.
The bottom line is that currently in UK, the BBC transmits about a third of the data used by Channel 4 which uses a near constant bit rate (CBR). The BBC bit rate will vary widely (VBR) dependent on the scene content. ITV uses a protocol between these two extremes, although until a couple of years ago it used a CBR scheme as well.
As a matter of interest, picture noise is interpreted by the encoder as information, so older films require a higher data rate. It is thus common for popular movies that often get reshown to be digitally enhanced to reduce the noise and thus the data rate requirement.
FWIW


www.cypheros.de