Messages

1

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: June 18, 2015, 05:19:19 PM »

... 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.





 

2

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: May 05, 2015, 01:37:52 AM »

Hello Olga,

Any developments?

Thanks.

3

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 24, 2015, 09:40:29 AM »

 

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.     







 

4

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 23, 2015, 05:37:23 PM »

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. 

5

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 22, 2015, 02:05:55 PM »

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.

 

6

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 18, 2015, 10:10:27 AM »

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.

7

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 15, 2015, 11:48:32 PM »

I'm still here.

8

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 05, 2015, 03:41:53 PM »

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.     

9

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 04, 2015, 03:46:57 PM »

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.

10

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 04, 2015, 12:54:42 AM »

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

11

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 03, 2015, 09:11:40 AM »

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. 

12

Video Splitter / Re: Bad frames at splice points when trimming AVCHD files

« on: April 02, 2015, 02:19:37 AM »

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.

13

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.


       

14

Video Splitter / Re: Native MTS clips from Canon AVCHD camcorder will not load

« on: March 29, 2015, 01:13:31 PM »

Hi Olga,

Yes, with that beta version, MTS clips from my HF-G10, as well sample clips I had from HF-G30 and HF-S20 camcorders will all now load.

Do you still want me to upload a sample file ?

Thanks.

Edit: And, out of interest, what was the problem with these files? 

15

Video Splitter / Re: Native MTS clips from Canon AVCHD camcorder will not load

« on: March 27, 2015, 03:16:35 PM »

You most certainly will.

Thanks. Well, it's nice to receive a reply from someone at least, and I'm glad you have confidence that I will eventually receive a response from the developers because I find it a bit puzzling that I haven't.

But I would not necessarily expect the developers to have exactly that kind of equipment.

No, but in stating that Video Splitter supports AVCHD files and providing a list of 'famous' camcorder models that support that format, including the Canon HF-G10, one would think that the developers would have at least tested representative sample clips from those models listed to ensure compatibility.

http://www.solveigmm.com/en/faq/avchd-camcorders/

I also tested some native mts clips from a Canon HF-S20, which is basically the same as the HF-S21 model listed on that page, as well as clips from a Canon HF-G30, which is Canon's current flagship model and an upgrade to the HF-G10, and none of those clips would load either. So clearly, this is not a model-specific issue and possibly applies to the entire series of Canon AVCHD camcorders.
 

A short MTS clip (provided e.g. via some upload service) showing that effect might be helpful.

I will be happy to oblige if that's what the developers request, when or if they reply. 

Coming here was the right choice.

Hope so.