ERRORS @ Navigation Packs (might that be the freeze cause ?)

[gm901]

Trying to figure out why some standalone players may not play a DVD-RB movie (freezes etc) I found out the following.

Original Movie (in fact Main Movie from Shrink)
Number of Video Packs=2267323
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=7243
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26

Transcoded Movie (DVD-RB 0.69 + 0.72, CCE)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=82 <------

Transcoded of transcoded Movie (DVD-RB 0.72 "No Compression (100% Video)" – to correct any errors)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26 <------ (now corrected)


Checking (viewing) the (82-26=)56 Nav Packs with Zero Cell Elapsed Time (BCD 0x40), there were the freezes.

Is that eventually the problem?

Any comments please…


---------------------------------
Edited according to next 2 posts.

[jdobbs]

I, for one, am confused. How can you have 26 cells of which 82 have a zero elapsed time?

[gm901]

Sorry, copy-paste error...

Instead of
Number of Cells with Zero Cell Elapsed Time (BCD 0x40)
you should read
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)

[jdobbs]

Let me make sure I understand...

In the last example you took the output from DVD-RB and then ran it through DVD-RB using "No Compression" and the result was different?

Does the transcoded transcode work correctly (after two times through DVD-RB)?

[gm901]

Yes. Because No Compression (100% Video) “is also a way in which previously created discs can be demuxed and remuxed to fix possible errors “ as you say.
As you see there is no Phase II, just demuxing and remuxing (and correcting…)
Now the movie is (navigation) error free.

Transcoding...
-----------------
[19:32:13] Phase I, PREPARATION started.
- VTS_01: 2.282.646 sectors.
-- Scanning and writing .D2V file
-- Video demultiplexing...
-- Processed 168.381 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 98,4%
- Overall Bitrate : 4.973Kbs
- Space for Video : 4.088.962KB
- HIGH/LOW/AVERAGE Cell Bitrates: 5.778/3.875/4.973 Kbs
[19:38:54] Phase I, PREPARATION completed in 6 minutes.
[19:38:54] Phase II ENCODING started
[19:38:54] Phase II ENCODING completed in 0 minutes.
[19:38:54] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Rebuilding segment 2 VOBID: 1 CELLID: 3
- Rebuilding segment 3 VOBID: 1 CELLID: 4
- Rebuilding segment 4 VOBID: 1 CELLID: 5
- Rebuilding segment 5 VOBID: 1 CELLID: 6
- Rebuilding segment 6 VOBID: 1 CELLID: 7
- Rebuilding segment 7 VOBID: 1 CELLID: 8
- Rebuilding segment 8 VOBID: 1 CELLID: 9
- Rebuilding segment 9 VOBID: 1 CELLID: 10
- Rebuilding segment 10 VOBID: 1 CELLID: 11
- Rebuilding segment 11 VOBID: 1 CELLID: 12
- Rebuilding segment 12 VOBID: 1 CELLID: 13
- Rebuilding segment 13 VOBID: 1 CELLID: 14
- Updating NAVPACKS for VOBID_01
- Rebuilding segment 14 VOBID: 2 CELLID: 1
- Rebuilding segment 15 VOBID: 2 CELLID: 2
- Rebuilding segment 16 VOBID: 2 CELLID: 3
- Rebuilding segment 17 VOBID: 2 CELLID: 4
- Rebuilding segment 18 VOBID: 2 CELLID: 5
- Rebuilding segment 19 VOBID: 2 CELLID: 6
- Rebuilding segment 20 VOBID: 2 CELLID: 7
- Rebuilding segment 21 VOBID: 2 CELLID: 8
- Rebuilding segment 22 VOBID: 2 CELLID: 9
- Rebuilding segment 23 VOBID: 2 CELLID: 10
- Rebuilding segment 24 VOBID: 2 CELLID: 11
- Updating NAVPACKS for VOBID_02
- Rebuilding segment 25 VOBID: 3 CELLID: 1
- Updating NAVPACKS for VOBID_03
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
Correcting VTS Sectors...
[19:49:27] Phase III, REBUILD completed in 11 minutes.

Done.

[jptheripper]

Transcoded Movie (DVD-RB 0.69 + 0.72, CCE)

