[RESOLVED] DGIndexNV strategy for TS errors?

[subpardaemon]

Hi,

After a lot of trial and error, I finally managed to start using DGIndexNV and MeGUI together, and the results are pretty excellent. However, I hit a snag so far regarding an STB capture of a HD programme.

The STB recorded the programme as a series of 1GB elementary TS files (I'm guessing a raw dump of the DVB transport stream). However, it seemed to make glitches in the recorded stream as it switched from one file to the other. This causes the programme audio to become progressively desynced from the picture. Looks like 1-2 frames might have been lost, as the picture becomes momentarily garbled.

So far I've tried the following (at all occasions, I set the PCR and video stream IDs before anything):
- cut the unnecessary parts from the beginning and the end of the project, then saving the project, then encoding: unsynced;
- save the project uncut in DGIndexNV, then do the cuts in MeGUI's AVS cutter, then encoding: unsynced (slightly less);
- cut the unnecessary parts, then saving the cut transport stream within DGINV, then reopening the stream, then making the project, then encoding: unsynced (slightly less).

Right now I'm trying to encode a version where I manually joined the separate TS files into one (with Total Commander's Combine files feature), then ran it through DGINV, then cut the fat in MeGUI's AVS cutter, then started encoding. Will know by tomorrow if there's any change in the sync.

What is really baffling, though, is when I play the joined raw TS file in VLC, the audio sync is PERFECT. Yes, there are glitches in the video where the files were originally switched, but the audio remains in perfect sync. How does VLC manage to do it?

Now I tried to plow through the documentation and the forum, but I couldn't find any writings about how DGINV handles glitches in the stream. Does it simply swallow the erronous frames without a trace? Or does it try to insert blank/repeated frames? Or even garbled frames?

I uploaded the .dgi and .log files under http://meggyfa.vphone.hu/dgi/ . The KAB files are the TC-enjoined TS, the TESTING2 is when I loaded the .TS files separately and let DGINV join them.

[admin]

Hi

Hello.

What is really baffling, though, is when I play the joined raw TS file in VLC, the audio sync is PERFECT. Yes, there are glitches in the video where the files were originally switched, but the audio remains in perfect sync. How does VLC manage to do it?

It reads the PTS timestamps and uses them to present the audio and video in sync.

You have two things going on:

1. You have these unexplained video glitches. I can look at that only if you provide the first two streams. Whether these video glitches
have audio sync implications is an open question. I do not discard garbled frames, so probably this alone isn't causing the desync.

2. You may be accumulating delay at the joints because audio and video access units do not have the same granularity. Still, this
would not be expected if the streams were simply binary splits of a contiguous capture. But again, we don't know how the STB does
the splits.

So, really, I don't know what to advise, without seeing sample streams.

Now I tried to plow through the documentation and the forum, but I couldn't find any writings about how DGINV handles glitches in the stream. Does it simply swallow the erronous frames without a trace? Or does it try to insert blank/repeated frames? Or even garbled frames?

No frames are swallowed or inserted. Whatever the decoder returns is used. DG tools don't know when a frame is garbled.

[subpardaemon]

Hi,

How much would you need in regard of sample size? The entire file is about 5GB, I guess you don't need all of it -- but if you do, I have my own server, so I can upload the entire TS if needed.

I've ran the TS files through ProjectX to check for stream errors, the logfile is at http://meggyfa.vphone.hu/dgi/000_log.txt . Maybe that is useful for something.

I've also downloaded [spam], and ran the files through it, the result is at http://meggyfa.vphone.hu/dgi/_check.txt . It seems that there are two kinds of problems: packet index discontinuities and malformed packets.

In the meantime, can you recommend any worthy software for TS repair?

[subpardaemon]

Further info:
- the TC-enjoined TS file, after encoding, presents the same, progressively worse, audio desync.
- did a comparison encoding with [spam], the audio stayed in perfect sync despite the video glitches.

[admin]

Please don't mention commercial products here. I consider it spam. Yes, I know you were only offering information.

You're confusing me now. You said the files are broken into 1GB pieces and then you say "the entire file is 5GB". I will assume you mean you have 5 1G files. If you can give me all of them that would be perfect, otherwise, give me at least the first two.

