TS demux broken even in 130b5

mshopf · 18th April 2005, 17:22

Hi guys

,

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

Guest · 18th April 2005, 20:15

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 · 18th April 2005, 21:15

Quote:

Originally posted by neuron2
Hmmm. I'm getting a distinct sense of deja vu about this.

How come

Quote:

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

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 · 9th June 2005, 23:01

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

What should I say, things even got worse.

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

Guest · 10th June 2005, 02:46

I'll have a look this weekend.

Guest · 10th June 2005, 13:43

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 · 10th June 2005, 18:43

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

mshopf · 13th June 2005, 17:22

Quote:

Originally Posted by neuron2

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?)...

Quote:

Originally Posted by neuron2

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

)

I can still do this if it would help you.

Quote:

Originally Posted by neuron2

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

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

Thanks

Matthias

Guest · 12th June 2005, 04:06

Quote:

Originally Posted by mshopf

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 · 13th June 2005, 13:57

Quote:

Originally Posted by neuron2

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?

Guest · 13th June 2005, 16:11

Quote:

Originally Posted by dlight

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 · 15th June 2005, 00:46

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!

Guest · 15th June 2005, 01:30

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.

Cyberia · 16th June 2005, 22:02

So this was a fix to both DGDecode and DGIndex?

Guest · 16th June 2005, 23:26

Quote:

Originally Posted by Cyberia

So this was a fix to both DGDecode and DGIndex?

10-4, because they both have to parse the transport stream.

mshopf · 17th June 2005, 11:07

Quote:

Originally Posted by neuron2

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

I will. So far everything looks fine

18th April 2005, 17:22	#1 \| Link
mshopf Registered User Join Date: Apr 2005 Posts: 7	TS demux broken even in 130b5 Hi guys , 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

10th June 2005, 13:43	#6 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	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. Last edited by Guest; 10th June 2005 at 14:54.

18th April 2005, 20:15	#2 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	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?

9th June 2005, 23:01	#4 \| Link
mshopf Registered User Join Date: Apr 2005 Posts: 7	Donald, I tested the stream I sent to you with 1.40b5. What should I say, things even got worse. 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

10th June 2005, 02:46	#5 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	I'll have a look this weekend.

10th June 2005, 18:43	#7 \| Link
dlight Registered User Join Date: Mar 2005 Posts: 26	Oh man I'll be happy if you can fix this because I have been encountering this same problem.

15th June 2005, 00:46	#12 \| Link
mshopf Registered User Join Date: Apr 2005 Posts: 7	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!

15th June 2005, 01:30	#13 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	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.

16th June 2005, 22:02	#14 \| Link
Cyberia Moderator Join Date: Nov 2002 Location: Inside Posts: 718	So this was a fix to both DGDecode and DGIndex?