vobu min len...

[Sir Didymus]

Jdobbs,
I really do not want you to spend all the time of your life on silly formal verifications against the compliancy of DVD-RB with some ISO13818 stuff...

:scared:

To say the truth I have been very dubtful on the opportunity of opening a new thread on this type of subjects...

Anyway, LOOKING DEEPLY at the vobs generated by the rebuilder, I noticed that it happens (again quite frequently...) that the vobu lenght is too short.

Since each vob unit is assumed to represent a presentation period of at least 0.4 seconds, do you think this could have an impact on the dropout issue ?

I have written a very simple program (based on the scr of Jsoto) to show the problem clearly.

It is attached as a zip archive in the second post...

All the best,
SD

[Sir Didymus]

Ok. The test program is in attachment.

1. Thanks to Jsoto for providing scr.cpp. I used the same program as a starter... (by the way I know he is now very busy in writing the code of VobBlanker...; just tested the beta release for stripping contents in the title menus...; it works very well...).

2. Apologise in advance if the present contribution will result ininfluent...

3. Just reasoning on the matter, a too short vobu time means that the decoder should do the job of fetching the stream content into its STD buffer more quickly than in normal situations... Right ?

Cheers,
SD

[jdobbs]

Hmm... I wouldn't think it a likely candidate... but it doesn't hurt to find out. The only time that could happen would be when there is a CCE recognized scene change that would make a GOP smaller than 12 frames. A good test would be for one of the folks who get the problem to turn automatic scene detection off in the ECL created by DVD-RB. That would keep a fixed GOP size. If the dropouts stopped, we would be on the right track.

Have you run the test against any commercial DVDs to see if it identifies runt VOBUs there as well? I'm just wondering if this is strictly adhered to.

[robot1]

Just one test.
Original disc (The last Samurai), first VOB - no vulen errors
DVD-RB 79 errors, (one time it found Vobu_len=80ms)
Scenarist authored disk - no vulen errors.

[jdobbs]

Interesting. I hope one of the "dropout" people tries it without scene change.

[Sir Didymus]

Originally posted by jdobbs
Hmm... I wouldn't think it a likely candidate... but it doesn't hurt to find out. The only time that could happen would be when there is a CCE recognized scene change that would make a GOP smaller than 12 frames. A good test would be for one of the folks who get the problem to turn automatic scene detection off in the ECL created by DVD-RB. That would keep a fixed GOP size. If the dropouts stopped, we would be on the right track.

Have you run the test against any commercial DVDs to see if it identifies runt VOBUs there as well? I'm just wondering if this is strictly adhered to.

Excellent idea...
This way people experiencing dropouts should be able to gather some evidence on the impact of this vulen infringement respect to the dropout issue...

Regarding the compliance of commercial titles to this 0.4s rule, I don't know by sure...

Just reading the ISO documents it seems that each rule is mandatory...
On the other hand, looking at "real commercial titles", it happens that other type of errors are most time present...

In the titles I have now on my HD (all PAL, R2):
- ALI
- O brother where art thou ?
- Open Range
- Pirates of the Caribbean

No one of the vobs is showing vulen errors, so (at least on these titles) it seems that this rule is strictly obeyed...

Let's see if some news on the matter will be reported by other kind people...

Cheers,
SD

[jdobbs]

Yeah, most of the encoders and authoring engines ignore at least a few of the specs called out in the standards -- because knowing how players work they know it will never happen and it could be a pain to implement. It could be I shouldn't have ignored this one (frankly, I didn't do it purposefully -- I just overlooked it).

I'm going to be out of town this weekend, but I'll modify the code on Monday or Tuesday. Even it it isn't causing any visible problems it is something that needs to be fixed. You never know when you correct one of these inconsistencies -- some rarely reported problem falls off the radar screen -- and when you're lucky, a big one.

[Sir Didymus]

I am crossing the fingers.
This time no pressure from my side...
Let's wait for some reports from other testers...
And enjoy your w/e [I hope you leave for fun]...

By the way me too will be abroad on next Sunday;
for me it is because of the work...

Grrr... :devil:

Hopefully it happens just few times per year that they drain time to me also on Saturday or Sunday...

Grrr...

[eriksen76]

[QUOTE]Originally posted by jdobbs
[B]A good test would be for one of the folks who get the problem to turn automatic scene detection off in the ECL created by DVD-RB. That would keep a fixed GOP size. If the dropouts stopped, we would be on the right track.

How do I turn automatic scene detection off? I will try a encode then and post the results.

/Julius

[Sir Didymus]

Hi, Julius,

Get a look at the audio and video dropout thread...

Indeed, please consider that, up to now, one user reported this vobu min len infringement as ininfluent respect to the droput issue...

Cheers,
SD

[robot1]

Originally posted by eriksen76
How do I turn automatic scene detection off? I will try a encode then and post the results.
After "prepare", Change in Rebuilder.ecl all lines
fix_gop_length=0
with
fix_gop_length=1

Save and run encode phase.

[Trahald]

This may have an effect if the last gop of a cell is <0.4sec (most compilers just add it to the preceding vobu) at least if the next cell is connected seamlessly. i didnt have any reference material to check what rb does in that scenario tho .. *it may already be handled*

