Solveig Multimedia Forum - Get help for video editing software
SolveigMM End-User Products => Video Splitter => Topic started by: WorBry 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 (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 (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 (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.
-
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.
-
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.
-
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.
-
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.
-
Thanks. I'm a bit busy today, so will upload the files tonight. I'll put them together in a single zip folder.
-
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.
-
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 WorBry,
Thank you for files you have sent and excuse for the delayed answer.
We currently test them. As soon as there will be any results, I'll post here.
-
I'm still here.
-
Hello WorBry,
Thanks for your patience.
Please try to use Video Splitter 5 beta version with the fixed issue at the link below. Will it also work at your end?
http://solveigmm.com/files/SolveigMM_Video_Splitter_Home_Edition_5_0_1504_16_Beta.exe (http://solveigmm.com/files/SolveigMM_Video_Splitter_Home_Edition_5_0_1504_16_Beta.exe)
http://solveigmm.com/files/SolveigMM_Video_Splitter_Business_Edition_5_0_1504_16_Beta.exe (http://solveigmm.com/files/SolveigMM_Video_Splitter_Business_Edition_5_0_1504_16_Beta.exe)
-
Hello Olga,
Well I'd like to test the beta but the 21 day trial evaluation period has now expired.
I have sent you an email.
Thanks.
-
Hello WorBry,
Just for your knowledge, you can test it by clicking the "Later" button on the first window that will be opened after Video Splitter launching.
Thank you.
-
Thanks Olga.
Having just re-run some 'trimming' tests using the AVCHD sample clips I have to hand, the beta does indeed appear to have fixed the two issues I addressed.
The last frame of each 'selected fragment' now respects the 'end' marker point, with no GOP overshoot - and that's in both frame-accurate and key-frame accurate modes.
I also re-tested the 1080/30PF MTS clip I sent you that had produced the 'bad' (insanely low bit size) end B-frames on trimming. Although the re-encoded frames (as identified by the Elecard watermark) are, in general, slightly lower quality than the native frames when inspected closely (marginal loss of fine definition), that is, to some degree, only to be expected - but I could not see any 'bad' frames as such. And analyzing the trimmed streams with Stream Eye I couldn't see any frames with abnormally low (or null) bit sizes either.
Also, all of the trimmed AVCHD clips I've tested so far play back perfectly well on my PC (MPC-HC) and on a set-top player (PS3/HDTV) - no skips, dithers or freeze-ups.
I'll come back to you if I find any other issues on wider testing, but it's looking good. I think can see myself using Video Splitter for native cut editing of AVCHD clips.
If I might make a few suggestions/requests at this point:
1. Would it be possible to display in some way an analysis of those frames that will be (ideally) or have been re-encoded after rendering? In the trial version the re-encoded frames can be be recognized by the Elecard watermark. It would be helpful to have some means of identifying the re-encoded frames in the licensed version also. "Smart" native cut-editing is, after all, about preserving as much of the original source video as is possible.
2. In the time-line 'zoom control' could you possibly include a 'Key-Frame' level view, in addition to frame level ('Frame Mode') ? I appreciate that at all zoom levels one can use the navigation controls to go to the next or previous key-frame, but I would find it useful to see a timeline displaying the key-frame thumbnails, at least for AVCHD files with a regular, repeating GOP structure. Or else maybe you could highlight the key frames in some way in the 'Frame Mode' view?
Actually, what would be really nice is if there could be a 'scene change' view, or at least some way of marking on the time-line where scene changes occur. I am of course thinking of the type of feature offered in most NLE's where a clip placed on the storyboard timeline can be split at scene changes (as judged by scanned frame 'content'). Something for the future maybe? Still I'd settle for a 'Key-Frame Mode' view if that's readily do-able.
Thanks.
-
Hello WorBry,
Thank you for your suggestions.
We will discuss them with our tean and possibly add them to Video Splitter's next releases.
If such features appear in the product, I'll post here.
-
OK, thanks.
Thinking about it more, highlighting the Key Frames in some way (colored border or something) on the frame level (Frame Mode) timeline probably would be the better option - and probably the easiest to implement?
Cheers.
-
The last frame of each 'selected fragment' now respects the 'end' marker point, with no GOP overshoot - and that's in both frame-accurate and key-frame accurate modes.
Correction on that. The marked start frame of a selected fragment is always bang on, but 2-3 frames are now lost at the end of the fragment i.e. the end cut is made 2-3 frames before the marked frame. So now, instead of overshooting by a full GOP (15 frames for 30PF), its undershooting.
I picked it up when I was comparing the quality of the trimmed files and fragments with the source MTS files which I trancoded to a lossless YV12 intra-frame format (MagicYUV) to make reference clips cut at same frame points. For the metric quality tests (SSIM, PSNR) I also transcoded the Video Splitter outputs to MagicYUV. Couldn't understand at first why the frame lengths of the reference and test clips didn't match up, until I discovered that end frames were being deleted by Video Splitter.
As a case in point:
1. Took a native 1080/30PF mts clip - 8670 frames
2. Made 5 cut marker points at random with Video Splitter (in Frame Accurate mode), producing six fragments.
3. Saved all six fragments as individual files. The frame counts of the fragments were, in order: 1623,1370,1656, 1394, 921, 1692 = Total 8656.
4. Rejoined the fragments with Join Manager. Frame count of recombined clip was 8656 - same as the sum of the saved fragments. And when the clip was played back you could see a frame jump at the join points.
5. Then I used the same cut marker points to produce a trimmed file, excising the 1st, 3rd and 5th segments. Frame count of rendered trimmed file - 4456, which is the same as the sum of saved fragments 2, 4 and 6.
So, irrespective of whether the clip was trimmed or split into fragments, 14 frames were 'lost' with the 5 cuts.
Something to be looked at I think.
Edit: I wonder, is this the reason why other 'smart trimmers' I've looked at (Video Cutter, Smart Render 4) perform more extensive GOP re-construction on both sides of a cut/re-splice point. In the case of Smart Renderer 4, that can often extend to five GOP's - that's 2.5 seconds of re-encoded video which is quite significant if you are editing relatively short clips. Please don't go that route if you can avoid it. It's one of the reasons why I stopped using SR4 for cut editing AVCHD - that and the often low quality (low bit size) of the re-encoded frames. Same goes for Smart Cutter, which I only tried out.
Edit2: Just tested some 1080/60i MTS clips from my Canon HF-G10 and some 1080/60p MTS clips from a Panasonic TM700 and all show the same thing on splitting or trimming - deletion of 2-3 frames at the end of a selected fragment. So again, it's not some 30PF quirk.
-
Hello WorBry,
Thank you for your post. We have already noticed such behaviour of Video Splitter.
We will try to fix this in near future.
I'll write here as soon as the updated version will be released.
Thank you.
-
Hello Olga,
Any developments?
Thanks.
-
Hello WorBry,
Thanks for your patience.
Please try to use Video Splitter 5 beta version with the fixed issue at the link below. Will it also work at your end?
http://solveigmm.com/files/SolveigMM_Video_Splitter_Home_Edition_5_0_1504_16_Beta.exe (http://solveigmm.com/files/SolveigMM_Video_Splitter_Home_Edition_5_0_1504_16_Beta.exe)
http://solveigmm.com/files/SolveigMM_Video_Splitter_Business_Edition_5_0_1504_16_Beta.exe (http://solveigmm.com/files/SolveigMM_Video_Splitter_Business_Edition_5_0_1504_16_Beta.exe)
Olga, What´s the link of newest Beta version?
-
Hello minegroasprilla,
Links to latest beta versions of Video Splitter 5 are:
http://www.solveigmm.com/download/SolveigMM_Video_Splitter_Home_Edition_5_0_Beta.exe (http://www.solveigmm.com/download/SolveigMM_Video_Splitter_Home_Edition_5_0_Beta.exe)
http://www.solveigmm.com/download/SolveigMM_Video_Splitter_Business_Edition_5_0_Beta.exe (http://www.solveigmm.com/download/SolveigMM_Video_Splitter_Business_Edition_5_0_Beta.exe)
-
Hello Olga,
Any developments?
Thanks.
Hello WorBry,
This issue is in our "to do" list at the present time.
As soon as there will be the updated version ready, I'll post here.
Thank you for your patience.
-
... The marked start frame of a selected fragment is always bang on, but 2-3 frames are now lost at the end of the fragment i.e. the end cut is made 2-3 frames before the marked frame. So now, instead of overshooting by a full GOP (15 frames for 30PF), its undershooting.
It's been nearly six weeks now, and still no fix for what is a pretty fundamental flaw :(
You can hardly say that Video Splitter "cuts and joins up video and audio streams perfectly" if it drops frames in the process.
Can't understand why resolving this would not be considered a priority, especially as you were already aware of this behavior:
We have already noticed such behaviour of Video Splitter.
I'd really like to use Video Splitter for native cut editing of AVCHD files, I really would, but frame accuracy is crucial for me.