what does that mean.. its the same with .69 and .72?

interesting that running through twice fixes, too bad there isnt an easy way to see what changed.

[gm901]

0.69, 0.70 and 0.72 produced exactly the same encoding Phase I results (binary compared all files in D2VAVS).
And the “No Compression (100% Video)” demuxing produced the same Phase I results, but obviously the remuxing is different.

That’s the point.
The differences between the two remuxing procedures.

And, I know, there isn’t an easy way. I used Vobedit, copy to excel to ascii compare …
Until I modified a free program + source I’ve found so as to auto check all nav packs.

[jdobbs]

Yes. Because No Compression (100% Video) “is also a way in which previously created discs can be demuxed and remuxed to fix possible errors “ as you say. That's what throws me off. In the quote you give I'm talking about remuxing from a source that was created by a different DVD-RB version.

Both methods (No Compression or Reencoding) use the exact same remuxing routines. The only difference is the generation of the .M2V files (one demuxes them from the source, the other uses AVS files for decoding and reencoding).

So the question is (assuming what you are saying is accurate): What the hell could be changing by running it through the exact same algorithm twice? That is, of course, for me to figure out...

[robot1]

I think he run the first time DVD-RB 0.69.
The second time (with no compression) DVD-RB 0.72
With the same .m2v, the results are different (and without stutters) because DVD-RB 0.72 have a better muxing engine.

[jdobbs]

Now that could make sense.

Just for the record... I would never recommend anyone stay with any of the older versions. This is a beta, and every new release can make a lot of difference.

[gm901]

I’ve transcoded the movie 3 times using 0.69, 0.70 and 0.72 expecting that each new version might have solved the problem.
Each time the results were the same.
The “No Compression” was applied to BOTH 0.69 and 0.72 results.
Specifically, the 0.70’s “No Compression” to 0.69’s output, and the 0.72’s to 0.72’s
The resulting movie in both situations was OK and identical.
Therefore it’s not the 0.69 engine.
The 0.72 created 56 more zero navpacks and the same 0.72 corrected them.

...one demuxes them from the source, the other uses AVS files for decoding and reencoding.

So there at least one difference.

And the most important point is, I think, why these zero navpacks were created in the first place.

[jdobbs]

@gm901

Please check your PM.

[jptheripper]

i just want to complement on gm901 and jdobbs for awesome troubleshooting.

good luck and thanx for sticking thru it.

I wonder if its a error in the cce generated m2v file that is fixed while demuxing (as opposed to something that rebuilder is specifically doing). That is, rebuilder on intial run assumes its correct and uses it, but the demux fixes it. Not that i have any idea what it might be.

Regardless, for an extra 20 mins or so i am tempted to suggest a pseudo 4 click mode with fourth click the "no compression" as a temporary patch until the problem is fixed for anyone experiencing the studder.

again thanx and good luck

[jdobbs]

Hmmm... since I've never actually seen this problem on any of several players or experienced it myself -- I have to believe recommending using this as a fix for what I'm not even sure is really a problem is a little premature.

As was found in several other instances of problems -- sometimes it comes down to something a lot more simple (like using the right decoder).

[gm901]

“The specific movie was OK when I’ve tested it to my pc dvd drives (Sony and LG) and to a standalone Pioneer. However, when I’ve tried to watch it to another standalone LG (7600 or 8600 ?) there were freezes, skippings and stops. Lots of them.
The only way to reproduce the error back home is to play it Fast Forward (32X) to PowerDVD 6 (Show Information ON, Bitrate drops from 20Mbps to 0, timer and image freezes and after a while skips some minutes and so on).”

For details see:
http://forum.doom9.org/showthread.php?s=&threadid=89467

An idea would be, while processing, to count zero time navpacks against number of cells, and issue a warning at log whenever there are differences. This is what I’m doing now after reencoding each movie using a little program, just to be sure.
As a matter of fact, I’m checking both original + DVD-RB’s output packs, to find any differences.
BTW, why are there so many more (7243 - > 14084, almost double) nav packs at DVD-RB’s output comparing to original?

[gm901]

YES YES YES


