Sync problems

[Rufus]

Hello,

I've been trying to fix my DVB-T recordings with ProjectX, using demux. Unfortunately, most of my material still comes out with video and audio badly out of sync after remultiplexing. I have tried several multiplexers with the same result.

My DVB-receiver is the Hauppauge WinTV Nova-t PCI (same as the Technotrend TT-PCline budget) which apparently outputs some variant of an MPEG2 Program Stream (not Transport Stream nor PVA).

I'm quite sure the problems are related to the cuts I experience in reception. However, as the recorded stream plays quite well in various software players, it should no doubt be possible to fix it for DVD authoring.

I would be glad to send the author some sample streams on DVD by snail mail if that could help in investigating the problem.

Just let me know. Also, thanks for all the work done so far.

Regards,
Rufus
--
Hauppauge WinTV Nova-t PCI - TechnoTrend driver v. 2.3.0.1
TechnoTrend DVB-TV 2.16
MPG-MP2
X 0.81.5, JDK/JRE 1.4.1_01


[equote:8ee0c2b56e="Edit Admin"][center:8ee0c2b56e]Attachment gelöscht und lokal archiviert

Lucike[/center:8ee0c2b56e]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:8ee0c2b56e]

[dvb.matt]

hi,

first you may update the sources as we collected here (http://forum.dvbtechnics.info/viewtopic.php?t=252).
it contains some changes maybe affecting your stream data..

awaiting your report...

[Rufus]

Hello,

The new code did improve the result. My recordings now seem to stay _almost_ in sync.

However, the result is still not quite right. On my sample movie, a/v sync is off by about 0.1 -0.2 seconds at the end. Video seems to run ahead, which apparently means that either too much video is cut compared to the audio or too little audio is cut compared to the video.

I also tried demuxing with "limit points of Audio PTS for sync" enabled, but that produced slightly worse output on my test material.

Regards,
Rufus
--
Hauppauge WinTV Nova-t PCI - TechnoTrend driver v. 2.3.0.1
TechnoTrend DVB-TV 2.16
MPG-MP2
X 0.81.5a, JRE 1.4.1_01


[equote:a51dc46eaa="Edit Admin"][center:a51dc46eaa]Attachment gelöscht und lokal archiviert

Lucike[/center:a51dc46eaa]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:a51dc46eaa]

[dvb.matt]

GOP#41 has no PTS, use last PTS for sync
GOP#41, new format in leading sequenceheader detected:
-> video basics: 0*0 @ forbidden fps @ res. @ 0bps, vbvBuffer 0
dropping gop(sequence) @ orig.PTS 00:00:20.968 / new Timecode 00:00:00.000
GOP#41, Pics expected/count 1/0 ; PTS difference 0ms (should be 0)
GOP#42, new format in leading sequenceheader detected:
-> video basics: 720*576 @ 25fps @ 0.7031 (16:9) @ 10000000bps, vbvBuffer 112

I'm still confused by the 'red' line (GOP41).
I'll prepare a little extraction job for you :)

[Rufus]

Hello,

I believe GOP41 occurs at about the time when broadcast changed from 4:3 to 16:9. Sync seems to keep OK past that transition, though.

The sync skew is actually noticeable only after some point into the second hour of the program (not quite sure where exactly).

Anyway, I'll be happy to run any tests you may have for me.

Regards,
Rufus

[dvb.matt]

video: fr/ct/1p/cg/og/dg 202021/7/16844/16837/0/7
your stream data seems to contain only one PTS per GOP.
so it's a bit more difficult to detect errors in time.
that's why a GOP error came without PTS error (->PTS difference 0ms; means diff in a GOP).

ATM I can't figure out a problem, the only one is the sequenceheader error (0*0).
if you use the GUI, on demux the right value of the field A/V offset should not exceed the range of -12..12 for your actual audio type, otherwise sync is not checked anymore.
the audio errors are not the worst, esp. after 2:02:xx it's not of interest for you, I guess.

do you've tried out several muxers afterwards?

Thus you can help with a little file only (as above):
(1)open the X Hexviewer while doublecklicking the fileproperties (left/bottom) in 'files'.
(2)navigate (with bytepos cut) in the X preview to the 1st aspectratio change (GOP42->16:9)
(3)go 2 GOPs backward ("<")
(4)copy & paste the shown bytepos. into the hexviewers 'jump to (dec.)' field; enter.
(5)type in the same value as hex into the left 'extract from..' field
(6)go 3 GOPs forward (">") (2nd GOP with 16:9)
(7)copy & paste the shown bytepos. into the hexviewers jump to (dec.) field; enter.
(8)type in the same value as hex into the right 'extract from..' field
(9)press 'extract' button, save the file and post/upload it.

so I can mess around with it..

[Rufus]

Hello,

Yes, I tried different multiplexers, but the problem remains the same.

You're correct that the audio errors past 2:02 aren't interesting since the program I was recording had already ended at that point. Any idea what those errors are about, anyway ?

The sample you requested appears to be too big for posting at the forum. You can download it from here:

http://www.selen.org/files/temp/empire-sample.zip

Regards,
Rufus
--
Hauppauge WinTV Nova-t PCI - TechnoTrend driver v. 2.3.0.1
TechnoTrend DVB-TV 2.16
MPG-MP2
X 0.81.5a, JRE 1.4.1_01

[dvb.matt]

thx.

