Avidemux 2.7 64bit Windows 10 - Picture errors after cutting on I-Frames

[Celas]

I really like this program. I use it to cut commercials from TV recordings (German TV).
The sources are according to Avidemux's Information page.

Code Select Expand


=====================================================
Video
=====================================================
Codec 4CC: MPEG
Image Size: 720 x 576
Aspect Ratio: PAL 16:9 (64:45)
Frame Rate: 25.000 fps
Total Duration: 01:00:31.460

=====================================================
Extra Video Properties
=====================================================
ExtraDataSize: 00

=====================================================
Audio
=====================================================
Codec: MP2
Channels: Stereo
Bitrate: 24000 Bps / 192 kbps
Frequency: 48000 Hz
Total Duration: 01:00:30.816


Because on the TV stream, the GOP ist always the same: IBBPBBPBBPBB the end of commercial / re-start of show rarely is on an I-Frame.
However, sometimes the station will repeat several seconds of the show after the commercial that was already shown before. Again, because of the fixed GOP structure, the I-Frames don't usually match.

What I do in those cases is, to place the B marker on an I-Frame after the commercial, go back to before the commercial, look for the exact frame and place the A marker on that. Then I hit delete to remove the commercial. I repeat this for all other commercial breaks.
At the end I copy both the Video and Audio Outputs and use Mpeg TS Muxer (ff) as format.

Sometimes this will corrupt the first GOP after the cut. Starting with the I-Frame that the B-Marker had been on, which is still fine, the entire GOP up to the next I-Frame will have artifact blocks. This can even be seen when I open the saved file back in Avidemux and navigate to that place.

One example where this happened, the resulting frame sequence is:

Code Select Expand


IBBPBBPBBPIBBPBBPBBPBBI
1111111111Bccccccccccc2

The frames marked 1 are from before the cut, the frame marked B is where the B-Marker was, the frames marked c are corrupt and starting from the last I-Frame the picture is back to normal.

In a different example that surprisingly didn't result in any picture errors, the frame sequence after the cut is:

Code Select Expand


IBBPBBPPBBPBBPBBPBBI
1111111B222222222222

Again, frames marked with 1 are from before the cut and 2 after the cut.
Note the frame marked with B, which must have been the I-Frame that the B-Marker had been on, seems to have turned into a P frame.

I want to say I didn't used to have this problem with Avidemux 2.5 and before, but I can't say for sure anymore.


PS: On an unrelated note, do you think it would be possible for the preview picture (the one shown while moving through the file and setting the A- and B-Markers) to be rendered in accordance with the PAR?
As in this case, it's 64:45 in many of my sources and the picture looks horizontally squished. It's not really a problem, just a little bit annoying to look at.

[eumagga0x2a]

Could you please retry with the latest nightly?

http://avidemux.org/nightly/

I agree that using square pixels for videos with a different PAR doesn't look perfect and poses problems when adding a logo. Not on my todo list though.

[Celas]

I just tried the nightly build from avidemux_r171031_win64Qt5_480.zip

It didn't produce the picture errors as before, but there is still something strange going on.
This version seems to drop two B frames before the cut. This was noticeable at the second cut, because it was during a camera pan, causing a jump.

I noted down the frame sequence before the cuts and after. After the cuts I also noted the timestamps of each frame to show where the missing B frames should be.

Code Select Expand


First cut:
Before save:
IBBPBBPBBP BBI...PBB IBBP
           A         B
After save:
I 22:30.840
B 22:30.880
B 22:30.920
P 22:30.960
B 22:31.000
B 22:31.040
P 22:31.080
B missing
B missing
P 22:31.200
--- cut
I 22:31.280

Second cut:
Before save:
IBBPBBPBBPBBI BBP...PBB IBBP
              A         B
After save:
I 35:42.760
B 35:42.800
B 35:42.840
P 35:42.880
B 35:42:920
B 35:42.960
P 35:43.000
B 35:43.040
B 35:43.080
P 35:43.120
B missing
B missing
I 35:43.240
--- cut
I 35:43.320


[eumagga0x2a]

Dropped B-frames might have had references in the future (in the deleted range), so that they actually belonged to the next GOP.

[Celas]

I admit that I don't quite understand every nuance of MPEG encoding.
Especially the fact that B frames might also need information from LATER in the stream to be able to render correctly.
Why any streaming service (which is what regular TV broadcasting is) would opt to encode in that matter is quite beyond me. Assuming of course, that there IS actually any option to do it differently, but I assume there is.

Anyway, since I discovered that Avidemux can actually use the Nvidia hardware encoder, I've changed my processing queue. I will now place my cuts on any frame I well please and re-encode the cut sequence with the hardware encoder at a fairly large bitrate, so that it hopefully doesn't introduce any perceivable artifacts and then encode the entire file again with Handbrake later, which is what I did after my previous Cut-and-Copy approach in Avidemux.

This has the advantage of making the placement of the cuts faster, since I don't need to hunt for the exact same frame before and after the commercial. Also in the case where they don't repeat part of the show, I can remove only the commercial, where I used to either lose a few frames of the show after the commercial or leave a few frames of the commercial.

But thanks for looking into this, anyway.

[eumagga0x2a]

Especially the fact that B frames might also need information from LATER in the stream to be able to render correctly.

Not in the stream. B-frames always need information from later in the video (which arrives earlier in the stream as these B-frames are shown). This is why they are called B (bidirectional) frames.

By reencoding you always lose quality, especially if you reencode twice.

[Celas]

I had always assumed that the frames would appear in sequential order in the stream. If that's not the case, I suppose it makes more sense to have B frames.

As to re-encoding twice. I run the first one on the hardware encoder with ridiculously high bitrates (like the default values of 10000 to 20000 kbit/s).
After all encoding is done, these files usually come in at around 700-800 kbit/s
And honestly, looking at the results, I'm fine with the resulting quality.

I just had a crazy idea. Not sure if it's possible. As far as I know, each frame can specify how long it should be displayed. Usually in a fixed framerate stream, each frame would have this parameter set according to the framerate.
If this is indeed possible to specify for each individual frame, what would happen if the program simply set the time for each frame that should be cut to 0?
When playing the resulting stream, the player should essentially skip over the frames. Might cause some delay if the decoder actually completely decodes all those frames, but if you then run that altered stream through something like Handbrake to re-encode, it might work. If a B frame needs information from a frame that should be skipped, the frame itself along with all its information would still be there, but because it's not to be actually displayed on playback, Handbrake should not include it in the final file...
Of course, that option would only really be useful in my specific usage scenario, cutting commercials out of TV broadcasts.

And before you ask why I don't simply use Avidemux for my final encode.
1. I'm used to the encoding options in Handbrake and I find the options panels in Avidemux rather confusing. I tried it once with settings that I figured where close to what I do in Handbrake, but the resulting file was significantly larger. Also: Handbrake CLI.
2. I usually cut several episodes or movies at once and then bulk encode them over night. I don't really want to wait for Avidemux to encode and save.