"Dead" keyframes in mp4 cut

[harrym]

Problem is still here.

[Jan Gruuthuse]

What build are you referring to?

[fish]

Actually on reflection, I have been seeing the dead 'key frame' in edits using Avidemux 2.6.12 (standard release) but only when editing DVB-T HD in copy mode. Some edits produce a freeze at an edit point and some don't. On playback, after the freeze in the video, the playback continues when the play head reaches the next key frame. If I move the play head back to just behind where the freeze occurs but before the next key frame, playback continues immediately, in frames that were frozen in continuous playback. I would assume this is related to problem I have mentioned earlier in this thread, about black frames at the first edit in mp4's in copy mode. I will try the nightly build to see whether this still occurs and if so, will look into posting a sample. The video is just standard DVB-T HD video, captured by USB tuner, so there is nothing unusual about it and I'd be amazed if the developers haven't reproduced it.

[mean]

Try a nightly

[Jan Gruuthuse]

The video is just standard DVB-T HD video, captured by USB tuner, so there is nothing unusual about it and I'd be amazed if the developers haven't reproduced it.

This could be provider (the ones who provide the signal on air or the TV channel) related. Each of these can use other parameters, without access to original recorded video: hard to detect what is going on.

On the other side this could be related to the usb dongle: hardware or driver issue and the used hardware where the dongle sits on: PC, STB and their used OS's.

could this also be the "null frame" (kind of black screen transmitted)?

[fish]

I have considered that the problem may be caused by inconsistent captured DVB-T HD files, although playback of the files before editing them did not show any issue. I have older versions of Avidemux on an external drive which I can try, to see if the problems are consistent on older versions. The problem only began after v2.6.10, so either the DVB-T HD's have changed to cause the issue or something in Avidemux has changed to cause the issue. The black frames after the first edit occurred with different mp4 files, not DVB-T HD files. I see an Avidemux v2.6.13 just been made available, so there's an excuse not to install an older version. Onwards and upwards.

[harrym]

This problem isnt typical only for captured stream. In ffmpeg reencoded videos is too.

Interesting is, that if you have a several consecutive dead keyframes - you can reopen avidemux-reencoded video (with dead keyframes at starting), and obviously the 2nd keyframe (which was not done previously satisfactorily cut) can be revitalised for cutting (before not).

It testifies to the fact that each keyframe is generally suitable for editing, just avidemux not correctly interpret it.

[fish]

Yes, I have noticed that the frames, just after the cut,  that no longer play in continuous playback, do seem to be ok because they play if the play head is moved to them. I have also noticed that either the 'Frame Type' indicator in Avidemux, is displaying I-frames as P-frames or keyframes in DVB-T HD can be I or P-frames. When next keyframe is selected, Avidemux quite often goes to, or indicates, that it is on a P-frame. This may be due to a feature of of TS files. There was one BBC HD capture I had of the Olympics I was editing, that had over 15 minutes of P and B-frames but no I-frames, at least according to the indicator in Avidemux.
There is a very useful utility called G-Spot for showing GOP information but it is quite old and the 'display GOP structure' feature only works for MPEG1 and 2 files. There may be a similar, more up to date utility, for MP4 files I must take a look.

http://www.free-codecs.com/gspot_download.htm

[mean]

Look at the difference between I & IDR

[fish]

I don't remember seeing IDR frames in DVB-T HD files. I see I-FRM, I-TFF, P-TFF, when moving through keyframes and B-TFF, P-TFF, as well as the other 3 when moving from frame to frame. I will keep a lookout for IDR frames.

[mean]

For mpegTS, the alternate way is to have recovery time at 0, when that happens it is a IDR in disguise

[fish]

I had a short DVB-T HD file recently that exhibited the freeze problem, so decided to chop  it up, firstly into two parts. Part 1 from the beginning to the I-frame where the freeze occurs and part 2, from the I-frame where the freeze occurs to the end. Both parts played without any signs of a problem.
I also cut the file into 3 parts. Part 1 from the beginning  to the I-frame where the freeze occurs,  part 2, from the I-frame where the freeze occurs to the I-frame where play resumes in the original and part 3 from I-frame where play resumes in the original to the end. All parts played without any signs of a problem.
I then joined the two parts together and the three parts together and the two new files exhibited the same freeze problem as the original.
One thing I did notice when I reduced the playback rate in MPC, was a slight glitch a few frames before the I-frame where the freeze occurs. I guess these sort of .TS files are prone to these sort of tranmission glitches from time to time and the only way to repair them is to split the file or re-encode.

[mean]

yes, errors in TS are pretty common
Depending on the type of error, it can be a problem for avidemux
A player will just skip and resume later
Avidemux is trying to seek accurately, and if it fails at finding the correct seek point/ decodable starting point, it will bail