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

Please refer to the files uploaded to subdirectory 'wavelet' on the FTP server.

File test1.ts is the original transport stream.
File test1cut.ts is the output after attempting to cut from frames #16 to #496 inclusive (where the first frame is frame #0).

There are 2 bugs in the output.

Bug 1. 17 frames have been duplicated near the beginning of the output file. The beginning of the output file consists of the following:-
- a re-encoded GOP containing 24 frames (frames 16 through 39 of the original file)
- a re-encoded GOP containing 17 frames (frames 40 through 56 of the original file)
- a duplicate GOP containing 17 frames (frames 40 through 56 of the original file). The duplicate GOP appears not be re-encoded because its frames have pic_struct set to 3, the same as the original file. (pic_struct in the re-encoded GOPs is 0.)

Bug 2. The final 3 frames in the output file (part of a re-encoded GOP of 7 frames) have blocking artifacts (see file test1artifacts.png for an example).

This example may appear a bit unusual in that the video is interlaced (and it is quite shocking how many established H.264/AVC video tools out there don't handle interlaced video) and the GOPs do not always start with an I frame. Nevertheless, I would say it's a fairly standard example of a DVB transport stream.

Any update on this? Have you been able to reproduce the issue with the files I sent? Do you need any other info?

Thanks.

wavelet wrote:Any update on this? Have you been able to reproduce the issue with the files I sent? Do you need any other info?
Thanks.

Dear wavelet:
Sorry for the latency.
We did re-produce the problem. And we do have a clue about this problem. Our developers are trying to make a solution for this.
We will keep you posted about the progress.

Please feel free to send us your further advice and suggestion.
Thank you very much.

Best Regards,
FameRing Support Team

Dear wavelet:
Sorry for the latency.

We think we have solved the problem.
You may please try the new version(1.3.7) on your end
http://www.fame-ring.com/smart.cutter.rar

Please feel free to send us your further advice and suggestion.
Thank you very much.

Best Regards,
FameRing Support Team

Thank you. I have tested the new release on 2 examples which previously failed and they both now work. Excellent!

One feature I would love to see added to a future release some time would be this:
Ensure that re-encoded frames at cut points are encoded with the same pic_struct as the originals. At the moment, the re-encoded frames have pic_struct=0. If the original material has a different pic_struct, then at cut-points, the changing values of pic_struct between the re-encoded frames and non-re-encoded frames causes some software players to stutter during playback of the video.

Regards,
wavelet

Actually, on further investigation, I'm not sure if the stuttering is caused by the difference in pic_struct. It might also be caused by a discontinuity in the value of picture order count between the re-encoded and original frames. So another feature request would be - In the re-encoded frames, align their picture order count values so that they seemlessly fit with the untouched frames.

Regards,
wavelet

Dear wavelet:
Thanks for your message.

Please help us to identiry this problem:

output of version 1.3.7
http://www.fame-ring.com/samples/admin/wav.new.ts
fixed for pic order count
http://www.fame-ring.com/samples/admin/wav.fix.ts

Please playback the two files on your end, see whether they behave differently.

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

Best Regards,
FameRing Support Team

Well, first thing to say is that using version 1.3.8 (i.e. fixing the pic_struct values) does not stop the stuttering. But nevertheless I'm very pleased to see pic_struct fixed.

Thanks for making these samples available. I'm pretty sure they both stutter, but it's a little difficult to tell because my eye gets distracted by the watermark flashing off.

Looking at the POC values, both samples still have a discontinuity.

In wav.new.ts, we have:
First GOP has POC=0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30
Second GOP has POC=-48,-46,-44,-42,-40,-38,-36,-34,-32,-30,-28,-26,-24,-22,-20,-18,-16

In wav.fix.ts, we have:
First GOP has POC=0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30
Second GOP has POC=0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32

So in both cases there is a discontinuity between the last frame of the first GOP and the first frame of the second GOP.

To eliminate the discontinuity, you would need to either:
Make the re-encoded (i.e. first) GOP have POC values -80,-78,-76,-74,-72,-70,-68,-66,-64,-62,-60,-58,-56,-54,-52,-50 so that it lines up with the second GOP;
or if you want to have the first GOP start from 0, renumber frames in subsequent GOPs from 32 onwards.

I would have thought that the first option involved less work and was more in line with the philosophy of leaving as much of the video as possible untouched.

Regards,
Wavelet

Dear wavelet:
Thanks for your detailed analysis.

The previous samples are from version 1.3.7, now we have version 1.3.8
http://www.fame-ring.com/smart.cutter.rar

for a better view, we removed the watermark from the two samples

new output of version 1.3.8
http://www.fame-ring.com/samples/admin/wav.new.ts
fixed for pic order count
http://www.fame-ring.com/samples/admin/wav.fix.ts

Please playback the two files on your end, see whether they behave differently.

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

Best Regards,
FameRing Support Team

admin ,can you test my sample , the 12.ts is cut by 1.3.8 ,
but look like is not dxva compile and ffdshow rev 3760 have blocking and frame loop back..
loop back and dxva full green screen is after the watermark
so the bug in the encode part end and the no edit source start?