Cannot cut at desired I-frames

Begonnen von gabortel, Oktober 27, 2020, 10:10:50

« vorheriges - nächstes »

gabortel

I know, that a clean cut of H264 TS streams is possible at I-frames only. I have an observation, that DVB-T broadcast ts streams always have an I-frame at the start and at the end of a programme (when they change video source). This helps to make a nice cut, free of preceeding and following channel signal clips; I just select these I-frames as cutin and cutout frames. Then I expect the resulting cut and fixed ts file to start and end precisely at these I-frames.

However, I found that TS-Doctor often saves a fixed ts file that is an I-frame (~1sec) behind the cutin and cutout I-frames that had been set in the cut preview window.
(This problem might be related to the forum post by john1969, on January 31, 2020, 16:09:26 "Problem with cutting scenes", that was not further investigated...)

As an example, I attach the screenshots of the preview window at cutin and cutout frames. By playing the cut and fixed ts file, it is about 1sec late, more precisely an I-frame behind the set points, both at the cutin and cutout. I know this by checking the I-frames of the saved ts file with ffmpeg command: 'ffmpeg -i "filename_fixed.ts" -vf "select=eq(pict_type\,I)" -vsync vfr frm%%05d.jpg' The first and last extracted I-frames are 1 I-frame behind the set ones.
(see these in the attached zip folder: cutpoints_set_as_desired_result_is_one_iframe_late)

OK, I was experimenting more. (Sometimes this trick helps, but not always.) Opening the same input file again and setting the cut points intentionally one I-frame earlier than desired, I expect a correct cut, but now I get the cuts exactly at the set I-frames. So these are now really one I-frame earlier than desired, i.e. two I-frames earlier than I got in the first case.
(see these in the attached zip folder: cutpoints_set_one_iframe_early_result_is_one_iframe_early)

So, in conclusion, I cannot get a fixed file that is reliably cut in and out at the desired I-frames. The problem is randomly present with my recordings, sometimes the cuts are exact, sometimes the -1 I-frame offset trick helps, but sometimes even with this trick I cannot get a proper cut (as in the shown example). Might be that the actual cutting procedure uses a different way of determining the cut point I-frames than it was used in the preview window and their results can be off with an I-frame? What is the solution?

Additional info: The input file was recorded using NextPVR with a DVB-T dongle. It has no errors, nor warnings with the check only function. I am trying TSDoctor 3.0.26. My settings for preview and for correction behaviour are at default. I run Windows 10 64bit 2004 version. My video card is a recent NVidia with latest driver. My splitter and filters are on automatic selection. I have LAVLight installed.

Please help me with a relevant setting that perhaps solves this problem, or please check whether it is a bug in TS Doctor. I am attaching a zip of screenshots and extracted I-frames, the logs, the tsb batch files with cut points, all, but the the large input ts file (~2.8GB). If you provide a way, I can upload that too, for analysis.

Cypheros

Hi, could you offer a short sample? You could use the TS RawCutter under tools to cut a 100 - 200 MByte file from the beginning of the recording.

gabortel

I made a 100MB raw cut of the original file, then made a regular cut and fix procedure with a much shorter example (cutin at the black frame before the rising sun, cutout at the flowers, before the BBC logo appears). This cut also suffers from the one I-frame late problem.
I also found a way to send the zipped files (rawcutsample.zip) via wetransfer.com. Here is the link (for 7 days): https://we.tl/t-4C2MzP6nZO
Thank you for dealing with the problem.

Cypheros


jaydear

I've been using TSD since v1 and this issue which is also affected in various negative ways depending on the source channel's transport stream attributes is a major issue for me. A successful way around it is to cut the whole program out in one chunk in TSD to get a program list, subtitle files and do repairs, then edit it in other software that can do frame accurate edits whilst fixing the frame sequences at the joins. That is made possible because the other software vendor includes the necessary commercial codecs. I would be interested to know how much more TSD would cost if the frame-accurate editing was made possible and the same codecs were included because having to edit everything twice to get a smooth result and preserve sub-titles is too time-consuming.
The.Doctor is the ants' pants :)

Cypheros

For TV broadcasting today, many different codecs (mp4, h.264, h.265, eac3, aac, aac-le, aac-he) are used and for each codec a license agreement would have to be concluded with the respective license holders or their representatives. An organizational and financial nightmare that only the big players can handle.

jaydear

I only see mpeg2 for SD and h.264 for HD here, but I get your point. It would be brilliant if you could make it possible to replace the Cutting section of TSD with say, VideoReDo TV Suite. It would be similar to the way that e.g. Affinity Photo, etc. use other photo software such as Luminar and CameraBag as plugins and then jump back into TSD to deal with things such as program guides, chapter marks and subtitles that it does so well and VRD doesn't do. The need for you to buy codec licenses would be gone. The user would need to have a valid license for VRD of course. The capabilities of both programs complement each other very well, but there is a chasm between them with a bridge made of string at present.
The.Doctor is the ants' pants :)

Cypheros

The problem is that the whole thing is a lawful swamp in which you can quickly sink. Most companies try to hide their true identety, like VideoRedo to circumvent the legal risks. In Europe this kind of buissness is impossible. Every buisness is controlled by the goverment 99.99%.
Only the big players can cheat the system.

jaydear

The.Doctor is the ants' pants :)

gabortel

Dear Cypheros,
Any conclusion on the original problem and the posted sample?
Thanks, gabortel

Cypheros

Sorry, can't see a reason why the cut is 1 iframe shifted. It needs deeper analysis of the packet timing. Have no solution yet.
The recording has very few iframes and the distance between iframes is 66 frames or more, what is unusually. At 25 fps, there is a iframes every 2.5 seconds. Is it a sat, cable or an ip recording?

gabortel

#11
Thank you for working on the problem.
The recording is from a free-to-air television channel broadcast on the hungarian DVB-T.
It was made using a DVB-T USB stick and the NextPVR recording software.

gabortel

I had a chance to test TS-Doctor version 2.2.24 with the original "problematic" samples. It does create precise cuts at the required I-frames! Regardless of the "unusually" long time between I-frames.
However, the described cutting problem is still unsolved in the recent versions 3.1.x.

If an older version of TS-Doctor creates correct cuts, that suggests some change in the newer version was not properly justified.
For further investigation I again uploaded the 100MB sample: https://we.tl/t-HuA966YRpC (valid for 7 days)


www.cypheros.de