but Oops. sorry.
It seems we have to make more precise descripitions:
..
(5)type in the same value as hex number into the left 'extract from..' field
(8)type in the same value as hex number into the right 'extract from..' field
..
thats why I let you type in the pos. as in (4)+(7) cuz' it converts it to a hex number for the extraction fields below.

Thus your IN '8440190' is '80C97E' and OUT '9147546' is '8B949A' instead. (without leading '0x')
the resulting file size will be 707356 bytes.
but before uploading just check out whether it really includes the '0*0' error..

Additionally, for the _complete_ file, set the option 'specials1' -> 'dump dropped gops to separate files'.
so any discarded gop will be saved as .bin, too. (each ~180kb)

Then we have 8 .bins (7 dropped plus the binary cut) to play around with..

anyway, a nice cut-off (BBC2?), cuz usually we can't get that original version for free here..

bye

[Rufus]

Hello,

I'm sorry, I really wasn't thinking. Perhaps this one is better:

http://www.selen.org/files/temp/empire-debug.zip

The cut sequence indeed holds the "0*0" -error. Also, the package includes the 7 dropped GOPs as well as two .bin -files (apparently) from the very beginning of the file.

The recording is from YLE2 in Finland and yes, I think it's quite nice, too. :)

Regards,
Rufus
--
Hauppauge WinTV Nova-t PCI - TechnoTrend driver v. 2.3.0.1
TechnoTrend DVB-TV 2.16
MPG-MP2
X 0.81.5a, JRE 1.4.1_01

[dvb.matt]

hi

ATM the 0*0 error is fixed (no message anymore), but the results if such an error occurs are the same and already ok.

Also the dropped GOPs are really 'bad', so thats right.
There is one error, where X isn't looking for. I'll try to implement this, but guess, that it does not affect your prob. ..

[Rufus]

Also the dropped GOPs are really 'bad', so thats right.
There is one error, where X isn't looking for. I'll try to implement this, but guess, that it does not affect your prob. ..

I have spent some time trying to find the specific points where my recording goes out of sync, but it's quite difficult since the difference at the end of the film is only a couple tenths of a second.

Anyway, I extracted two sequences which have errors in them for you to examine, if you want.

One (according to ProjectX) only has useless B-frames while the other contains a cut which requires dropping an entire GOP plus some B-frames. These are at about 0:18:52 and 0:23:48, respectively (see my earlier log files for details).

While there is not necessarily a huge sync problem immediately noticeable in these examples, I can't help but draw the conclusion that sync goes off during breaks or disturbances in the recording. I guess it's possible that small sync anomalies caused by the cuts accumulate during the course of the recording.

You'll find the samples here:

http://www.selen.org/files/temp/EmpireCuts.zip (22 MB)

If you need anything else, just let me know.

Regards,
Rufus
--
Hauppauge WinTV Nova-t PCI - TechnoTrend driver v. 2.3.0.1
TechnoTrend DVB-TV 2.16
MPG-MP2
X 0.81.5++, JRE 1.4.1_01

[dvb.matt]

well, got that, but not with another realization.. :(
AFAIS it's not going off sync in the examples after demux..
One (according to ProjectX) only has useless B-frames thats why the remaining frames in the GOP before are usable (better: not detected as wrong), but not complete. (you see only a little slice error, not that worse)
thus it's only shorter than the 'real' transmission, but not off sync after that..
small sync anomalies caused by the cuts
maybe there's an errorneous GOP not yet detected, so try the latest update of X, whether more errors coming out..

[Rufus]

Hello,

Apart from some (cosmetic ?) changes in the log output, there doesn't seem to be any concrete difference from the previous version.

I'll watch through the entire recording once more and see if I can spot any additional problems.

Regards,
Rufus
--
Hauppauge WinTV Nova-t PCI - TechnoTrend driver v. 2.3.0.1
TechnoTrend DVB-TV 2.16
MPG-MP2
X 0.81.5++ (05.11.2003), JRE 1.4.1_01


[equote:9486930ac8="Edit Admin"][center:9486930ac8]Attachment gelöscht und lokal archiviert

Lucike[/center:9486930ac8]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:9486930ac8]

[dvb.matt]

not only cosmetic.. ;)
but you're right..
meanwhile I found smth more that X ignores..

[Rufus]

not only cosmetic..
but you're right..
meanwhile I found smth more that X ignores..

I have continued examining my recording and found a couple of interesting properties.

First of all, I extracted a sequence without any errors from the end of the recording using the hex editor. After running that through Project X, multiplexing and burning to DVD the same 100-200 ms delay in audio is there. This leads me to believe that there is indeed a small sync problem already in the original recording towards the end.

Secondly, there appears to be a small overall skew introduced by Project X. I have found that running demux with an "additional time offset" of -100 ms improves lipsync. Normally, that small a difference is not noticeable, but together with the delay from the original recording (which by itself is not really noticeable, either) the sync problem becomes apparent.

However, with the additional offset of -100 ms, my recording is now watchable in its entirety. One might, however, wonder why this is necessary since the original recording _appears_ to play perfectly in sync (apart from the minor problems towards the end) ?

Regards,
Rufus
--
Hauppauge WinTV Nova-t PCI - TechnoTrend driver v. 2.3.0.1
TechnoTrend DVB-TV 2.16
MPG-MP2
X 0.81.5++ (16.11.2003), JRE 1.4.1_01