TS demux broken even in 130b5

[mshopf]

Hi guys :D,

I wanted to make you aware that even with 130b5 (I couldn't download newer versions, links seemed to be dead) of DGIndex & co I seem to have some frame loss. The following happens for a lot of streams for me:

I have a decent HDTV TS stream with 1080p data, MPeg2Repair tells me that there are no errors in the stream, at least not in the first 90 minutes. I create a d2v project and demux the ac3 audio. I also create an AviSynth 2.5 avs file for loading this into VirtualDubMod.

If I jump to any given potion in the stream, encode a number of frames, and multiplex the ac3 audio, everything's perfect, audio and video are in sync. If I encode the whole stream and jump to the same position in the player, audio and video are out of sync.

I dug deeper into this and noticed that for a specific stream I loose the first frame somewhere between 12300 (IIRC) and 12508, but only if I encode a sufficiently large number of frames. Don't ask me right now what 'a sufficiently large number' is in this case. It's certainly more than 1000 frames.

If I encode a large potion (e.g. from the beginning), I get a scene cut at 12507, while - if I jump directly to the frame or only encode a smaller potion) - I get the (correct) scene cut at 12508 (denoting the first frame of a new scene here).

This is only a single frame, but it tends to get worse later in the stream, I have about 1 sec of audio delay after 60 minutes.

Now the interesting part: If I convert the video with HDTV2Mpeg first, everything's perfect, no frame loss, audio in sync.

If you want to debug this, I would be pleased to make you the data stream available, or even send it on DVD to you (as it's HDTV it tends to be rather large). I'm a computer scientist, so looking at code is no problem for me either, but I don't have a build environment on Windows right now. I also tested this with DGIndex 1.2.1, it suffered from the same symptom. Older versions are not capable of parsing transport streams, so no failure there.

Thanks,
Matthias

[neuron2]

Hmmm. I'm getting a distinct sense of deja vu about this. :)

I'll give you my mailing address in a PM. Please send the entire transport stream on a DVD, as you offered. Thank you.

BTW, there are no versions later than 130b5. What links are you talking about?

[mshopf]

Originally posted by neuron2
Hmmm. I'm getting a distinct sense of deja vu about this. :)
How come ;)

BTW, there are no versions later than 130b5. What links are you talking about?
I read something about a beta7. Maybe that was about another program and I just misread the whole thread :D

About the stream: I accidentally deleted the current one, but I'm sure I'll be able to reproduce, because it happened multiple times for me. It may take some days, though.

[mshopf]

Donald, I tested the stream I sent to you with 1.40b5.

What should I say, things even got worse. :confused:

With 1.30b5 2 frames are lost during encoding the complete file (compared to directly skipping to the according frame). The frame received by directly skipping to one of the last frames (scene change) was the same as when the whole file was encoded after converting it with HDTV2Mpeg - modulo the first GOP which the converted Mpg missed (I guess due to missing B frames).

Now with 1.40b5 65 frames are lost during encoding! Again, when directly skipping to the according comparable frame the frame number is correct i.e. no frames are lost.

For comparison: create a .avs file, encode it once, take a look at frames 33297+33298 (scene change). Open the .avs in VirtualDub directly, and find the same scene change at 33362+33363. Convert it to Mpg and find the scene change at 33348+33349 (-14 frames for first gop), both in encoded form and directly in the .avs. With 1.30b5 the scene change happend (in the encoded file) at 33360+33361.

For validation: The first major scene starts at frame 1001 for the Mpg converted, and at 1015 for all others.

Any ideas?
Thanks

Matthias

[neuron2]

I'll have a look this weekend.

[neuron2]

What are you using for encoding?

Are you able to demonstrate this issue without the encoding (for example, by just playing linearly in VirtualDub)? I can tell you I don't have a lot of time to spend doing encodes. And it's suspicious to me that this only appears to be a problem after encoding. If there is a mismatch between linear decode and random access, you should be able to demonstrate that without encoding.

EDIT: OK, I have seen the effect and am investigating. My first observation is that this stream has no GOP headers. The integrated DGParse has a bug and is showing GOP headers. I'll fix that too. :)

[dlight]

Oh man I'll be happy if you can fix this because I have been encountering this same problem.

[neuron2]

after converting it with HDTV2Mpeg What version did you use? I tried 1.10.3 and it made macroblock hell in the MPEG.

EDIT: I went back to version 1.07 and it is OK. I confirm your result, which points to a problem with transport parsing in DGIndex. Investigating...

Are those guys aware that later versions of HDTV2MPG are brain-dead?

[dlight]

What version did you use? I tried 1.10.3 and it made macroblock hell in the MPEG.

EDIT: I went back to version 1.07 and it is OK. I confirm your result, which points to a problem with transport parsing in DGIndex. Investigating...

Are those guys aware that later versions of HDTV2MPG are brain-dead?

