Selur's Little Message Board

1. Wrong delay relative to video
I'm doing remux from *.ts container to m2ts with normalize and convert audio to LPCM.
Audio in the source file has delay relative to video [-80 ms]
Audio in the destination file has delay relative to video [-2 s 360 ms] - A-V resync
source file

destination file

2. After the crash of the current job, the Hybrid stops the next jobs, when I have checked "Ignore crashed jobs and process next".

MediaInfo reported -80ms delay of the audio relativ to the video and Hybrid told tsMuxeR to use that value:

Code:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --vbr --vbv-len=500

V_MPEG4/ISO/AVC, "C:\Windows\Temp\1_21_02_47_9010_04.264", fps=25, insertSEI, contSPS, ar=1:1 (Square)

A_LPCM, "C:\Windows\Temp\iId_73_aid_307_lang_en_DELAY_-80ms_21_02_47_9010_02.wav", timeshift=-80ms, lang=eng

Looking at the output of ffmpeg there are tons of problems reported about the decoding time stamps (DTS) of the source.
Seems like there is something wrong with the source. My guess is the extraction/decoding of the video caused the demuxer/decoder to drop some frame or some time codes are to messed up to guess them.
-> Hybrid isn't designed to handle broken sources.

About the crash and the processing stopping, according to Hybrid it was still trying to process '21_02_47_9010_07_cleanUp' and the 'parallelJobCount of client' was 1.

Cu Selur

kingcrimsonster

Selur