Settings set to video and audio COPY but output laggy

[Sora]

I got an original TS file and I want to cut out part of it without encoding, I set both video and audio to COPY mode and tried outputting it to mp4 and ts but in both cases, the video in the output file is kind of choppy, like the frame rate dropped a lot. The video and audio are in sync and the audio track has no problem.
I also tried re-encoding the video as x264 and save the output as mp4, the output has no problem at all. Does this mean I must re-encode the file just for cutting the input? But shouldn't copying video and audio and outputting as TS file(the same file format as the input) work?

Attached are the mediainfo of the input and outputs file.
Someone please help me thanks.

[eumagga0x2a]

I'm sorry, but downloading (at least, text attachments) is currently broken in this forum. Would you please provide the files via Pastebin, WeTransfer, Mega, Dropbox or Google Drive?

[Sora]

I'm sorry, but downloading (at least, text attachments) is currently broken in this forum. Would you please provide the files via Pastebin, WeTransfer, Mega, Dropbox or Google Drive?

Here's the link:
https://drive.google.com/drive/folders/1ulLkiIw7pNECEXJTXd1W7i2JtjyT_9Ym?usp=sharing

There're also several things I noticed.
1) When I tried to open the output file in avidemux again, it shows a warning message "This video contains B-frames, but presentation time stamps (PTS) are either missing or monotonically increasing." This message only popped up for the output files, the original file plays smoothly and avidemux doesn't show this message for it.
2) I tried using different media players (or video decoders) to play the output files.

• For MPC-HC, I use "LAV video decoder" and "Enhanced video renderer (custom presenter)" for both of the output files. This setting leads to the laggy playback. But when I choose the "enable frame time correction" option, the video plays smoothly.
• For potplayer, I'm using the defaults, "AVC1 - Built-in FFmpeg Decoder(h264, Thread Frame)" for the mp4 output. And I use "H264 - Built-in FFmpeg Decoder(h264, Thread Frame)" for the ts output. I use "Enhanced Video Renderer(Custom Present)" for both of them. The output files play smoothly with these settings.

It seems that there're timestamps issues with the output files. Thanks.

[eumagga0x2a]

Could you please verify that the problem with invalid frame timestamps not detected in the source MPEG-TS file but present in the output persists with the latest Avidemux win64 nightly (currently from June 20) and if it does, provide the first ~300 MiB of the source file as a sample, cut with a simple tool similar to head or dd on Linux? (In a way that the cutter doesn't interfere with the content and internal structure of the file, just copies the first N bytes).

I suspect that there is some problem with timing in the source.

[Sora]

Could you please verify that the problem with invalid frame timestamps not detected in the source MPEG-TS file but present in the output persists with the latest Avidemux win64 nightly (currently from June 20) and if it does, provide the first ~300 MiB of the source file as a sample, cut with a simple tool similar to head or dd on Linux? (In a way that the cutter doesn't interfere with the content and internal structure of the file, just copies the first N bytes).

I suspect that there is some problem with timing in the source.

Yes the problem does exists in the latest Avidemux win64 nightly and I don't know if I'm doing this correctly but I just use "Get-Content original.ts -TotalCount 300MB -Encoding byte" in windows powershell to extract the first 300MB but it's taking a really long time because the file is around 7.9GB. Are there any other ways to do this? Thanks.

[eumagga0x2a]

I have no knowledge of PowerShell, but looking at the documentation, your command line seems to be correct.

[Sora]

I have no knowledge of PowerShell, but looking at the documentation, your command line seems to be correct.

I don't know if this is a problem but the first 300MiB of the file is just the same frame contents, there're no movements, do you still want it? Thanks.

[eumagga0x2a]

Please increase the size of the sample to 500 MiB and let me have a look at it.

[Sora]

I figured 500MB is still not enough, the video starts to have motion at around 23 mins so at least around 800MB is needed and Get-content is taking way too long to output the 800MB file. Would it be better if I just send you the whole original file?

[eumagga0x2a]

Something must be really fishy with the source file.

Would it be better if I just send you the whole original file?

If your upstream bandwidth allows uploading 7.9 GiB within a reasonable period of time, then do, please. Please keep in mind that installing a Windows version of coreutils (or MSYS2) and using

Code Select Expand

head -c 500M /path/to/source.ts > /path/to/output.ts
to write the first 500 MiB of source.ts to a new file output.ts may be faster (and you get a proper all-purpose set of tools for later).

[Sora]

Something must be really fishy with the source file.

Would it be better if I just send you the whole original file?

If your upstream bandwidth allows uploading 7.9 GiB within a reasonable period of time, then do, please. Please keep in mind that installing a Windows version of coreutils (or MSYS2) and using

Code Select Expand

head -c 500M /path/to/source.ts > /path/to/output.ts
to write the first 500 MiB of source.ts to a new file output.ts may be faster (and you get a proper all-purpose set of tools for later).

I just sent you the file through PM. Thanks.

[eumagga0x2a]

Thank you for the sample, the issue should be fixed by [editor] Check for insufficient PTS delay when adding a ref video and correct it if necessary.

The video contains B-frames, but presentation timestamps (PTS) are not shifted to ensure that they never precede corresponding decode timestamps (DTS). Avidemux was expecting and checking for pretty all sorts of trouble except for the case when all timestamps in a closed-GOP video were present and valid, but the PTS delay was too low (here: equal zero).

[Sora]

Thank you for the reply. May I ask how do I use the script provided to fix the problem?

And if I understand you correctly, since a frame needs to be decoded first in order for it to be displayed, so DTS for the same frame should always be smaller than or equal to its PTS, right? In this video case, there're DTS that are after the PTS? And I'm guessing the PTS delay is to delay PTS so that they are after the DTS?

[eumagga0x2a]

May I ask how do I use the script provided to fix the problem?

This is not a script but a patch, already submitted to the repository. Next time Avidemux is compiled off the git master, the resulting application will handle such files correctly (as always, the change may have unwanted side effects with some other files with broken timing, but that's life). If you have some experience with Linux and don't want to depend on officially provided binaries, you can build Avidemux for Windows from source yourself which is not too complicated.

And if I understand you correctly, since a frame needs to be decoded first in order for it to be displayed, so DTS for the same frame should always be smaller than or equal to its PTS, right? In this video case, there're DTS that are after the PTS? And I'm guessing the PTS delay is to delay PTS so that they are after the DTS?

Yes, absolutely correct.

[Sora]

Got it, thanks for the help!