Both methods (No Compression or Reencoding) use the exact same remuxing routines. The only difference is the generation of the .M2V files (one demuxes them from the source, the other uses AVS files for decoding and reencoding).


Up to now, me the @#*!&%#$, I’ve compared all Phase I: Prepare outputs (D2VAVS files) of each DVD-RB version I’ve used (0.69 to 0.72). And they were identical.
But, the great @#*!&%#$^)!!$%, didn’t check the obvious.
The Phase I: Prepare output of normal encoding against the Phase I: Prepare output of “No Compression”. What have I found out ???
The Phase I: Prepare output of normal encoding produced 82 avs files (V01000000001001.AVS to V01008100003001.AVS)
while Phase I: Prepare output of “No Compression” produced 26 avs files (V01000000001001.AVS to V01002500003001.AVS)

These are the 56 more zero navpacks.

See the diffs for example of V01000000001001.AVS

V01000000001001.AVS of Phase I: Prepare output of normal encoding
#------------------
# AVS File Created by DVD Rebuilder
# VOBID:01, CELLID:01
#------------------
LoadPlugin("C:\Program Files\_MM\dgmpgdec1012a\DGDecode.dll")
mpeg2source("G:\_MOVIES_TEST\CONDOR\CONDOR_RB1_W_2004.02.10\D2VAVS\V01.D2V")
trim(0,2331)
ConvertToYUY2(interlaced=true)
AudioDub(BlankClip())

V01000000001001.AVS of Phase I: Prepare output of “No Compression”
#------------------
# AVS File Created by DVD Rebuilder
# VOBID:01, CELLID:01
#------------------
LoadPlugin("C:\Program Files\_MM\dgmpgdec1012a\DGDecode.dll")
mpeg2source("G:\_MOVIES_TEST\CONDOR\CONDOR_RB2_W_2004.02.10\D2VAVS\V01.D2V")
trim(0,9196)
ConvertToYUY2(interlaced=true)
AudioDub(BlankClip())

Sorry for not being enough accurate.
(Sometimes, I feel soooo angry at my stupidity….)

So the errors are not introduced by Phase III: Remuxing, but by Phase I: Demuxing.

Are we getting somewhere?
Is there any difference between normal Phase I and “No Compression” Phase I procedure ???

[gm901]

Back home, time for new experiments…

Extra info: In my previous post
0.72 Phase I: Prepare Mode 1 (CCE) was applied to Original (result 82 avs files)
0.72 Phase I: Prepare Mode 4 (100%) was applied to 0.72’s transcoded (result 26 avs files - OK)
But the input of each Phase was different.
Testing some more, I run
0.72 Phase I: Prepare Mode 4 (100%) to Original (result 82 avs files) !!!
0.72 Phase I: Prepare Mode 1 (CCE) to 0.72’s transcoded (result 26 avs files - OK) !!!

Therefore the Prepare Phase produced the same results according to the input.
So there should be no differences of preparing in mode 1 and 4.
Then the question is:

Why when the input is the original (Main Movie Shrinked I remind you – but checked and found navigational OK, both navpacks and viewing – 26 cells/zero time navpacks) the Phase I produces 82 avs, while when the input is the transcoded (with 82 zero time navpacks and freezing) it produces the correct 26 avs/zeros ???????

Now I’m completely lost…..

Please let me know what to check, what points exactly of the ifos, vobs the DVD-RB is analyzing as to create an avs file.
The ifos at both cases (orig. and transcoded) have the correct information concerning cells (26)

I’ve tested 0.75
Didn’t have the time to run a full reencoding, but it produced exactly the same results when Preparing, as 0.72 (82 avs to Orig. and 26 to transcoded). So I presume the final transcoded movie will also have 82 zero time navpacks = 56 freezes.

[jdobbs]

There are many, many good reasons why the number of AVS files (segments) don't match the number of cells. In fact you will find that it seldom does. For example, there are times when it is important that you have an I-Frame at a certain location, and the only way you can do that on some encoders (e.g. CCE Basic) is to start a segment there -- the cell count will be correct (based on the original) upon rebuild.

But you may be onto something here, and I'll follow up.

