437 crashing

[rontop]

If you still have a copy of my Trimmed.tp (around 300MB), it will crash VRD 437 if you try to open it. It used to be that VRD would just refuse to open it, because the good frames were too far into the file.

Ron

[DanR]

Hi Ron,

OK, found and fixed the problem. 437 will now search further into the file than previous versions (settable with a registry parameter). However, we messed up an internal consistency check for certain kinds of bad data in the transport stream. Your Trimmed.tp file now opens quite nicely.

I'll post 438 with a fix as soon as we hear back from Litz.

[rontop]

This is great news. Thanks. I do have to ask though -- will I have to change this new registry setting to get files like this to open? If so:

1) What is the name of the registry key.
2) What setting should I use.
3) (Sorry in advance) Why do we have yet another setting that we have to know about, understand, and set? I assume that you are still working toward the day when VRD will indicate its progress and maybe allow the Open to be aborted?

Ron

[DanR]

will I have to change this new registry setting to get files like this to openNo, your file will now open with the new setting.

In case you are interested, the new setting is: HKEY_CURRENT_USER\Software\DRD Systems\VideoReDo-Plus\AdvancedStream\MaxTSSearchPackets the old value, which was hardcoded, was 50,000 (decimal) packets or 9.4 MB. The new default is 100,000 packets or 18.8 MB.

3) 99.9% of our users never have to change the default settings and we continually try to make things as automatic as possible. Many users run VideoReDo in a batch mode using our COM interface. We try to keep the behavior the same in both modes.

[rontop]

Thanks for the info. I love knowing that I am in the top 0.1% :) I have to change the Transport Stream Output - Output Mux Rate setting because of the "audio packet without a syncword" problem that the sampling introduces (you can change this behavior, if you like.) If I set the sampling to 8, for instance, I run into it a lot. If I set the sampling to 1 or 2, it happens less often. When setting it to a 1 still causes the error, I change to a Manual setting of 20 Mbps even though I hate having a manual setting in there.

I do have MaxTSReadBytesForSync set to a huge number, and one other registry value that I can't remember now. Oh, and Abort After n Buffer Underflows is set really large.

Ron

[litz]

Replied in the other thread (could not reproduce the problem I had had, now), so probably OK to let 438 out the door ...

Edit: OTOH, see the other two threads of more issues I've found ...

- litz

[DanR]

439 is posted, but does not address your other issues.