How to correctly cut and merge two h264 .ts streams

[geohei]

Hi.

I have two h264 streams (DVB-S2 recordings), which I merge using the Joiner. Same movie but recorded (from same channel) at different times! Audio tracks are identical. Both streams are partially corrupt due to heavy rainfall both times.

Stream 1 : I take the first part until 01:00:00.
Stream 2 : I take from 01:00:00 (approximately - same scene change) until the end.

Problem: At the cut frame (which is a scene change, not necessarily an I-frame) I get garbage for 1 second when playing. But this only on some payers, not all. My belief was, that the Intelligent saving does smart rendering, meaning that the cut is re-encoded if required. In my situation, I think that was the case, but VRD didn't re-encode as garbage suggests.

What is the correct procedure to cut at any frame 2 recordings using smart rendering at the cut?

Thanks,

 

[Winnewup]

Hello,
if there are these problems when joining, I have had good experiences with cutting the individual pieces not on I-frames, but on B-frames. Usually a matching point in both sources can be found. Then VRD will definitely perform a recoding on the cutpoint and the transition is then usually okay, even in VLC player, which is probably the most likely to cause problems. If that doesn't help either, the individual cuts can first be saved separately and then joined using the joiner. The reason for the sometimes clumsy cut is probably due to the fact that VRD often does not perform a recode on I-frames, which are usually good for cutting. Unfortunately, with TS-streams (satellite broadcast) there are sometimes also I-frames, which are related to previous frames, which are omitted in a cut without recode. Then some players react unexpectedly, from pixelation to hanging for a few seconds. Sometimes it can be helpfull to make a second round and cut out the first frame after the cut in the finished video, if the problem persists.
TS streams are probably very complex and therefore cannot be handled without errors perfectly, if you want to have smart edit. Overall, VRD solves it very well and the few problematic cases can usually be solved with the workaround described above.

Regards
Frank

 

[geohei]

Thanks for your reply.
Very interesting.

But this all sounds a bit like fishing in the dark. If this works, fine, otherwise try something else. The point is that you don't know 100% sure if something "worked", since only visual checking is possible. Is there any kind of log at the end of the processing, which tells in detail what VRD did?

After quite some testing, I noticed that VRD recodes when cuts are at B- or P-frames, not I-frames (so that confirms what you said - don't cut at I-frames). However I wonder why VRD doesn't simply recode any cut, since errors seem to be unavoidable if no recode occurs?

Also, why do you say I should cut at B-frames and not P-frames?

Thanks,

 

[Winnewup]

Hello,

it is shown live at the process what VRD does. At the end of the process you can have a look into the logfile too.
Fishing in the dark ... sounds funny ... I don't think it's that bad because it doesn't happen that often.
If you have problems joining ts-files, you should be sure that VRD does a recode at both sides of the joining point. This only happens with certainty with B-frames, while with P-frames at the end there is usually no cut.
Since ts-streams are a bit stubborn in rare cases, it would certainly be an interesting idea to also store a recode of I-frames by default and only cut on IDR frames without recode. Presumably this will not be done, since in the vast majority of cases everything works fine and an I-frame does not have references to previous frames that often.
But that's a question for the developers.



Regards
Frank

 

[geohei]

Understood.
Thanks again!
And again ... very interesting!

I need some extensive testing now (which will take time). But at least, I know a bit more how VDR ticks and what can/should be done/avoided.

Regards,