[subpardaemon]

Please don't mention commercial products here. I consider it spam. Yes, I know you were only offering information.

Sorry about that.

You're confusing me now. You said the files are broken into 1GB pieces and then you say "the entire file is 5GB". I will assume you mean you have 5 1G files. If you can give me all of them that would be perfect, otherwise, give me at least the first two.

When I joined the files with TC (damn there goes another CP), the result file is about 5GB, but it's nothing more than the separate .ts files combined.

I've started uploading the .ts files (as I've scanned through the log the first two should be enough for starters as they present all the error/warning varieties the parser encountered), it's gonna take about 5 more hours for 000 and 001 to complete (hah, it's Hungary, where uploads are ehhh). When it's done, they will be available at http://www.pdx.hu/jobs/dgi/ , and I'll drop a line here. The rest will be uploaded as well (002-004), but it's quite possible it'll take another 10 hours or so.

[admin]

Thanks for the explanation. I'll start downloading when you post here that at least the first two files are there.

[subpardaemon]

Thanks for the explanation. I'll start downloading when you post here that at least the first two files are there.

they're up. the rest are still being uploaded, but 000 and 001 are complete.

[admin]

OK, thanks. Investigating...

[subpardaemon]

By the way, the whole seems to have finished, so the entire project (000-004.ts) is up if you need it.

[subpardaemon]

A minor additional detail: while in the beginning the audio is in perfect sync, by the end it comes around 500ms too early. That means somewhere along the line the audio lost around 12 (video) frames' worth of data, leading me to believe that there might be some audio-heavy packets that get lost while video is retained. But that's just spitballing on my part, I'm still trying to wrap my head around the TS internals.

Would it be worth investigating what would happen if I tried frameserving the audio along the video in the .avs file, insteading of demuxing the audio part and working with that file?

[admin]

Still investigating...

[subpardaemon]

any news? could you confirm that the desync actually happens?

[admin]

I confirm that the desync exists but it would be a bit of a project to find the exact causes. Clearly it accumulates at each file joint. All I can suggest, given that I don't know the details of this STB file storage and I am not familiar with any other tools that might help, is to write a script to manually correct the sync at each file joint. Or just play the TS files and be happy.

[subpardaemon]

I confirm that the desync exists but it would be a bit of a project to find the exact causes. Clearly it accumulates at each file joint. All I can suggest, given that I don't know the details of this STB file storage and I am not familiar with any other tools that might help, is to write a script to manually correct the sync at each file joint. Or just play the TS files and be happy.

the problems do not just happen at the file joins, as the log files show. since it was a terrestrial broadcast (DVB-T), i'm guessing the TS stream itself contains these errors, as the STB seems to be simply recording the TS as-is.

what i find alarming is that DGINV seems to contain a watchdog for misaligned A/V streams (cf option Response to mismatched audio), but somehow these stream errors slip by this mechanism.

since i'm a software engineer, that got me thinking how that could happen. how do you parse the stream? do you go by the stream checking for timecode of the packets? do you employ a different strategy for parsing the video stream and the audio stream? because if you go by timecode, you should notice that there is a video packet with a timecode that doesn't have a matching audio packet, or vice versa -- this is when the Response to mismatched audio should kick in, right?

sorry, i'm just shooting in the dark with these as i don't have the source code of DGINV and only limited understanding of the TS structure...

[subpardaemon]