When you say "zero navpack" -- exactly what to you mean? From earlier e-mails -- you're counting the number of navpacks that have no value in the PCI_GI (BCD) at offset 0x45 in the navpack? The reason I ask is that zero is an illegal value in that field -- and you are saying the original had 26 of them. (two bits are used to show the frame_rate as part of the framecount portion and 00 is an illegal frame rate)

There are also lots of reasons for why there could be more navpacks -- it is reauthored. That does look like a large difference, though. I'll check on that too.

[gm901]

When you say "zero navpack"….

When offset 0x45, Zero Cell Elapsed Time as named by VobEdit, has value 0x40 as BCD (or 00.00.00,00 as time)

[gm901]

I don’t know if it may help you, but since I don’t know lots of things …
When checking, having no knowledge of vob structure, I’ve tried to locate within vob, the spots where the freezes happened. Then I copied VobEdit’s screen to Excel, and I ascii compared the specific data of the error movie vob against the mode 4 (100%) produced OK.
The first thing I noticed (and understood) was the offset 0x45.

But the total differences were:

Offset VobEdit’s description
-------- -----------------------------------------------------
(navigation pack where 1st freeze happens)
[0004] SCR (System clock reference)
[0045] Cell elapsed time (BCD)
[0407] system clock reference
[040f] VOBU end address - relative
[0413] VOBU first reference frame end block
[0417] VOBU second reference frame end block
[0423] Cell elapsed time (BCD)
[0599] offset to audio packet for AudioStrem1

and at the next navigation pack there are 2 more (plus the above):
[002d] this->lba
[040b] this->lba

Can’t evaluate if it means anything…
If you need the values, let me know.

[jdobbs]

Ok. That makes more sense. VOBEDIT only displays the interpreted value and removes the two bits showing frame rate -- it just puts a "/" followed by the framerate (e.g. "25" or "30")

