Can I save this edited file some way in v2.7.5?

[fish]

I have just started using ADM 2.7.5 early this week and encountered, 'The saved video is incomplete' because of invalid timestamps. This was while editing a DVB HD file which I know give problems (not only in  ADM I have found). This is a real problem, because instead of getting a flawed file, which in the past I have compensated for by leaving one I-Frame handles at each edit, I now get next to no file saved. I tried opening the saved project script in v2.7.3 but it won't open in v2.7.3.  So a file that should save as 14 minutes, possibly with artifacts for which I have compensated, now saves as a 2 second file, with no option of saving it.
I can't see how this is a good development, i.e. saving a full edit (which may have problems) v saving next to nothing, with no option to save the file despite possible problems. The result of this change is,  I can now only have a 2 second file or nothing. It would be much better to have a option of saving the 14 minute file, with flaws, than being forced to make do with a 2 second file.

[eumagga0x2a]

Do you refer to the latest nightly? Please provide a sample.

If you save to MP4, try setting clock frequency to 90kHz.

[fish]

It might be the latest nightly it's 191222_...4.2.1-vc++. I can redo the edits using v2.7.3 but I just thought I would comment as it seems like a backward step to get next to no file saved, as opposed to a full but flawed file.

[eumagga0x2a]

Please provide information which might help to fix the regression (if 2.7.3 works where the nightly fails).

[eumagga0x2a]

Builds from 2019-12-19 on contain massive changes to the way Avidemux handles fps and timebase, fixing issues like perfectly regular constant fps mp4 files becoming variable frame rate mp4. The changes affect all ffmpeg-based muxers, i.e. mp4, mkv, mpegts, mpegps and webm. The latest nightly from 2020-01-01 is mingw-only, but the changes there affect mostly the flv demuxer.

[eumagga0x2a]

It looks like I haven't committed and pushed updates to the MpegTS, MpegPS and MKV to the repository, they exist only in my local tree. This might be responsible for the failure. Please specify which format you were saving to.

[fish]

I have noticed that v2.7.5, when editing DVB HD files, which have always given problems, such as artifacts and freezes around the edit points, now refuse to save but instead give a warning. It seems to me that saving the full edited video, with problems, would be preferable to saving just the section up to the first problematic edit.
My work round was to save the file in four parts cutting round the problematic frames and then saving that using append.

[fish]

I was saving to .mp4  and the files were originally .ts. No worries, you guys to a fantastic job.

[eumagga0x2a]

Okay, please set clock frequency in the MP4 muxer settings to 90kHz then.

edit: as the input is TS, this means that the problem is with the MpegTS demuxer. There are some uncommitted changes as well, will check... In any case, please delete *.idx2 files to force re-indexing.

[fish]

I'll give that a try in my next edit.

[eumagga0x2a]

Do you still have the source .ts from the last video editing session, which would allow to reproduce the issue?

[fish]

It's already deleted but any DVB HD broadcast file should be good for testing.
I remember a post by someone a year or two ago and the poster had a way of analysing the GOP structure of DVB HD files before and after editing. It showed the frame structure around the edit was getting damaged quite often. ADM isn't the only editor that has trouble reading these files, quite a few won't look at them and others get frames mixed up.

[eumagga0x2a]

That is a pity as not any DVB HD broadcast will do.

Avidemux knows since last summer which B-frames in H.264 streams it may drop and which not, thus no damaged GOPs should occur. The issue you encountered this time is however a completely different one. The timebase provided to the libavformat-based muxer doesn't match the real timestamps.

[eumagga0x2a]

No problems saving a ~1h long freshly recorded DVB HD transport stream with quite a few transmission errors to mp4 so far, please provide a sample once you get hold of a suitable one.

[fish]

That's very strange but from what you describe you don't appear to have removed any sections in the video. The problem does not arise if you simply take a whole DVB-T  HD file and save it in a mp4 container, the problem arises around edits. Try taking 10 mins of the video and remove 5 - 10, 5 second sections.
This has been a long running problem caused by this type of file, see the post 'Broken frames due to H.264 Open-GOP (DVB MPEG-TS)' which describes it very well. What the poster describes concurs exactly with what I see. The problem is with this type of file, I haven't seen it with any other. The only difference with the latest ADM is that the whole file no longer saves, the file only save to the first messed up frames.