<edit> ok .. did a quick compile and the last vobu of a vob/cell that had a seamless connection to the next vob/cell was created with 3 frames ( .1 second )... which would mean that turning on gop size restriction would only reduce the instances.. not elliminate them

[erdoke]

Originally posted by Trahald
This may have an effect if the last gop of a cell is <0.4sec (most compilers just add it to the preceding vobu) at least if the next cell is connected seamlessly.

Hmm. If I remember correctly, many of the dropout issue reports describing it as mainly occuring at chapter points.:confused:

[Sir Didymus]

Originally posted by Trahald
This may have an effect if the last gop of a cell is <0.4sec (most compilers just add it to the preceding vobu) at least if the next cell is connected seamlessly. i didnt have any reference material to check what rb does in that scenario tho .. *it may already be handled*

<edit> ok .. did a quick compile and the last vobu of a vob/cell that had a seamless connection to the next vob/cell was created with 3 frames ( .1 second )... which would mean that turning on gop size restriction would only reduce the instances.. not elliminate them

Agreed, totally agreed...

But please consider that users suffering from the issue have clearily reported that the DROPOUTS ARE NOT RELATED [OR AT LEAST NOT ONLY RELATED] with the cell changes (see next post to Erdoke)...

Anyway in such cases the usage of the little verification with "vulen.exe" would still report the infringements...

I hope it is clear that the test proposed by Jdobbs is just finalised to understand if the timing infringement has relevance or not with the dropout problem; it is not intended (I hope...) as a stable fix for this infringement... As everybody may understand, in general, there are many good reasons for leaving the automated scene detection, in CCE, activated [as it is actually done, with fix_gop_length=0].

Cheers,
SD

[Sir Didymus]

Originally posted by erdoke
Hmm. If I remember correctly, many of the dropout issue reports describing it as mainly occuring at chapter points.:confused:

Hi Erdoke! :)

No. I think your memory has some leaks [respectfully speaking]...
But nothing relevant to worry about... By sure my memory is even worse ;) ...

Look at the "official" droput thread, especially from page 6:

http://forum.doom9.org/showthread.php?s=&threadid=75848&perpage=20&pagenumber=6

Anyway, maybe I am wrong, but just a single user has reported a clear feedback until now...

It seems that last releases of rebuilder [especially 0.62, that solved some majour troubles with QuEnc], has reduced the set of the "dropout people" to a very limited size...

Cheers,
SD

[erdoke]

Originally posted by Sir Didymus
Hi Erdoke! :)

No. I think your memory has some leaks [respectfully speaking]...
But nothing relevant to worry about... By sure my memory is even worse ;) ...

Look at the "official" droput thread, especially from page 6:

http://forum.doom9.org/showthread.php?s=&threadid=75848&perpage=20&pagenumber=6


Yep, I refreshed my memory and revised my opinion.:D

THX SD!

I think that version 0.63 of DVD Rebuilder will be pretty good build.
People even more happy are on the way.;)

[Trahald]

@Sir Didymus

Well, yes. I didnt want one of the stutter sufferers to still see a stutter and think that restricting the size wasnt working. They should be able to see an improvement in stutters, but possibly not an ellimination.

[Sir Didymus]

@Trahald

Sorry for the late comment on your post.

Well, I see your argument is totally true and agreed, since it is based on a very strict logic...

Maybe we can say that the test proposed should at least allow to verify its effects on all of the title positions, EXCEPT THAN ON THE CELL CHANGES...

I have to say that the topic we are discussing seems to be of very limited interest for people suffering from stuttes and dropouts [just a single user so far has reported a result for the test proposed by jdobbs...]...

It is by sure an excellent situation, as it indicates that people having these troubles are very very very rare... :D

[wmansir]

Sir Didymus,

I ran your program on one of the VOB files that experienced stutters (reported in the Star Wars stutter thread). It did report 30 or so instances, but I don't know how to convert LBA address to video location so I can see if they coincide with the stuttering. Do you have a quick way to check that, or is it possible to give a frame # for each instance?

[Sir Didymus]

Ma che bella domanda! (I mean, what a nice question...)...

Well, it is possible, with the lba address and vobedit, to jump at the place of the infringement [using the button at the bottom of the main window].

When you click on the navpak at that address [left panel] you see [on the right panel] a lot of data on the navpack.

Vobid is at address 41f
Cell id is at address 422

Immediately after (address 423) there is a time indication RELATIVE TO THE CELL START, that is the cell elapsed time...

If you want, it is easy to modify the little vulen program in order to show these info...

But frankly, I think the easiest way to verify if there are any relationship between this formal infringement and the dropout issue, is simply to remove the infringement, to burn the title on a RW, and see if the dropouts are still present. It takes some time, but it provides definitive answers.

To do this it is sufficient to reencode one or all of the movie cells, changing in the file Rebuilder.ecl the line

fix_gop_length=0
with
fix_gop_length=1

This will have effect for all of the cell positions EXCEPT THAN THE ONES AT THE CELL BOUNDARIES.

If you are experiencing dropouts (as I understand), your testing on the matter will be very appreciated...

Up to now one single user reported no impact (I mean all dropouts still presents)...

All the best,
SD