Open abakum opened 4 years ago
Does the same behaviour occur with any TS file? Can you reproduce with the files from https://4kmedia.org/ or https://peach.blender.org/download/ ?
I came across this on files from AVCHD camcorder. In order not to upload these pivate videos, I reproduced their structure via ffmpeg. I think for any file you can choose such timings in SRT that an bug occurs. You managed to reproduce an bug with the files made by a.bat or a.sh?
It seemed like a good idea to create test files rather than download them.
I download http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4
from
http://distribution.bbb3d.renderfarming.net/video/mp4/
to https://yadi.sk/d/td0NxxaLQQcy5Q
and add to a.bat and a.sh command:
tsmuxer bbb_duration_6_instead_of_10.meta bbb_duration_6_instead_of_10.ts
where bbb_duration_6_instead_of_10.meta:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --vbr --cut-start=5000ms --cut-end=15000ms --vbv-len=500
V_MPEG4/ISO/AVC, "bbb_sunflower_1080p_30fps_normal.mp4", contSPS, track=1, lang=und
#A_MP3, "bbb_sunflower_1080p_30fps_normal.mp4", track=2, lang=und
A_AC3, "bbb_sunflower_1080p_30fps_normal.mp4", track=3, lang=und
S_TEXT/UTF8, "duration_6_instead_of_10.srt", timeshift=5000ms,font-name="Impact",font-size=65,font-color=0xffffffff,bottom-offset=24,font-border=5,text-align=center,fadein-time=0.1,fadeout-time=0.1,video-width=1920,video-height=1080,fps=30
and duration_6_instead_of_10.srt:
1
00:00:03,000 --> 00:00:06,000
1
00:00:03,000 --> 00:00:06,000
result bbb_duration_6_instead_of_10.ts should have been 10 seconds but due to an bug it is only 6 seconds
Sometimes using timeshift=Xms for the SRT file and --cut-start=Xms --cut-end=Yms leads to the fact that the duration of the result is reduced to the duration of the SRT file Download https://yadi.sk/d/td0NxxaLQQcy5Q run a.bat or a.sh and see duration_6_instead_of_10.ts If you do not use SRT, the duration of the result is correct: not_srt-not_bug.ts If you do not use timeshift=Xms for SRT, the duration of the result is correct: not_timeshift-not_bug.ts If you successfully select the time in SRT, the duration of the result is correct: lucky_srt-not_bug.ts Even if you successfully pick up the time of the first subtitle in SRT, the second can ruin everything: lucky_srt-duration_9_instead_of_10.ts If you do not use --cut-start=Xms --cut-end=Yms then even using timeshift=Xms everything is fine: not_cut-not_bug.ts