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

[fish]

Just to add some observations about editing DVB-T HD files,  I am 99% sure the problem isn't caused by ADM. For what I have experienced it is caused by wrongly ordered frames in DVB-T HD files. My heavy weight editor of choice is Avid Media Composer and when the files are linked into MC this shows up the wrongly ordered frames. When the frames are played  forward frame by frame, every 1,2,3 or 4 seconds the playback jumps 2 frames forward, one frame back and then two frames forward, equivalent to a frame order of 1,2,3,4,6,5,7,8,9. This repeats seemingly randomly every few seconds.
These wrongly ordered frames don't show up in any media player I have tried, nor does it show up in playback in ADM. When editing in ADM in copy mode, if your chosen edit points randomly happen to be on these wrongly ordered frames, the saved file have artifacts and/or a frozen section of video around those edit points. If you are lucky and your edit points are not on any wrongly ordered frames the saved file will play as though everything is fine. The wrongly ordered files will still be there but most playback methods will not show them as wrongly ordered.
Another thing I have noticed is, if you are unlucky with your edit points and get frozen video  for  maybe 5 seconds, if the play head is moved back to just after the edit, the video section that freezes will play normally. It is only when the play head passes over the edit point, the video freezes. Another oddity is that video converters re order the frames to the correct positions.

[eumagga0x2a]

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.

Still can't reproduce. Of course, depending on cut positions I get a warning about picture order count (POC) going back, which should be taken seriously for compatibility with ffmpeg-based video players, but apart from that: WFM.

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.

This is all solved for H.264 streams more than half a year ago.

Just to add some observations about editing DVB-T HD files,  I am 99% sure the problem isn't caused by ADM. For what I have experienced it is caused by wrongly ordered frames in DVB-T HD files. My heavy weight editor of choice is Avid Media Composer and when the files are linked into MC this shows up the wrongly ordered frames. When the frames are played  forward frame by frame, every 1,2,3 or 4 seconds the playback jumps 2 frames forward, one frame back and then two frames forward, equivalent to a frame order of 1,2,3,4,6,5,7,8,9. This repeats seemingly randomly every few seconds.

Please provide a sample captured from DVB-T and the said sample edited by Avid Media Composer which allows to reproduce the issue, thanks. I don't encounter the problem you describe when using my equipment, both software- and hardware-wise.

[fish]

Here is an example of what I am seeing and have been seeing for as long as I can remember but simply work round it. There is a difference I have noticed between v2.7.3 and v2.7.5 and that difference can be seen in the size and length of the saved file, one from v2.7.3 and the other from v2.7.5. As you can see, both files freeze at around 10s - 15s but only if the play head passes over the edit point around 10s, the video will play normally if the play head is moved to eg. 11s, this is normal.
What has changed can be seen from the edit around 39s. v2.7.3 saves the whole file before and after the 39s edit but v2.7.5 saved the video only up to that edit the rest is not saved.
I have uploaded a test file along with edit points and the file resulting from both versions. The edit points are sequential, so the position of edit 2 depends on edit 1 having been made and edit 3 on 1 and 2. Here is the link to the files.

https://file.io/kZWXfk

[fish]

I should have also added, that a file edited in Media Composer would be of no help, as all such editors either need to convert files before editing or after editing or both, unless the codec type is native to that editor (they generally use non inter frame codecs). The resultant re encoded files would preserve the original frame order but the file would be re encoded and so defeats the purpose of using ADM. DVB-T HD files also need to be re wrapped from .ts to .mp4 before MC can use them.

[eumagga0x2a]

file.io

404
Page not found

In doubt, please use WeTransfer, Mega, Dropbox or Google Drive – services which are proven working well.

[fish]

OK, it worked a few minutes ago but obviously isn't now I will try another, that was 'File IO' by the way.

[fish]

Try this.

https://file.io/rOiRUZ

[eumagga0x2a]

Same.

[fish]

That also failed, I'll try again with a different one.

[fish]

This one should be ok.

https://drive.google.com/open?id=1h8mWm_un3dXbh1BnsvVFaGoLmE6w1bfd

[eumagga0x2a]

Yes, thanks, got the sample. Will look into it ASAP.

[eumagga0x2a]

I can reproduce the issue with the cut no. 4 from frame 1247 to 1462 (counting from zero) or 00:00:50.713 to 00:00:59.313 without previous cuts, we get identical DTS (DTS collision) out of editor. The video is a mix of fields and frames, this is indeed a blind spot in all the improvements Avidemux received last summer (all samples I can produce myself contain exclusively frames).

Will look into it, thank you for the sample.

[eumagga0x2a]

I can also reproduce that we miss for some reason one occurence of POC going back (the problem only FFmpeg and FFmpeg-based players experience due to a questionable strategy to deal with such irregularities) after a cut and don't issue a warning.

[fish]

The strange thing is the edit you describe,  '00:00:50.713 to 00:00:59.313 without previous cuts', completes without a problem for me, although I can't tell whether you are referring to a saved file or something in the internals of ADM.
I tried playing the sample file in Media Composer and it crashes at around 28-29 seconds. So the file is far from perfect, even though it is a typical DVB-T HD file and the problems don't show up in media players or when playing in ADM. Media Composer's playback engine is often criticised but it does seem discriminating enough to know a good video file from a bad one even though it's not really designed for inter frame codec editing)
I'm pretty sure I have seen this incomplete save with progressive DVB-T HD files as well as the MBAFF type, (movies are all broadcast in progressive), so I will try to get a suitable example.

[eumagga0x2a]

The strange thing is the edit you describe,  '00:00:50.713 to 00:00:59.313 without previous cuts', completes without a problem for me

Same here, I just pointed out the source video frame numbers and timestamps of the last cut.

I tried playing the sample file in Media Composer and it crashes at around 28-29 seconds. So the file is far from perfect

The frame 737, marked as an IDR in the stream, contains an invalid bit sequence where idr_pic_id value should be encoded. This might be the issue which the decoder in Media Composer fails to handle.