Recompressing MKV to AVI and audio delay

[Gusi]

Hi,
I'm writing a directshow application which encodes a DV avi file into MKV+XVID+OGG and then reencodes again into DV avi (this is to send the MKV file through internet)

The file in MKV works fine and I can play it with any media player (WMP9, ZoomPlayer...), with audio syncing perfectly.

But when I recompress into avi (DV codec for video and PCM for audio) the resulting file has always an audio delay of more or less +0.5 seconds. I tried to compress to other video and audio formats (DIVX, MP3...), and the problem seems to be related to the matroska container, because if the intermediate file is compressed in AVI (and using MP3 codec for example) it works perfectly.

I'm using latest matroska pack, DX9.0b, winXP...

Anyone has a clue of whant's happenning? Maybe a matroska splitter bug? But I can't understand why when playing it is working perfectly...

I you need more information or code to check please let me know.

Thanks in advance

[Atamido]

Use MKVInfo to look at the Matroska file. Look at the blocks for the audio track. See what timecode the first audio blocks have. If they have a timecode of around 1 second, then that means that there is a delay in the audio track. Whatever method you are using to convert the streams back to DV may be shifting the track so that the audio starts at zero.

[Gusi]

Thanks a lot for the reply!
I'm going to try it and I'll post the results.

[Gusi]

I've tried with various files, and in some of them the audio delays and in others it anticipates.

This is a sample where the audio plays a little before it should.
Is there something wrong? I can't understand the format of the mkvinfo results.

Thanks in advance.

+ EBML head
+ Segment, size -13
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 3014)
|+ Segment information
| + Timecode scale: 1000000
| + Duration: 985.440s (00:16:25.440)
| + Date: Fri Jun 18 17:59:37 2004 UTC
| + Muxing application: DirectShow Matroska Muxer
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 21238
| + Track type: video
| + MinCache: 1
| + MaxCache: 1
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 40 (FourCC: XVID, 0x44495658)
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Video track
| + Pixel width: 720
| + Pixel height: 576
| + Frame rate: 25.000000
| + A track
| + Track number: 2
| + Track UID: 2437
| + Track type: audio
| + MinCache: 1
| + MaxCache: 1
| + Codec ID: A_VORBIS
| + CodecPrivate, length 4303
| + Audio track
| + Sampling frequency: 48000.000000
| + Channels: 2
|+ Cluster
| + Cluster timecode: 0.000s
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000)
| + Frame with size 51063
| + Block group
| + Block (track number 2, 1 frame(s), timecode 0.000s = 00:00:00.000)
| + Frame with size 95
| + Block group
| + Reference block: -2.000ms
| + Block (track number 2, 1 frame(s), timecode 0.003s = 00:00:00.003)
| + Frame with size 90
| + Block group
| + Reference block: -11.000ms
| + Block (track number 2, 1 frame(s), timecode 0.015s = 00:00:00.015)
| + Frame with size 419
| + Block group
| + Reference block: -20.000ms
| + Block (track number 2, 1 frame(s), timecode 0.036s = 00:00:00.036)
| + Frame with size 428
| + Block group
| + Reference block: -39.000ms
| + Block (track number 1, 1 frame(s), timecode 0.040s = 00:00:00.040)
| + Frame with size 1
| + Block group
| + Reference block: -20.000ms
| + Block (track number 2, 1 frame(s), timecode 0.057s = 00:00:00.057)
| + Frame with size 427
| + Block group
| + Reference block: -20.000ms
| + Block (track number 2, 1 frame(s), timecode 0.079s = 00:00:00.079)
| + Frame with size 433
| + Block group
| + Reference block: -39.000ms
| + Block (track number 1, 1 frame(s), timecode 0.080s = 00:00:00.080)
| + Frame with size 1
| + Block group
| + Reference block: -20.000ms
| + Block (track number 2, 1 frame(s), timecode 0.100s = 00:00:00.100)
| + Frame with size 410
| + Block group
| + Reference block: -39.000ms
| + Block (track number 1, 1 frame(s), timecode 0.120s = 00:00:00.120)
| + Frame with size 27515
| + Block group
| + Reference block: -20.000ms
| + Block (track number 2, 1 frame(s), timecode 0.121s = 00:00:00.121)
| + Frame with size 427

