World's first frame accurate H.264 AVCHD cutter without re-encoding!

Hi!

I tried Smart Cutter 1.9.2f to cut HDTV video captured by DVB card (from German TV). Smart Cutter is easy to use and works very fast. But the result file does not play well. At the beginning and ending of the cut sequence, where the video is edited by Smart Cutter, playback doesn’t work in one way or the other. I have tried several players (Windows Mediaplayer, VLC, Graphedit from the Windows SDK, and also some SmartTVs). Either the playback freezes for a few seconds at the start, or the playback is jumping forward and backward by a few frames for a few seconds, or those few seconds aren’t shown at all. After the few seconds modified by Smart Cutter, the rest of the video plays nicely. So it is not that the source video is corrupted or incompatible with the players.

Can you have a look at it? Shall I upload a sample of the DVB .ts file?

I’ve done some more investigations, and found a few things in the generated result file that look strange and maybe need to be fixed. Are you interested in that analysis, too?

Best regards,
rrabit.

Dear rrabit:
Thanks for your message.

' found a few things in the generated result file that look strange and maybe need to be fixed.'
We want to know the details very much, thank you.

'upload a sample of the DVB .ts file?'
That will be very helpful.

It would be better if the sample file size is less than 50 MB.

If you can not find small sample, use this simple tool to split your movie file into small pieces, and upload any one of them.
http://www.softpedia.com/get/PORTABLE-S ... rger.shtml
-------------------------------------
before uploading sample, please create sub-directory with your name under the root, then upload sample to this sub-directory.

FULL priviliged --- mkdir, read, write, remove
Will be helpful to limit the sample file size under 50MB.
Thank you.

FTP Username: samples@fame-ring.com
Password: samples
FTP Server: ftp.fame-ring.com
FTP Server Port: 21
-------------------------------------
Here is also a step by step tutorial for uploading sample(s):
http://www.fame-ring.com/uphelp.html

Looking forward to your further message.
Thank you very much.

Best Regards,
FameRing Support Team

Dear FameRing Support Team,

I’ve uploaded the sample file Sample1.ts to /rrabit. To reproduce exactly the same result, use start point 8.560 and end point 27.480 with Smart Cutter. The result shows the effects I’ve described before.

When looking at the generated file’s individual frames, e.g., with Smart Cutter itself, or with other programs, the picture slices coded by Smart Cutter look fine, so the actual rendering seems to work fine.

To further analyse the reason for the problem when playing the output file, I’m using a test program I’ve written to verify the operation of ‘smart’ video editor programs. This program searches for modified or unmodified sections per each video or audio streams, and, for the matching sections, compares the presentation time stamps (PTS) between source and edited streams.

I used my program to dump the file position, the presentation time stamps (PTS), and the slice_type, frame_num, and pic_order_cnt_lsb from the H.264 stream packets. I also uploaded them as Sample1.txt and Out1.txt, and also used a tool to compare them and produce the Report.html comparison report, which I refer to in the details below.

I noted the following ‘oddities’:
a) For the first ‘group of pictures’ (from the first I slice to the second I slice), the original video uses slice types 2, 0 and 1, while the result file generated by Smart Cutter uses slice type 7, 5 and 6 (see lines 1 to 29 in the right file). It seems Smart Cutter changes the input format 1080i50 to 1080p25. The remaining part of the result file uses the original slice types.

b) Also for the first ‘group of pictures’, the pic_order_cnt_lsb goes from 0 to 56 (in this case), and increments by 2, while for the rest of the file it uses the original pic_order_cnt_lsb values and increments by 1. As a result, from the first ‘GOP’ to the second one, there is a discontinuity in the pic_order_cnt_lsb values. E.g., in this case it jumps from 56 to 472.

c) For the second ‘group of pictures’ (lines 30 to 103 in the right file), the slice counters (and actually the slice contents too) match perfectly bit wise with the input file, but you can notice that the PTS in the PES packets are incorrect. Each PTS has apparently a small random offset in the range of up to a few hundred clock ticks (a few milliseconds), and additionally every second PTS is off by 20 milliseconds. It seems that for the second ‘GOP’, the PTS are calculated for the 1080p format, but the slices are (correctly) from the 1080i format. I have no idea where the random jitter comes from.

d) Just for completeness, a similar discontinuity in the pic_order_cnt_lsb happens in the last ‘group of pictures’ (lines 912 to 915 in the right file).

e) All remaining ‘group of pictures’ are fine and also the slice contents matches with the input file. Just for curiosity, notice that the PTS are identical, just with an offset of exactly 1 clock tick.

I can’t positively say that these points are causing the playback problems, but they seem at least strange to me. I hope it helps. I’m sure you have better insight in the Smart Cutter operations, and I hope you can help to fix the playback issues.

Best regards,
rrabit

Hi,

I've the same issue.
I created posting:
http://www.fame-ring.com/forum/viewtopic.php?f=7&t=7378

Regards

helmar