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

Thank you for posting the new samples and sorry for the delay in responding. I have been trying out some new versions of codecs on your samples.

I may not have been clear in my earlier post, but only certain software codec/player combinations stutter during the playback. My hardware player (which I think uses a Broadcom 7400 chip) plays back the cut video perfectly.

I am also pleased to report that using recent versions of Haali Media splitter (v1.11.96.14) to demux the transport stream and ffdshow tryouts (rev3711) to decode the H.264 results in no stutter.

But using the DivX decoder (v1.2.1, build 9.0.1.21) in place of ffdshow tryouts does cause stutter. You can see it most noticably at the end of the wav.new.ts clip.

All these tests are on 32-bit Windows 7 Home Premium SP1.

Another codec which doesn't work is DiAVC. This codec doesn't stutter - even worse, it outputs blocking artifacts starting at the first I-frame of the 2nd GOP and continuing until the next I-frame. I will report this to the author of DiAVC and maybe he can shed some light on what is causing his decoder to get confused.

Regards,
Wavelet

IS HAVE THE NEW THAN 1.38 VER IS OUT?

I have an update to my previous post. I contacted the author of DiAVC and he thinks his codec produces blocking artifacts because the H.264 bitstream in wav.new.ts is corrupt. He pointed out that the bitstream does not parse successfully when decoded using the reference "JM" decoder (the one published by the committee which wrote the H.264 standard). Since this reference software is available for free (http://iphome.hhi.de/suehring/tml/) I decided to downloaded and run it on the bitstream myself.

The decoder does indeed fail to decode the bitstream. It complains that an SEI message just after frame 14 has the wrong length.

In the original uncut video (test1.ts in the ftp 'wavelet' directory, which *does* decode successfully in the JM decoder), there are 19-byte SEI messages every frame (containing message types 0,1,4) and then, towards the end of every GOP, a 22-byte SEI message containing message types 0,1,6,4.

In the cut video (wav.new.ts) which you provided, there are 6-byte SEI messages every frame (containing message type 1) in the first (re-encoded) GOP until frame 14 when there is the SEI message containing types 1,2,6,4. This message should be 22 bytes, but the decoder thinks the message is 172 bytes long. When it sees the stop bit in the SEI message after 22 bytes, it aborts with an error message.

So the SEI message contents appears to be correct, but the length (which the decoder will be determining by the distance between NAL unit delimiters) is wrong. I suppose there is also the question of whether the SEI message should really be there at all because we are still in the first (re-encoded) GOP.

Anyway, I have uploaded to the ftp server a couple of log files showing NAL and SEI trace information up to the point where the decoder crashes.

I would recommend you use the JM decoder as a QA test of the output of SmartCutter. It would be a good way to ensure compliance with the H.264 standard and hopefully maximum compatibility with all the different players, camcorders, etc. that people are using.

Regards,
wavelet.

Here is a screenshot of the H.264 elementary stream with the "wrong length" SEI message highlighed. You can see there is a load of garbage bytes just after the message.
(Full-sized image at http://img196.imagevenue.com/img.php?im ... _351lo.jpg)

wavelet