What do you mean by brain-dead?

[neuron2]

What do you mean by brain-dead? I found that when I used version 1.07 to convert the file sent by mshopf, the video was fine. When I used 1.10.3, I got video corrupted by macroblocking, i.e., bad video. The term "brain-dead" was my way of saying that these later versions appear to be broken.

BTW, I may have found the fix to the problem. My initial test this morning succeeded but then I had to go to work. :( I will test it some more this evening. It seems there is a bad test for the start of a video PES packet in the transport parser. Instead of using payload_unit_start_indicator, it was looking for the {packet start code + stream id} to be as expected at the start of the packet, which is unusual if not bizarre. That was inherited from earlier transport versions of DVD2AVI. I changed that to use payload_unit_start_indicator and the one test I did succeeded, whereas it failed with the earlier code.

I don't fully understand it yet, though, because theoretically start code emulation in a video stream is not possible. I think it is actually caused by the read-ahead and then unreading that the code does. If the read-ahead triggers the refilling of the buffer, then unreading by decrementing the read pointer will not be correct. By using the payload_unit_start_indicator, the need for read-ahead/unreading is eliminated.

More later...

[mshopf]

What are you using for encoding?

Ok, just to clearify everything:

I'm using VirtualDubMod 1.5.10.1, XVid 1.1.0-Beta1-16012005 (koepi),
HDTV2Mpeg 1.07 (AFAIR no change when switching to 1.11 Beta). Yes, 1.10.3 didn't work for me either, but 1.11 seems to be pretty solid. And it does no long bug you with "Couldn't sync ac3 paket" (sp?)...

Are you able to demonstrate this issue without the encoding (for example, by just playing linearly in VirtualDub)?

Frankly said, I haven't tried, due to the nature of the bug (no frame loss with the mpeg transformed movie, frame loss with the original data) I haven't bothered because I would be really amused if this would be a XVid or VirtualDubMod bug (not that believe them to be bug free :p )

I can still do this if it would help you.

EDIT: OK, I have seen the effect and am investigating. My first observation is that this stream has no GOP headers. The integrated DGParse has a bug and is showing GOP headers. I'll fix that too. :)

Great news :cool:

I currently happen to stumble accross streams of which appearantly the DELAY during demultiplexing is calculated wrong. But this is only due to me being rather sensitive to async audio. I don't have a clear example at hand, and I would like to solve one problem at a time. So if you don't happen to accidentially fix this bug as well, expect another report in a couple of weeks :D

Thanks

Matthias

[mshopf]

BTW, I may have found the fix to the problem.

Great news!

Though I must admit in your description you lost me a bit. I did write my own TS parser (no further than to the PES level so far) recently, but I seem to have forgotten some of the gory details already...
Have to read it again with the specs at hand.

I don't fully undestand it yet, though, because theoretically start code emulation in a video stream is not possible.

... you could help me a lot if pointed me to a section in the specs start code emulation is explained. Or a short comment... Or is this something internal with the buffer code?

Either way

:thanks:

[neuron2]

See 13818-1 Annex G, and google search for "start code emulation".

Sync byte emulation and start code emulation refer to the appearance during parsing of false sync bytes or start codes due to coincidental patterns in the data. The video elementary streams are designed to avoid emulation of start codes, but emulation can happen in audio and private streams. I was thinking that perhaps the use of the {start code + stream id} test instead of payload_unit_start_indicator might be getting spoofed by emulated start codes. But for video it cannot happen. So I think the problem is the read-ahead/unreading of the {start code + stream id}.

Just for grins, try this on your problem:

http://neuron2.net/dgmpgdec/dgmpgdec140b8.zip

EDIT: I had some time so I encoded the stream sent to me, using the indicated delay of -469ms. The audio was perfectly in sync throughout and the scene change points I tested matched correctly using either linear play or random access.

[neuron2]

Any feedback on this, gentlemen?

[mshopf]

Sorry, Don, I'm a bit slow in response, as I have to co-organize a conference (and I have to give a talk on the weekend and haven't prepared a damned slide yet). I'll let you know as soon as I find out something.

That said, I guess you got it all fixed (the stream I sent you was the worst one so far). Other than checking it myself I can only try future encodes again using dgmpgdec directly, and come back if I happen to find another source of problems.

Thanks a lot for all your time spent! :thanks:

[neuron2]

Of course, I understand the demands of real employment. By all means, do post again if you run into any further difficulties. And many thanks for bringing this issue to my attention (and pushing me a little about it). All transport stream users will benefit.

:thanks:

[Cyberia]

So this was a fix to both DGDecode and DGIndex?

[neuron2]

So this was a fix to both DGDecode and DGIndex? 10-4, because they both have to parse the transport stream.

[mshopf]

By all means, do post again if you run into any further difficulties.

I will. So far everything looks fine :D