H.264 TS -> MKV, AviSynth+DGAVCDecode+ffmpeg, trim recording + delay audio?

[Matchay]

Hi!
I have a few recordings from Hauppauge HD PVR where audio is delayed a little. These are .TS files with AVC H.264 content (1080i) and AC3 stereo stream. I would like to convert them to 720p, trimming them and correcting the audio delay by the way. The point is, trimming should be frame-accurate, and audio stream should be delayed, but copied, not re-encoded.

My approach was as follows:

AviSynth script, serving video only (to be able to cut frame accurately with ffmpeg) --> ffmpeg with two input streams, video from .avs and audio from original .ts

a.AVS:
AVCSource("a.dga").AssumeTff().Yadif().LanczosResi ze(1280,720,3)

recode.bat (two-pass encoding):
ffmpeg.exe -ss 00:00:04.500 -t 00:57:03.000 -i "a.avs" -threads 0 -codec:v libx264 -b:v 4000k -vpre libx264-fast-pass1 -pass 1 -passlogfile "a.log" -an -f rawvideo -y NUL

ffmpeg.exe -ss 00:00:04.500 -t 00:57:03.000 -i "a.avs" -threads 0 -codec:v libx264 -b:v 4000k -vpre libx264-hq-pass2 -ss 00:00:04.500 -t 00:57:03.000 -itsoffset 0.390 -i "a.ts" -codec:a copy -pass 2 -passlogfile "a.log" -y "a.mkv"


The thing is, the MKV generated like this, opens a very long time. Once opened, it plays fine, it's cut exactly where I wanted to and audio is copied and in sync. At first I thought it's about issues with filters/codecs chain, but it isn't: other MKV files with similar content (h.264 + ac3 audio) open instantly. I used MatroskaDiagnostic tool and the only difference I can see between other files and mine is surprisingly long time until Haali Media Splitter opens:

00:00.000 Rendering file: T:\Films\a.mkv
00:00.000 Creating Filter Graph Manager instance: OK
00:00.000 Creating Filter Mapper instance: OK
00:00.016 Adding graph to ROT: OK
01:15.817 Added source filter: Haali Media Splitter {55DA30FC-F16B-49FC-BAA5-AE59FC65F82D}
01:15.817 Rendering output pin: T:\Films\a.mkv(Video)
[...]

After some experiments (I created various files, trimming it more and more) I realized the longer the clip is, the longer it takes to open the file.

When I remove the audio track (copy the video stream only to another .mkv via ffmpeg) it opens instantly.
There is definitely something wrong with the way I want to copy, trim and delay audio.

Do you have any ideas or hints?

Cheers,
Maciej

[Selur]

did you try to remux the file with mkvmerge and see if the problem persists? (this way you would know if it's a problem with the mkv muxing ffmpeg does)

[Matchay]

Thanks for the hint. I suspected the ffmpeg muxing yesterday already, because I noticed (using procmon) that the ENTIRE content of the file (2GB) is being read at opening. When opening any other good MKV, only first 64K were being read.

After remuxing, all plays fine and the file opens instantly. I see differences between the original and remixed mkv using "mkvinfo"; there's possibly something wrong with audio timestamps (due to delaying) and header stripping, but I am not an expert on it.

[...]
(MKVInfo) |+ Cluster at 613
(MKVInfo) | + Cluster timecode: 0.000s at 625
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-37) at 628
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-34) at 2171
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-31) at 3714
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-27) at 5257
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-24) at 6800
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-21) at 8343
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-18) at 9886
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-15) at 11429
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-11) at 12972
(MKVInfo) | + Frame with size 1536
(MKVInfo) |+ Cluster at 14515
(MKVInfo) | + Cluster timecode: 0.000s at 14527
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-86) at 14530
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000) at 16073
(MKVInfo) | + Frame with size 19720
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-54) at 35801
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (track number 1, 1 frame(s), timecode 0.160s = 00:00:00.160) at 37344
(MKVInfo) | + Frame with size 4019
(MKVInfo) | + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = 00:00:00.-22) at 41370
(MKVInfo) | + Frame with size 1536
(MKVInfo) | + SimpleBlock (track number 1, 1 frame(s), timecode 0.080s = 00:00:00.080) at 42913
[...]

Anyway, an improved approach would be to extract audio (dgavcindex can do it during indexing), then re-encode video only with the ffmpeg or x264, and afterwards remux the reencoded video track with the original audio track (introducing a proper audio delay). The whole point is I don't want to reencode the audio track, as it would be a third lossy reencoding in the chain (I guess there are already those done (at least...): original->SAT broadcast, SAT settop-box->Hauppauge HD PVR))

Regards,
Maciej

[Matchay]

FYI: putting -itsoffset in front of video stream did the trick. It seems it's better to delay video than to speed up audio. Now the container is muxed correctly. Must be a bug in ffmpeg.

Maciej