Topics - WorBry
1
Video Splitter / Bad frames at splice points when trimming AVCHD files
« on: March 31, 2015, 12:24:12 PM »
Hi,
As a follow on to my last post:
http://www.solveigmm.com/forum/index.php?topic=4837.0
Now that I can load MTS files from my Canon HF-G10 AVCHD camcorder, I've been running some more tests, making random cut-excisions (trims) in both frame-accurate and key-frame accurate modes. On examining the outputs, one thing I've noticed that the last frame of a 're-joined' "selected segment" frequently is very bad quality. Analyzing the GOP structure with Elecards Stream Eye (demo version) I can see why. This 'bad' frame, when it occurs, is a P frame with an extremely low bit size, and is always preceded by an I frame, also with a relatively low bit size.
Here are two examples, the first showing the GOP sequence around a 'splice point' after frame accurate trimming. Original file was a 1080/30PF (PsF) MTS clip from the HF-G10.
http://i1276.photobucket.com/albums/y475/WorBry/Video%20Splitter%2030PsF%20Frame-accurate%20trim_zpscggjjaca.png
The frames re-encoded by Video Splitter are those in the dotted rectangle. I know they are re-encoded because they have the Elecard watermark. Note the 'bad' P frame I was referring to.
And here's another example, this time using Key-Frame accurate trimming. As might be expected, the leading GOP after the join is not re-encoded, but the last two frames of the preceding segment are re-encoded - and again the low bit size I frame and the insanely low-bit size P frame.
http://i1276.photobucket.com/albums/y475/WorBry/Video%20Splitter%2030PsF%20Key%20frame%20accurate%20trim_zpsit0gywav.png
However, if, instead of 'trimming' to produce a single file, I save the 'selected fragments' as individual files, none of them have a bad terminal frame, and if I join those together using Join Manager, no bad P frame occurs at the splice point either. In fact, it doesn't look like any frames are re-encoded at the end of the individual fragments and, as far as I can tell, the only 'non-native' frames appearing at the 'join points' are those that were re-encoded to re-construct the leading GOP when the selected fragments were produced (from frame accurate cutting, that is).
So, is it really necessary that the trimmed files are re-constructed in a way that generates these bad frames? My incentive for using a 'smart trimmer' like Video Splitter is to remove unwanted frames, not to generate more in the process.
Edit: It's interesting that trimmed 1080/60i MTS files from my Canon HF-G10 show these 'bad' (P) frames at the join points only occasionally, and with 1080/60p MTS files from a Panasonic TM900 camcorder, I can't see any at all. So this does seem to be an issue with 1080/30PF MTS files in particular.
As a follow on to my last post:
http://www.solveigmm.com/forum/index.php?topic=4837.0
Now that I can load MTS files from my Canon HF-G10 AVCHD camcorder, I've been running some more tests, making random cut-excisions (trims) in both frame-accurate and key-frame accurate modes. On examining the outputs, one thing I've noticed that the last frame of a 're-joined' "selected segment" frequently is very bad quality. Analyzing the GOP structure with Elecards Stream Eye (demo version) I can see why. This 'bad' frame, when it occurs, is a P frame with an extremely low bit size, and is always preceded by an I frame, also with a relatively low bit size.
Here are two examples, the first showing the GOP sequence around a 'splice point' after frame accurate trimming. Original file was a 1080/30PF (PsF) MTS clip from the HF-G10.
http://i1276.photobucket.com/albums/y475/WorBry/Video%20Splitter%2030PsF%20Frame-accurate%20trim_zpscggjjaca.png
The frames re-encoded by Video Splitter are those in the dotted rectangle. I know they are re-encoded because they have the Elecard watermark. Note the 'bad' P frame I was referring to.
And here's another example, this time using Key-Frame accurate trimming. As might be expected, the leading GOP after the join is not re-encoded, but the last two frames of the preceding segment are re-encoded - and again the low bit size I frame and the insanely low-bit size P frame.
http://i1276.photobucket.com/albums/y475/WorBry/Video%20Splitter%2030PsF%20Key%20frame%20accurate%20trim_zpsit0gywav.png
However, if, instead of 'trimming' to produce a single file, I save the 'selected fragments' as individual files, none of them have a bad terminal frame, and if I join those together using Join Manager, no bad P frame occurs at the splice point either. In fact, it doesn't look like any frames are re-encoded at the end of the individual fragments and, as far as I can tell, the only 'non-native' frames appearing at the 'join points' are those that were re-encoded to re-construct the leading GOP when the selected fragments were produced (from frame accurate cutting, that is).
So, is it really necessary that the trimmed files are re-constructed in a way that generates these bad frames? My incentive for using a 'smart trimmer' like Video Splitter is to remove unwanted frames, not to generate more in the process.
Edit: It's interesting that trimmed 1080/60i MTS files from my Canon HF-G10 show these 'bad' (P) frames at the join points only occasionally, and with 1080/60p MTS files from a Panasonic TM900 camcorder, I can't see any at all. So this does seem to be an issue with 1080/30PF MTS files in particular.