some more spitballing:
- do you preparse the stream for invalid/erroneous packets? because if not, i can very well imagine that such a desync might occur as you have no means to look ahead and check if all valid audio packets have a matching video packet. if i had to write a demuxer (hopefully i won't have to ), i'd first run through the TS stream and check if all video frames have enough matching audio frames, and make note of frames that don't have both audio and video -- the strategy to handle such errors would be then a matter of choice between dropping those frames, or copying the previous OK frames instead, or just insert blank video/audio. (btw, i don't know how granular the audio packets are -- is it the rule that one video frame (or packet -- does one video packet contain an entire I, P or B frame?) should have one matching audio frame (or packet), or do many audio packets make up one video frame's worth time?)
- do you expect packets to align to file boundaries, or do you treat a TS split into several files as one virtual file? i guess the latter, as joining the .ts files in TC led to the same desync.
- do you check the packets for CRC errors? (i guess you do.)

[admin]

the problems do not just happen at the file joins, as the log files show.

What log files?

what i find alarming is that DGINV seems to contain a watchdog for misaligned A/V streams (cf option Response to mismatched audio), but somehow these stream errors slip by this mechanism.

No, the mismatch there refers only to a mismatch between what the PAT/PMT says the audio streams are and what my software detects them to be by reading audio headers etc. It has nothing to do with desync between audio and video.

[admin]

some more spitballing:
- do you preparse the stream for invalid/erroneous packets? because if not, i can very well imagine that such a desync might occur as you have no means to look ahead and check if all valid audio packets have a matching video packet. if i had to write a demuxer (hopefully i won't have to ), i'd first run through the TS stream and check if all video frames have enough matching audio frames, and make note of frames that don't have both audio and video -- the strategy to handle such errors would be then a matter of choice between dropping those frames, or copying the previous OK frames instead, or just insert blank video/audio. (btw, i don't know how granular the audio packets are -- is it the rule that one video frame (or packet -- does one video packet contain an entire I, P or B frame?) should have one matching audio frame (or packet), or do many audio packets make up one video frame's worth time?)

My software does nothing like that. It assumes that the files are correct. You will need to turn to other software, such as ProjectX, TSDoctor, etc., to get this kind of functionality.

- do you expect packets to align to file boundaries, or do you treat a TS split into several files as one virtual file? i guess the latter, as joining the .ts files in TC led to the same desync.

When multiple files are loaded, it is equivalent to combining them by simple binary concatenation.

- do you check the packets for CRC errors? (i guess you do.)

Transport packets do not carry CRCs.

I understand that this is important for you, but frankly, it is a very big project to analyze and diagnose the causes of your situation and code any possible mitigation. I have one person asking for this and it is not relevant to me personally. With all the other exciting things to work on that affect lots of people and which I personally need as well, I can't justify spending lots of time on this.

[subpardaemon]

My software does nothing like that. It assumes that the files are correct. You will need to turn to other software, such as ProjectX, TSDoctor, etc., to get this kind of functionality.

ahaaaa! that's where i was wrong, i assumed DGINV was performing some kind of sanity check on the TS files dumped onto it (hence the mismatched audio/video option), but now it's clear it's not. not a problem, i thought there was a bug in the TS parser and that's why i alerted you to all this. thanks for the help, i'll get projectx on the job and see if it clears up the desync issue.

Transport packets do not carry CRCs.

i meant the FEC present in a TS stream, but now rereading some of the specs indeed it's not on a packet level.

[subpardaemon]

btw, i have managed to solve the issue (after none of the stream fixers i tried managed to overcome the error): around the points where stream analyzers detected serious errors, i looked for the nearest scene change, and chopped a few a frames from there (using megui's AVS cutter feature), and did the transcoding like that. now the sync is restored.

sorry for bothering you.

[admin]

No problem on bothering me, and I'm glad you have a workaround.

I suppose the STB software has some proprietary way to stitch the pieces together for playback.

[subpardaemon]

hah, not over yet.

one more question: since you suppose that dginv gets an error-free TS as an input, during demuxing, do you also export the audio frames as-is, even if they contain a frame error? since i still get a/v desync from time to time, i'm trying to narrow down where the desync actually occurs.

[admin]

If an audio header is corrupted that frame will be lost.

[subpardaemon]

If an audio header is corrupted that frame will be lost.

aha! so in theory (and practice), a DVB-C stream containing glitches might end up with a different number of frames in the video output (ie the dgi and avs files) and the demuxed audio files (all or some), right?

[admin]

Audio and video frames do not have the same granularity, so comparing their number is problematic. If, at a given point in a stream, some video is lost but not audio, or vice versa, then a desync will be caused from that point forward. The desync at any given point will be determined by the cumulative losses of video and audio.