Bad frames at splice points when trimming AVCHD files

Whilst awaiting your response I've also examined the trimmed output of a few other AVCHD camcorder MTS files I had to hand - 1080/60i clips from my Canon HF-G10 and an HF-S20, 1080/60p clips from a Panasonic TM900 and 1080/50p clips from a TM700. In all cases the trimmed 'selected fragments' likewise over-shot the 'end' marker by a full GOP - that's half a second of video.     

Hello Olga,

The files are uploading to WeTransfer as I write. You will receive an email notification when it is complete. It's a rather large folder (482MB) as I included the output files as well as the source 1080/30PF MTS clips. I also included a Word document that gives the details.

Thanks.

Thanks. I'm a bit busy today, so will upload the files tonight. I'll put them together in a single zip folder.

Hello WorBry,

Thank you for your reply.

Sure you can use any convenient for you file host service to send the file(s). Please specify our support(at)solveigmm(dot)com email address.

Unfortunately, I deleted the project files I had for those tests and so will need do them over again.

I don't use Google Drive or Dropbox and would be prefer to upload using WeTransfer, in which case I will need an email address for you as the recipient. If that's OK with you, could you PM me the email address.

Thanks. 

Dear WorBry,

Thank you a lot for your report.

Could you please upload for us the original input file(s) from your camcoder to e.g. Google drive or Dropbox.com to reproduce all this issues at our end?

Also please send us project files for all this issues. To get the project file select fragments for saving then Go to "File" menu -> Save project as.

Thank you in advance.

And another thing I'm finding when trimming (making cut-excisions) in 'frame accurate' mode is that the mark-out point for a selected 'fragment' is not being respected. The mark-in point is frame accurate, provided one allows for the fact that the first frame of selected 'fragment' will be the frame after the marked frame. But the rendered 'saved fragment' retains up 15 frames beyond the 'mark-out' frame. This happens irrespective of whether the selected fragments are saved as individual files or rendered together in a single stream (i.e. Trim mode). That is hardly frame-accurate cut editing and is very frustrating.

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.