AviDeMux only handles first 3h of a 16h TS file

[beta-tester]

i created a "synthetic" TS file of 16h duration by using ffmpeg.
it's compressed size is only 16MB and unzipped it is 1GB.
so i can upload it easely and it does not contain potentially copyright protected content.

https://www.file-upload.net/download-14071227/out-test-files.7z.html

created with (contains only video data):

Code Select Expand

ffmpeg -framerate 50 -loop 1 -i ~/Pictures/test_1280x720.jpg  -t:v 57600 -vf scale=1280:720 -r 50 -pix_fmt yuv420p -c:v libx264 out.ts

created with (contains video and audio data):

Code Select Expand

ffmpeg -framerate 50 -loop 1 -i ~/Pictures/test_1280x720.jpg -stream_loop -1 -i ~/Music/test_1kHz_30s.wav -t:v 57600 -vf scale=1280:720 -r 50 -pix_fmt yuv420p -c:a mp2 -b:a 256k -ar 48000 -c:v libx264 out2.ts

it shows up the same issue, under linux and windows.

i did not tried your new patch yet, but i will try it in a moment.

[beta-tester]

ok, i tried your second patch...

it opends the real TS file and the synthetic one without problems. i can see the whole 16h of video and i can move the slider to any position. that is nice.

BUT playback the TS file in ADM is problematic.
i can play back both TS files from position 00:00:00.000.
but i can't play back the real TS file from position above 14:00:00.000 ... then ADM gets stuck (not responding) and produces in the background many many MBytes of endless log output.

Code Select Expand

...
[Composer::getPCMPacket] Track 0, 0x55b4d09c2030 : drift -1530441629, computed : 13:57:33,660 got 00:04:04,494
[Composer::getPCMPacket] Track 0:55b4d09c2030 : Dropping packet 50253660 last =244494
...


i had to cut the log file from about 500MB down to 1MB so send it here.
see attachment.

but the strange thing is, that the synthetic TS file out.ts can be played back from any position. but that file does not contain any audio stream.
and the message "[Composer::getPCMPacket] ..." looks like an audio stream issue here.

i have to generate a synthetic out.ts file with an audio stream first to see if the issue can be reproduced with a synthetic TS file as well.
but rendering a TS file with ffmpeg will take on my PC about 7h without audio...

[eumagga0x2a]

Thank you very much, there must be a similar wrap problem in the generation of audio seek points, not tackled by the patch yet. Will look into it very soon.

[eumagga0x2a]

Could you please test whether the attached patch helps with audio timestamps wrapping around?

To discard changes from this patch, you can use

Code Select Expand

git checkout avidemux_plugins/ADM_demuxers/MpegTS/ADM_ts.h avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsAudio.cpp

[beta-tester]

YES, that looks great now... thank you very much!!!

i tried to copy video and audio to a mkv file successfully from around 13:xx:xx.xxx to around 14:xx:xx.xxx.
i am currently try to convert video and audio, but that will take a longer while...

here the log of the current process...
(including log of the copy to mkv, a convert to x265/aac i canceled and convert to mpeg2/mp3 that is still on progress)

[eumagga0x2a]

Glad to hear that the patch fixes the issue. If you have sufficient storage space, could you please test whether it still works with a video twice as long (i.e. longer than 27 hours)? The steps would be as following:

1. load the recorded stream in Avidemux
2. append it to itself
3. save in copy mode as MPEG-TS
4. load the result

Then please test whether seeking and starting playback works all the way to the end of the entire video. Thanks!

[beta-tester]

you made a great job...
all tests passed.

• appending 16h + 16h TS to 32h TS file - ok
• seeking with all possible knobs (frame by frame, I-frame by i-frame, seek wheel, ...)- ok
• play the video in ADM from several positions (0h, ~14h, ~17h, ~29h, ...)- ok
• saving the 32h TS file - ok
• deleting portions from the whole the 32h video - ok (a message popped up - see screenshot)
• reopening the saved 32h TS file - ok
• seeking with all possible knows (frame by frame, I-frame by i-frame, seek wheel, ...)- ok
• play the video in ADM from several positions (0h, ~14h, ~17h, ~29h, ...)- ok
• play the video in ADM from the transition part (16:01h, 16:06h)- ok
• saving a part from the transition from one 16h video to the appended 16h video of the 32h TS file - ok

EDIT: stupid me. forget the screenshot, i forgot to align the a- and b- markers to an i-frame

[eumagga0x2a]

Great, thank you very much for your help. The fix wouldn't be possible without it. I'll commit and push the changes once I've finished my current work on editor.

[beta-tester]

can i delete all my huge test files now or shall i keep them for a while...
better i ask you, befor i do silly things again 

[eumagga0x2a]

You would do me a great favor if you keep the 16 hours long recording for future testing (the double duration sample can be easily recreated if necessary). At least until a month or two past the 2.7.6 release, please.

[beta-tester]

is this TS file (see attached log) more interesting to you than the previous one?
if so, i would delete the previous TS file and keep the current one.
i have to delete one of the two big TS files, i need the disk space.

[eumagga0x2a]

Is the indicated duration of 17:49:54,673 correct (I assume your Avidemux build is patched as otherwise it would be too old to handle it)? If yes, please keep the previous recording if somehow possible because its duration exceeds ~27 hours, i.e. it allowed to verify correct handling of the second "a uint32_t would now wrap around" event, not just the first one.

By the way, why haven't you updated to the current git master? There is some new stuff there in dire need for real-world testing including but not limited to an updated internal FFmpeg.

[beta-tester]

yes, the length of the TS file is 17:49...
but the previous TS file was 16h... only the "doubled appended" TS file was twice as long.

why i didn't updated my current git master?... because i am too lasy... i didn't wanted to apply the patches and recompile everything again...

EDIT: i thought i have to apply the patches... now i see i don't.

[eumagga0x2a]

only the "doubled appended" TS file was twice as long.

And it is now gone? In this case it is up to you which one to keep.

i didn't wanted to apply the patches and recompile everything again...

The fix for MPEG-TS timestamps wrapping around was committed and pushed to git master three weeks ago, all official nightly builds uploaded after that date should handle MPEG-TS streams longer than 13 hrs 16 min just fine.

Please note to pull from the git master successfully you would need to reset the files modified by the patch as explained in https://avidemux.org/smif/index.php/topic,19110.msg88908.html#msg88908 first.

[beta-tester]

only the "doubled appended" TS file was twice as long.

And it is now gone? In this case it is up to you which one to keep.

i thought i am able to re-create the twice as long file when necessary - and will do, when you ask for.

i recompiled avidemux...
but i think i will use the precompiled nightly builds netx time,
i didn't realized before, that the changes were committed by you for the "wrap" issue.
(i feel i get more and more stupid the longer i can't go to the office to work  )

thank you.