[Atamido]

Originally posted by Gusi
| + A track
| + Track number: 2
| + Track type: audio
| + Codec ID: A_VORBIS
............
| + Block group
| + Reference block: -2.000ms
| + Block (track number 2, 1 frame(s), timecode 0.003s = 00:00:00.003)
| + Frame with size 90
| + Block group
| + Reference block: -11.000ms
| + Block (track number 2, 1 frame(s), timecode 0.015s = 00:00:00.015)
| + Frame with size 419 Okay, something is definately wrong with the muxing here. Track 2 is an audio track, but it has References to other Blocks. (This is like a P frame in video tracks.) There isn't currently an encoder/muxer that will mark audio Blocks as a 'P' frame. (Technically you could with something like MP3, but nothing does)

Other than that, it looks like the first audio Block is at 0 seconds

| + Block (track number 2, 1 frame(s), timecode 0.000s = 00:00:00.000)

So that is right, but there is definately something screwy with the file.

[Gusi]

Hi again and thanks for the reply.
I've checked with some files downloaded from internet and you're right, they don't have the audio track with reference blocks.
What I can't understand it's what's causing this. I'm using the latest matroska pack filters and the directshow graph is as simple as compressing the video and audio streams and muxing with Matroska Muxer from Gabest. Maybe it's a bug in the muxer implementation?
I'm going to investigate further.

Thanks again!

GUSi.

[Gusi]

Hi!
I encoded a pair of new files using the DirectShow Matroska Muxer from Gabest and all the files have references to blocks in the audio tracks. I've tried joining in the directshow graph first the audio track, and it's the same.
So I'm quite convinced it's a bug in the directshow muxer. If Gabest is reading this post, could you be so king to take a minute to check this and fix if possible? I'm a VC++ developer and I'm trying to understand the Muxer code, but to find this bug for me is quite impossible as you could imagine.

Thanks in advance

GUSi.

[gabest]

The muxer puts references to previous frames whenever the current frame is not a sync point (keyframe in DS term). It is possible that the input came from a filter not marking the audio frames as keyframes properly. It isn't a problem when it goes into a decoder or renderer, so filter writers usually don't care about setting this flag.

[kilg0r3]

nice to haveyou back, gabest! :D

[Gusi]

Hi and thank you a lot, Gabest.
I was using the Ogg Vorbis DirectShow encoder, and this seems to be the cause of the audio blocks references. I tried with the standar MP3 encoder and the references are gone, but I can't check the delay problems because the graph converting again to DV is crashing when converted to MP3.
So... I need an audio codec that can be programmed directly ala Ogg Vorbis from DirectShow (Tobias made a fantastic work with the programming interface). Anyone knows an MP3 (or other format) directshow encoder that works correctly? The ogg encoder was fantastic, but I suspect the audio delay problems is coming from it.

Thanks again,

GUSi.

[ChristianHJW]

Originally posted by Gusi I was using the Ogg Vorbis DirectShow encoder, and this seems to be the cause of the audio blocks references.
Gusi, what DirectShow encoder are you using here ? Tobias' encoder from http://tobias.everwicked.com or the new one from Iliminable ?

[Gusi]

I'm using tobias version 0.9.9.5. I didn't know about iliminable version so I'm going to try it. Downloading from http://www.illiminable.com/ogg/ :D
Thank you a lot.

GUSi

[Gusi]

I have to discard iliminable codec because it seems to be unable to connect to any ogg or matroska directshow muxer.
This thing is driving me crazy... :(