It appears from what you are saying that (perhaps) each segment may be resetting that value to zero (which, of course, it shouldn't do -- as it only goes back to zero for each cell). Hmm... you may be onto something -- I'll check it out and give you some feedback.

This could also be the root of some previously reported display clock goofiness. (Don't you love the way I use strict scientific terms)

Good debugging, by the way, you're a helluva beta tester! I can only imagine how much work this must have been to find!

[jdobbs]

@gm901

Yep. You nailed it. I wasn't keeping the cell elapsed time current between segments. The fix will be in version 0.76.

Thanks, dude!

[gm901]

I thank you for your passion & dedication.
You must be in love with this project

[jptheripper]

You both rock!! congrats

[XMEN3]

Originally posted by gm901
Trying to figure out why some standalone players may not play a DVD-RB movie (freezes etc) I found out the following.

Original Movie (in fact Main Movie from Shrink)
Number of Video Packs=2267323
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=7243
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26

Transcoded Movie (DVD-RB 0.69 + 0.72, CCE)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=82 <------

Transcoded of transcoded Movie (DVD-RB 0.72 "No Compression (100% Video)" – to correct any errors)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26 <------ (now corrected)


Checking (viewing) the (82-26=)56 Nav Packs with Zero Cell Elapsed Time (BCD 0x40), there were the freezes.

Is that eventually the problem?

Any comments please…


---------------------------------
Edited according to next 2 posts.

HOW DO I FIND THESE VALUE?

[Trahald]

Originally posted by XMEN3
HOW DO I FIND THESE VALUE?
answer--
Originally posted by gm901
And, I know, there isn’t an easy way. I used Vobedit, copy to excel to ascii compare …
Until I modified a free program + source I’ve found so as to auto check all nav packs.
basically means a lot of work.

[XMEN3]

ok...so...demuxing e rebuilding the movie again with dvd-rb 0.76 will adjust everithing?:rolleyes:

[jdobbs]

Yes. Actually demuxing and rebuilding using the "No Compression" option of any version would work. Or just use v0.76 which corrects it from the start.

The odd thing is that this would have an effect on playback. I always thought the BCD fields in the NAVPACK were only used for display of playback times -- apparently some players use it for more.

[XMEN3]

again...the bug is present on dvd-rb from the beginning? first beta version?

[gm901]

Hi,

Tried the new 0.76. Done a full reencoding…
Well, didn’t had the chance to “real test” it (I visit the touchy LG every weekend) but the “simulated” results, using PowerDVD @32X, are the same !!!

There is another thing that bothers me, but I can’t be sure yet. Have to rescan all the dvds as to have a more concrete view.

But as a hint…
Up to know I’ve found 2 dvds that during Preparing, more .avs files were produced than the amount of cells (chapters). Both of them freeze the simulation (and the first, the famous Condor, has also failed real testing).
Condor produced 82 segments / 26 Cells. As you’ve explained, avs’ might be more than real cells. OK.
But the 2nd, Zatoichi - The Blind Swordsman, produced 367 seg / 13 Cells, and to make it more clear
Here are the Cells
Cell Frame
1 0
2 9256
3 29809
4 51142
5 77064
6 88738
7 104000
8 106743
9 111930
10 142883
11 150397
12 160888
13 165503

the segments that were created were according to the cells up to the 12th

Count LBA NavPack
1 0 1
2 138841 783
3 422964 2503
4 714252 4295
5 1068611 6459
6 1223595 7444
7 1447481 8729
8 1488782 8959
9 1565329 9393
10 1996645 11987
11 2104410 12619
12 2266295 13498
And the rest 355, were created from LBA 2266327 to 2277568, and from NavPack 13499 to13907. Almost every navigation pack was for a new segment !!!
That definitely shouldn’t have happened…

Usually, all my (PAL) movies are Main Movie Shrinked and stripped off other audios (but for the original) + subtitles (but for my language – which is not En).
Some of them are also 70% start and end (titles) compressed (by Shrink).
Condor was not, but Zatoichi was. But then I’ve checked other movies that were also title-compressed, and there were no extra segments or nav error.
Therefore I can’t say that the Shrink process added some bug. Just mentioning it…

And yet another observation.
Opening just the .vob, not as a dvd structure, but as a simple file (without the ifos…) the simulation runs OK !!!
Don’t know how a player works, but that’s seems strange. And I moved elsewhere the ifos/bups just to be sure.

Let’s go back to Condor.
As I’ve already posted, apart from [0045]_CellElapsedTime, there were other parts of navpacks that were different, but I cannot evaluate their significance. I’ll give you some numbers to judge for yourself.
First of all notation:
RB072.CCE_ERROR means full reencoding using v0.72, Mode 1 (CCE) and result…
RB072.CCE_x_RB072.100_OK means full reencoding using v0.72, Mode 1, CCE and the result as input to v0.72, Mode 4 (NoCompression).

So the specimens are

A&nbsp;&nbsp;&nbsp; RB072.CCE_ERROR
B&nbsp;&nbsp;&nbsp; RB072.CCE_x_RB072.100_OK
C&nbsp;&nbsp;&nbsp; RB075.CCE_ERROR
D&nbsp;&nbsp;&nbsp; RB075.CCE_x_RB075.100_OK
E&nbsp;&nbsp;&nbsp; RB076_CCE_ERROR
F&nbsp;&nbsp;&nbsp; RB076.CCE_x_RB076.100_OK
G&nbsp;&nbsp;&nbsp; RB075.CCE_x_RB076.100_OK
H&nbsp;&nbsp;&nbsp; RB076.CCE_x_RB076.100-REDONE _OK (<- !! just to be sure !!)

Scanning the Vobs…
Originl A B C D E F G H
Number of Video Packs 2267323 2077204 2077204 2077112 2077112 2077112 2077112 2077112 2077112
Number of Audio Packs 187090 187090 187090 187090 187090 187090 187090 187090 187090
Number of Subpicture Packs 4268 4268 4268 4268 4268 4268 4268 4268 4268
Number of Navigation Packs 7243 14084 14084 14084 14084 14084 14084 14084 14084
Number of Padding Packs 0 0 0 0 0 0 0 0 0
Number of Unknown Packs 0 0 0 0 0 0 0 0 0
Number of Cells 26 26 26 26 26 26 26 26 26
Number of 00:00:00,00 82 82 26 82 26 26 26 26 26

[offset]_Description A vs B C vs D E vs F B vs D D vs F B vs F A vs C C vs E A vs E F vs G F vs H
Amount_Of_Different_NavPacks 13214 10821 13214 8802 7579 5022 13170 13173 9445 7579 0
NavPack_Count 0 0 0 0 0 0 0 0 0 0 0
[002d]_LBA 5732 1465 5732 5039 24 5021 7579 6510 5021 24 0
[041f]_Vob-ID 0 0 0 0 0 0 0 0 0 0 0
[0422]_Cell-ID 0 0 0 0 0 0 0 0 0 0 0
[0045]_CellElapsedTime 8055 8055 0 0 0 0 0 8055 8055 0 0
[0039]_VobuStartPT 0 0 0 0 0 0 0 0 0 0 0
[003d_VobuEndPT 0 1 1 1 0 1 1 0 1 0 0
[0407]_SCR 13153 7624 13153 4432 4432 1 13169 13169 0 4432 0
[040f]_Vobu_End_Addr_Rel 1302 731 1302 52 48 4 1862 1859 4 48 0
[0413]_VOBU_1st_ref_FEB 3868 2067 3867 372 369 3 4256 4254 3 369 0
[0417]_VOBU_2nd_ref_FEB 4698 2816 4696 479 471 16 5127 5125 4 471 0
[041b]_VOBU_3rd_ref_FEB 4195 2555 4195 526 519 21 4408 4405 4 519 0
[0599]_Offset__audiop_AS1 11555 7581 11555 5499 5496 5 10983 10983 2 5496 0
[0423]_CellElapsedTime 8055 8055 0 0 0 0 0 8055 8055 0 0

Somewhere there are huge diffs, somewhere no
(tricky the table thing... so I attach a zipped xls)
Thanks

[XMEN3]

so version 0.76 is still buggy?
You wrote :
E RB076_CCE_ERROR

but in the table i can see 26 cells and 26 Number of 00:00:00,00

And why so many difference from:
Number of Video Packs 2267323 ---->2077112
Number of Navigation Packs 7243 ---->14084

I was thinking....
how these Nav Packs with Zero Cell Elapsed Time can cause freezes....
Anyway at the beginnin of each cells there's a 00 and this does not cause freeze...or not?

[jdobbs]

That definitely shouldn’t have happened… Not necessarily

I appreciate your testing -- but the question is: It's fixed. So what are we debugging? Am I missing something?

Let me give you an example on segments... if you had a narrative section that showed a lot of stills (say 300 of them) you would get 300 segments, because the still needs an I-Frame.

@xmen

There are supposed to be 26 00000 entries for 26 cells.

Video packs can never match -- they are determined by the encoder.

NAVPACKs depends upon authoring technique -- especially when related to stills.

As for how BCD values can cause freezing -- I don't know. Why a player would use BCD values to make determinations when there is a System Clock Reference only a few bytes away is beyond me.

[XMEN3]

Originally posted by jdobbs
.... So what are we debugging? Am I missing something?


I THINK gm901 found something...
bu the problem with him is (maybe) his Lg drive (not a very good dvd unit as I know)
freezing and skeeping is quite frequent using mastered dvds (mine skeeps even more with pressed dvd)

I think the problems are only media used and drive lens at this point....:confused: :confused:

[gm901]

Tried the new 0.76. Done a full reencoding… Well, didn’t had the chance to “real test” it (I visit the touchy LG every weekend) but the “simulated” results, using PowerDVD @32X, are the same !!!

By saying "are the same" I meant failed as previously.

Next weekend, I shall know the LG's attitude.

[gm901]

Couldn’t wait. The LG is home

No more debugging, just plain testing

A 0.67 to 0.75 [RB full encoding / Mode 1 - CCE]
B 0.76 [RB full encoding / Mode 1 - CCE]
C All versions [RB full encoding / Mode 1 - CCE] -> [RB Mode 4 - No Compression 100%]

Normal Play Fast Forward Backward
A B C A B C A B C
Standalones
Pioneer DV-360 ok ok ok ERR ERR ok ERR ERR ok
LG DV8600 ERR ERR ok ERR ERR ok ERR ERR ok

PC - Players
PowerDVD ok ok ok ERR ERR ok ERR ERR ok
Nero ShowTime ok ok ok ERR ERR ok ERR ERR ok
Notes:
All Players: ERR means freezing AND skipping.
PC Players: Forward speeds are 4x – 32X, Backward 1x – 32x. For some reason backward is more sensitive. Does that mean anything??
Nero escapes very fast the freezing when FF (you have to watch the timer), but when FB not only if freeze the image, but it freezes itself as a program!!

As you see the results are quite eloquent as far as 0.76 is concerned. I’m glad I’ve helped to locate an error that might cause trouble to others’ clock-timers, but unfortunately the fix doesn’t affect the malfunction I’m referring to.
by xmen
...bu the problem with him is (maybe) his Lg drive (not a very good dvd unit as I know)...
...I think the problems are only media used and drive lens at this point...@xmen
The LG has played flawlessly a large number of DV origin authored dvds + transcoded/reencoded movies. It plays perfectly as long as the source is perfect (which makes it a very good choice for a developer though).
I don’t know about other media, but I choose very carefully mine, and most of the time I double-check the burnt (Nero + DVDinfo or Binary Compare). It’s not the media.
Besides, errors that can be reproduced in 2 standalones and 2 sw players could not be specific case/configuration errors.


The vob value @offset [0045] (and [0423]) that is corrected @0.76,might be either informative, deriving from some other part of the Vob where lies the essential data, the data that the players really take into account, or it is indeed itself essential but must be in accordance with something else, for example the ifos (or another value within vob)
And what changes when the players run Fast Forward or Backward, all of them, even the Pioneer, what values are they “looking”. These values might be the problem.
And, don’t forget that Opening just the .vob, not as a dvd structure, but as a simple file (without the ifos…) the simulation runs OK !!!
…And I moved elsewhere the ifos/bups just to be sure.Every vob, doesn’t matter if it’s error, fixed, normal play, FF, FB, whichever speed, plays perfectly.
What a player “looks” when there is only a .vob file and what when there is a full dvd-structure. This is The Question

Maybe someone who has the knowledge to phrase the right question, could post something to a GNU SW (whichever)Player Forum/Net and get the right answer.

I’m not an expert, just a bit above complete ignorance, therefore this is as far as I can get. Maybe even what I’ve just said looks ludicrous to the eyes of a guru.

The only things I know for sure are the above test results.

I guess then, till further notice, I have to stick to the 1½ click mode (or 4 steps, or RBxRB)

Thanks for your patience.

[jdobbs]

I'll take a look at it. There's a table in the NAVPACK specifically used for FF/RW.

[gm901]

Think I’ve got it…

The navpacks with freezing problems have @ VOBU Search Information (VOBU_SRI)
Offset [04f1] to [0541] (next section) values [3fffffff]
while the RB X RB fixed has normal numbers.

Many others navpacks, have also [3fffffff] at offset [0545] to [0595] (previous section)

Is that it ???

[jdobbs]

You may be right, I'll have to see. Those values are legal -- but what I need to assure is that they weren't improperly placed based upon the segmenting. Are you having any trouble in the main movie, or is this just in extras? Extras would make more sense, as most movies would only break at cells in most situations (except where there was null packs inserted by DVD Decrypter because of copy protection - or partial cell references in the IFO).

[gm901]

I do only Main Movies, never extras.
I'll give you a pattern to understand more clear what I see

Offsets [04f1] ->>[0595]
next previous
NAVPACK_a001 F-----------------------
NAVPACK_a002 FF----------------------
NAVPACK_a003 FFF---------------------
NAVPACK_a004 FFFF--------------------
NAVPACK_a005 FFFFF-------------------
NAVPACK_a006 FFFFFF------------------
NAVPACK_a007 FFFFFFF-----------------
NAVPACK_a008 FFFFFFFF----------------
NAVPACK_a009 FFFFFFFFF---------------
NAVPACK_a010 FFFFFFFFFF--------------
NAVPACK_a011 FFFFFFFFFFF-------------
NAVPACK_a012 FFFFFFFFFFFF------------
NAVPACK_a013 ------------FFFFFFFFFFFF <----
NAVPACK_a014 -------------FFFFFFFFFFF
NAVPACK_a015 --------------FFFFFFFFFF
NAVPACK_a016 ---------------FFFFFFFFF
NAVPACK_a017 ----------------FFFFFFFF
NAVPACK_a018 -----------------FFFFFFF
NAVPACK_a019 ------------------FFFFFF
NAVPACK_a020 -------------------FFFFF
NAVPACK_a021 --------------------FFFF
NAVPACK_a022 ---------------------FFF
NAVPACK_a023 ----------------------FF
NAVPACK_a024 -----------------------F

Where
F = [3fffffff], and
- = any normal number


At NAVPACK_a013 is (or was, since v0.76 fixed it) the FALSE 00:00:00.00

it's like a new cell coming...

When you fixed the 00:00:00.00 did you figured out why it was produced? It seems that the same why produces pseudo cells patterns.

[EDIT] Added word FALSE for better sense

[gm901]

see attached xls for details

[jdobbs]

The pattern you are showing is correct for how the table is supposed to be constructed as long as it is within a VOBU. If you see that pattern in a segment that isn't a complete cell -- then I may have made a mistake in how I reconstruct the VOBU.

You don't need to spend any more time on it until I get a chance to look at it and tell you what I've found... I know what I'm looking for.

Again: thanks for the help.

[EDIT] Corrected terminology for clarity

[jdobbs]

Actually looking at the example you've given you say pack 13 has a zero elapsed time -- which implies it is a cell start -- so at least in that example the table is probably correctly constructed.

But I'm going to go through the routine anyway to be sure.

[jdobbs]

Ok, more confusion. The file you posted was done with v0.69... that doesn't help as that's not current and doesn't have the fix I put in 0.76. I'd need output from v0.76.

[jdobbs]

Originally posted by gm901
Think I’ve got it…

The navpacks with freezing problems have @ VOBU Search Information (VOBU_SRI)
Offset [04f1] to [0541] (next section) values [3fffffff]
while the RB X RB fixed has normal numbers.

Many others navpacks, have also [3fffffff] at offset [0545] to [0595] (previous section)

Is that it ??? I just looked at the code for inserting these and it appears to be correct as it is VOBU based and only updates on a per-VOBID basis. Can you elaborate on what you are saying here? The values are different if you run it through DVD-RB a second time with the no compression? Also -- please keep the discussion focused only on v0.76 ---> old information from obsolete versions has no value for me.

Thanks.

[Note]: The 3FFFFFFF is an indicator that there is no VOBU within the cell for the specified time unit in the appropriate direction.

[gm901]

Send you 2 xls.

1st the 076_CCE_ERROR and
2nd the RB_x_RB_OK
See them side by side, there are beautiful diffs (as for understanding what I'm talking about)

On each colored row there is a comment.

When I attach a file, I can't see it right away, but only after a few hours (!!). So I don't know if I sent it ...

Please let me know if you can dnld it

BTW, for all the extracts, a big thanks to the guy who not only has developed VobBlanker and PgcDemux (which I didn't had the chance to use as programs yet), but also has the courtesy to publish his source code (which I used as a basis to learn and to produce specific info results, since I didn't know a thing about IFOs/VOBs).
I didn't even knew that using VobEdit you have to check some checkboxes down there, in order to view more offsets. I found that out because trying to fix the error, in one of my tests, I used VobBlanker to cut a few LBAs and it produced a perfect result for that cell (fixing the subsequent navpacks). Then I looked at the code and I discovered that he putchared other offsets (VOBU SRI), significant but unknown to me.
And bear in mind that I'm not even a programmer.It's hell!!!

Hope that helps, If you need anything else let me know

[gm901]

And the 2nd RB_x_RB_OK

[jptheripper]

probably too little to late

but i came across this nav pack extractor program (from one of dvd remake's supporters)

might be useful

http://www.cdr-zone.com/forum/viewtopic.php?t=1025

[gm901]

probably too little to late
@jptheripper
Thank you, indeed, but now I got fully armed...

[jptheripper]

yeah i figured, thanx for all the great troubleshooting btw

[jdobbs]

I found what was causing this. I'll fix it and include it in v0.77.

@gm901

Again, great data collection and description of the problem.