The 'Wish List' [merged]

[Sharc]

Filter editor:
If I understand correctly, the filters are not applied to menus.
I would suggest to introduce a filter prefix (m) for filters that should be applied to the menus, e.g. for better compressability. Even better, if a special matrix for menus could be defined.

[jdobbs]

Hey... we're thinking alike. I've recently added the "M:" prefix for the next version. :)

[Sharc]

That's good news :cool:

Now I am curious if
- Matrix selection will follow the changes of the bitrates done by means of the editor
- Q-factor will be re-estimated in OPV mode after blanking of segments with the editor
in the coming release....

[Rippraff]

As it comes up again (http://forum.doom9.org/showthread.php?t=124713), a feature request:


To have the ability in the segment editor to blank/force encode on a VTS basis. Currently you have do do this for all segments by hand.
For these Letterbox/WS versions:
To have the ability to choose what the main movie is.
The second one isn't that important as the first one would be a workaround for this. ;)
It wouldn't work for 'movie only' mode, though.

Cu Rippraff

[SpazzHH]

And at the risk of sounding greedy after all the great new features lately,:rolleyes: was just wondering again about being able to use different encoders on the same project. It would just be so sweet to be able to choose CCE for all the progressive content, and have HC or Procoder handle all the interlaced stuff.

[Boulder]

Regarding ColorMatrix in DVD-RB: as there's also colorimetrics FCC and SMPTE 240M, you should also use the d2v parameter when adding the line into the scripts. This will ensure that the correct conversion is done in every case.

By the way, how does DVD-RB determine if the line is needed, that is, what colorimetry values in the d2v file are considered as Rec.709?

[FredThompson]

Huh? Which d2v parameter? What's a sample call that matches your comment?

[Boulder]

If you use mode="rec.601->rec.709" and d2v="path\clip.d2v" and the colorimetry information in the d2v file is something else than rec.709, the source colorimetry in the mode is adjusted accordingly. Then the conversion is correct every time.

[jdobbs]

Regarding ColorMatrix in DVD-RB: as there's also colorimetrics FCC and SMPTE 240M, you should also use the d2v parameter when adding the line into the scripts. This will ensure that the correct conversion is done in every case.

By the way, how does DVD-RB determine if the line is needed, that is, what colorimetry values in the d2v file are considered as Rec.709?I've never seen a DVD that isn't either Rec.601 or Rec.709. SMPTE 240M would probably imply an HD source -- which DVD-RB wouldn't expect to see as input (since it backs up standard DVDs) -- but is equivalent to Rec.709. FCC is considered the same as Rec.601 because the difference (as I understand it) is insignificant.

The decision is made based upon the matrix_coefficients setting in the stream. If none is specified, then (per spec) Rec.709 is assumed.

[jdobbs]

Huh? Which d2v parameter? What's a sample call that matches your comment?Here's a line from a D2V:900 1 0 956416 1 1 72 73 d0 f1 f2 e3 f0 f1 e2 f3 f0 e1The bold value represents the colorimetry information for that sequence.

Here are the definitions of the value:

1 ITU-R BT.709 I709
4 FCC (almost the same as ITU-R BT.601) FCC
5 ITU-R BT.470-2 (exactly the same as ITU-R BT.601)
(recommendation BT.601 is an update BT.470-2) I470
6 SMPTE 170M (exactly the same as ITU-R BT.601) S170
7 SMPTE 240M (almost the same as ITU-R BT.709) S240

[Boulder]

I've never seen a DVD that isn't either Rec.601 or Rec.709. SMPTE 240M would probably imply an HD source -- which DVD-RB wouldn't expect to see as input (since it backs up standard DVDs) -- but is equivalent to Rec.709. FCC is considered the same as Rec.601 because the difference (as I understand it) is insignificant.

The decision is made based upon the matrix_coefficients setting in the stream. If none is specified, then (per spec) Rec.709 is assumed.OK..I wasn't exactly sure whether FCC and SMPTE 240M were almost the same as Rec.601 and Rec.709 respectively.

I've seen one PAL DVD with SMPTE 240M coeffs but unfortunately I don't remember which one it is in my collection. I somehow recall it was a BBC series so I might just try and find it and see what the difference between accurate conversion and rec.601->rec.709 is in that case.

[Boulder]

I found a small glitch in the ColorMatrix feature. If the colorimetry value is '2' in the d2v file, ColorMatrix is added but it shouldn't be. In that case, the colorimetry is not defined but it is assumed that it is Rec.709. I think the information is buried in the ColorMatrix thread, but I just tested it and the results showed that in case of colorimetry value of 2, no ColorMatrix line is needed.

[Boulder]

I've gone one more feature request: in HC mode, the option to put the encoder exe files in the temp directory would be greatly appreciated.

At the moment I've got DVD-RB installed on my Windows drive which has ~300MB space left. When encoding two long segments simultaneously, the HC temp files take a huge amount of space so it would really be nice if the temporary encoder exes were copied to the temp directory.

[Rippraff]

What do you mean by temp directory, hopefully the working path in RB?

Cu Rippraff

[jdobbs]

I found a small glitch in the ColorMatrix feature. If the colorimetry value is '2' in the d2v file, ColorMatrix is added but it shouldn't be. In that case, the colorimetry is not defined but it is assumed that it is Rec.709. I think the information is buried in the ColorMatrix thread, but I just tested it and the results showed that in case of colorimetry value of 2, no ColorMatrix line is needed.I was under the assumption that "2" is an illegal value and should never occur.

[Boulder]

What do you mean by temp directory, hopefully the working path in RB?

Cu RippraffBy the temp directory I mean the Windows temp directory which you can set yourself via the System applet in Control Panel.

@jdobbs: at least the DVB transmissions here have '2' as the colorimetry value. DGIndex only shows it as Unknown.

EDIT: here's the table from the ColorMatrix docs:

0 forbidden
1 ITU-R BT.709
2 Unspecified Video (unknown)
3 reserved
4 FCC
5 ITU-R BT.470-2 (exactly the same as ITU-R BT.601)
6 SMPTE 170M (exactly the same as ITU-R BT.601)
7 SMPTE 240M

[Rippraff]

By the temp directory I mean the Windows temp directory which you can set yourself via the System applet in Control Panel.
I'ld prefer to have everything stored in the working path as in my eyes users will pick the drive with the largest free space for their working folder.

Cu Rippraff

[Boulder]

Well, that's one possible place too.

I also noticed that the temporary encoder folders are not removed after the process has been stopped so the huge dbs files will remain in the "tempenc" folders.

[jdobbs]

I'll change it to the working directory for the next release. People already expect a lot of size there. I'll also read matrix_coefficients=2 as unknown (implying Rec.709).

[Snarko]

How about OPV/CQ runs for CCE, HCEnc (I'm really interested in HCEnc here) using the matrices specified in the advanced settings? Possible to add to DVD-RB itself, or should I wait till RB-Opt works with HCCenc properly? Thanks.

[chainring]

How about OPV/CQ runs for CCE, HCEnc (I'm really interested in HCEnc here) using the matrices specified in the advanced settings? Possible to add to DVD-RB itself, or should I wait till RB-Opt works with HCCenc properly? Thanks.
You may want to read some of the threads that deal with applying matrices to an OPV/CQ encode. IIRC, doing so can cause the prediction phase to crater, thus making it unreliable.

Filters during OPV/CQ, yes.
Matrices during OPV/CQ, no.

[jdobbs]

I'm looking at use of a single matrix for OPV as an option as opposed to one that changes based upon resulting bitrate. But, true to form, my first encode oversized by quite a bit. I'm still not sure why this happens... you'd think that predicting with the same single matrix would remain accurate... but it doesn't seem to be the case.

[ricoman]

I know this is minor but everytime I update RBpro, it defaults to the multple encoder setting and of course I forget. Since most of us (I believe) do not have duo core systems, could the default be changed. This is the third time I have gone to bed while running RB/HC and when I get up in the morning it is still only 50% processed. Then I have to leave for work with the computer still processing. When it is set to multiple encoder and you don't have duo core, it takes more than twice as long to process 8 hrs. +, normally it takes me less than 4 hrs. Thanks for your consideration. Maybe a poll can be taken to see how many subscribers have duo core machines.

[jdobbs]

That probably means your system is somehow misconfigured. There is an environment variable called "NUMBER_OF_PROCESSORS" that DVD-RB looks at to see how many processors you have. In your case it seems it may be wrong. If you only have one processor, it should be set to one, and DVD-RB will only run one process.

You can also say "No" during the installation when DVD-RB asks whether to overwrite your REBUILDER.INI file -- and all your old settings will be kept.

You can look at "NUMBER_OF_PROCESSORS" by right clicking on "My Computer", selecting "Properties", and then choosing "Environment Variables" under the "Advanced" tab.

[Rippraff]

@ricoman

This has already been answered (http://forum.doom9.org/showthread.php?p=975288#post975288) more than a month ago...

Cu Rippraff

[ricoman]

@ricoman

This has already been answered (http://forum.doom9.org/showthread.php?p=975288#post975288) more than a month ago...

Cu Rippraff

That was a question and the solution didn't work. This is the Wish List thread and this is my wish.

Thank you jdobbs, I'll give it at try.

[ricoman]

You can look at "NUMBER_OF_PROCESSORS" by right clicking on "My Computer", selecting "Properties", and then choosing "Environment Variables" under the "Advanced" tab.

You are correct, it says 2, can I just edit this or with that screw something up. I do have hyperthreading, would this be considered a 2nd processor to RB? Also, your assessment was right, I alway overwrite the ini. file. Thanks for the help.

[Boulder]

Windows considers HT-capable processor as 2 different processors.

However, using the multiple encoders option on a HT processor should actually make the encoding faster, not slower as in your case.

[jdobbs]

It's possible the hyperthreading may be interpreted that way. But if it were correct and your system is properly configured -- you should also see better encoding times with multiple processes than with single ones.

I'm not sure where/how that environment varible gets set... so I'm not positive whether changing it will stay consistent, or it will go back the next time you reboot.

[jdobbs]

That is definitely confusing. Even on a single processor computer (e.g. my AMD XP 3200+) my tests with multiple process encoding don't show a significant slowdown. It just doesn't run any faster either.


How are you situated for memory? If the two instances makes your computer start using virtual memory I can see how that could slow it down.

[ricoman]

Hyperthreading is enabled. I have 1gig ram.
My system is P4 3.0 WD 320 & 160 SATA drives w/ XP pro. I defrag regularly. It normally takes 4 1/2 +/- hrs. for RB pro using HC, though HC 21 sped it up to approx. 3 hrs. 50 with my last run. However, the last 3 time (he said with embarrassment ;>) I forgot to uncheck "multiple processor" it took 8-9 hrs. to process.
Has no one else reported this problem?

[SpazzHH]

I use to have exactly the same setup. Average disc with one instance of HC - 3 hrs. Average disc with two instances of HC - 2 hrs. 45 min.

[Boulder]

Just for the heck of it, run DVD-RB with 2 encoder processes and then see what Task Manager (ctrl+alt+del) says about the processes, is the CPU usage something like less than 40% for both of the encoder processes?

[laserfan]

My system is P4 3.0 ... It normally takes 4 1/2 +/- hrs. for RB pro using HC, though HC 21 sped it up to approx. 3 hrs. 50 with my last run. However, the last 3 time (he said with embarrassment ;>) I forgot to uncheck "multiple processor" it took 8-9 hrs. to process.
Ouch, something is wrong there for sure. Mine's a 3.2GHz P4 and my last project went 7m Prepare, 118m Encode, 14m Rebuild so just over two hours and that is typical.

The Env variable says '2 processors' and latest RB-Pro runs two instances of HC.

I remember an earlier version of (RB-Pro? HC? Both?) where two instances was noticeably slower, but with the latest setup it seems fast so I've left it alone, despite that initially the two instances of HC alarmed me... :eek:

[rack04]

Jdobbs, what are your thoughts on implementing a "Two Click Mode"? The first click is the "Prepare" and the second click is the "Encode and Rebuild". This way the user is able to run the "Prepare", blank video segments using the "Video Segment Viewer/Editor", enable "Shutdown on Rebuild Completion", and lastly run the "Encode and Rebuild".

[rendez2k]

Jdobbs, what are your thoughts on implementing a "Two Click Mode"? The first click is the "Prepare" and the second click is the "Encode and Rebuild". This way the user is able to run the "Prepare", blank video segments using the "Video Segment Viewer/Editor", enable "Shutdown on Rebuild Completion", and lastly run the "Encode and Rebuild".

Its there already - just hit Encode after the prepare stage!

[~bT~]

Its there already - just hit Encode after the prepare stage!
U mean Rebuild?

[rendez2k]

Yup, thats the one! Sorry!

[rack04]

Its there already - just hit Encode after the prepare stage!

Actually the whole purpose of me suggesting "Two Click Mode" is so that i can use the Video Segment Viewer/Editor to blank video segments and then continue to "Encode" and "Rebuild" in one step. That way after the "Encode" the "Rebuild" would automatically start and then shutdown when complete. For example last night before I went to bed I started the "Prepare" in "3 Click Mode". After the "Prepare" was completed I blanked the video segments I didn't want using the Video Segment Viewer/Editor. Once I was done blanking I clicked "Encode" and went to bed. When I woke up this morning the "Encode" was complete and the computer was still powered on. I had to click "Rebuild" and once "Rebuild was complete it automatically shutdown. Does this make sense?

U mean Rebuild?

Ok maybe that's what I'm missing. I'll try this next time I run DVD-RB.

[Rippraff]

As already mentioned, this feature was introduced in October 2005 (http://forum.doom9.org/showthread.php?p=720550#post720550). ;)

Cu Rippraff

[rack04]

As already mentioned, this feature was introduced in October 2005 (http://forum.doom9.org/showthread.php?p=720550#post720550). ;)

Cu Rippraff

Thanks. Sorry for my confusion.

[ron spencer]

was PAL-NTSC and vicey versa discussed as a feature?

[Video Dude]

When I use batch mode in v1.25.0 with the Shutdown option enabled, DVD-RB does not shut the computer off when finished with the batch. The program remains open. Shutdown works for single projects. Is Shutdown supposed to work in batch mode?

[rack04]

When I use batch mode in v1.25.0 with the Shutdown option enabled, DVD-RB does not shut the computer off when finished with the batch. The program remains open. Shutdown works for single projects. Is Shutdown supposed to work in batch mode?

Are you using "Shutdown at Batch Completion" under File?

[Video Dude]

I did not see the shutdown under File. I was using the one under Mode.

:thanks:

[blutach]

I know this has been asked before, but is there a plan to encode VIDEO_TS.VOB as well as other menu VOBs?

Apologies if this is already implemented somehow, but I can't figure out where. For now, I am re-authoring the disk so the menus are not in VMG.

Regards

[Boulder]

I'd like to ask for an improvement in the multiple encoders setting. Currently the encoding process leaps way back when you need to stop it and restart it at a later time.

Last time I lost about 1.5hrs work as the first encoder instance was working on a long segment at a slow speed and the second encoder had done many small segments in that time. When I had to stop the process and restart it later, the first instance began encoding the long segment and the second instance began encoding the next one after that.

[blutach]

There's a manual way round that Boulder, by using the Encode Progress flag for each segment. I know it is picky but it works.

Regards

[jdobbs]

You have to be careful with that, though. If you had situation in which you are encoding 1, 2, 3, and 4 -- and #2 is hasn't completed (although 3 and 4 has) because it is very long -- there's no way to skip 3 and 4 when you restart... because the encode progress has to be set back to 2...

The easiest way to do that scenario is to cut-and-paste the ECL information from "2" into an independent .ECL file and encode it directly from CCE... and then set the encode progress to 4.

[tom942]

Just a little thing

Could you fix that when you use NaN's decoder, instead of unknown, says something like "NaN's 1.1.1" or something similar. I know, it falls in what you call cosmetic changes :).