Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th January 2006, 02:24   #1321  |  Link
berrinam
Registered User
 
berrinam's Avatar
 
Join Date: Apr 2005
Posts: 1,740
0.2.3.2032 18 Jan 2006
Bugfix: Scripts served by scriptserver now work (that's a good thing )
Bugfix: Fixed problems with comma locales in string->double conversions in source detection.

Is there a way to specify the locale across the entire GUI or do some other solution, as this problem keeps coming up?
berrinam is offline   Reply With Quote
Old 18th January 2006, 04:03   #1322  |  Link
berrinam
Registered User
 
berrinam's Avatar
 
Join Date: Apr 2005
Posts: 1,740
0.2.3.2033 18 Jan 2006
Bugfix: AviSynth errors are now displayed in the preview window (changes made by looking at AVIFile code).

EDIT: This code handles YV12 input differently from other input (because YV12 needs to be converted, whereas DIB is fine). As a result, it is possible to tell whether the AviSynth output is YV12, and if it isn't, warn the user that it won't work. What I'm saying is that it is possible for MeGUI to catch the 'unsupported input colorspace' error before it occurs. It could even suggest adding converttoyv12 if it isn't actually an error.

Last edited by berrinam; 18th January 2006 at 04:10.
berrinam is offline   Reply With Quote
Old 18th January 2006, 04:23   #1323  |  Link
Richard Berg
developer wannabe
 
Richard Berg's Avatar
 
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
Quote:
Is there a way to specify the locale across the entire GUI or do some other solution, as this problem keeps coming up?
Not really. Programmers should know that anytime you do string manipulation, you need to decide whether current locale vs. invariant locale is appropriate. This is very easy compared with the problems I encounter with localized builds & non-unicode encodings
Richard Berg is offline   Reply With Quote
Old 18th January 2006, 09:30   #1324  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
Quote:
you need to decide whether current locale vs. invariant locale is appropriate.
Invariant doesn't seem to cut it.. I first tried that in the getFrameNumber methods in the video encoders.. it still didn't work on those comma locales, so I forced it to en-us.
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline   Reply With Quote
Old 18th January 2006, 11:42   #1325  |  Link
dimzon
BeHappy/MeGUI developer
 
dimzon's Avatar
 
Join Date: Oct 2003
Location: Moscow, Russia
Posts: 1,727
Dear Doom9
Can you answer on this post http://forum.doom9.org/showthread.ph...907#post769907
dimzon is offline   Reply With Quote
Old 18th January 2006, 11:50   #1326  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
Quote:
Isn't existing technology implementation (BeHappy) enought to be sure?
Looking at your configuration template I'd say yes.. as long as you can cover everything in the BESweet configuration groupbox we won't have any problems.

Quote:
I'm a really sorry, I do not understand You at all! Command line is _private_ implementation detail. You does not like about Job can create it's own encoder but You hold specific information for concrete encoder implementation!
Make that a "currently a job holds the commandline". However, that is going to change.. in fact as it is now it doesn't make a whole lot of sense and the commandline should only be generated from the settings when encoding is to take place. That'll even permit an encoder change at the last moment (for instance mencoder <-> x264). I already had it like that in the past.. there was a reason why I changed it but I can't quite remember right now why it was.. just hoping I won't break anything if I go back to the "encoder generates commandline" approach.
As it is now, it's already possible that you change the path of the encoder after creating the job and you can still encode (except for dgindex.. it still includes the binary name in the commandline).. so we're already halfway there.. but the other half mile is to be walked...
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline   Reply With Quote
Old 18th January 2006, 11:55   #1327  |  Link
dimzon
BeHappy/MeGUI developer
 
dimzon's Avatar
 
Join Date: Oct 2003
Location: Moscow, Russia
Posts: 1,727
Quote:
Originally Posted by Doom9
Looking at your configuration template I'd say yes.. as long as you can cover everything in the BESweet configuration groupbox we won't have any problems.
Does it mean I can remove BeSweet-related code?

Quote:
Originally Posted by Doom9
in fact as it is now it doesn't make a whole lot of sense and the commandline should only be generated from the settings when encoding is to take place
Does it mean we does'nt need "Show commandline" option @ configuration dialog?
dimzon is offline   Reply With Quote
Old 18th January 2006, 12:00   #1328  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
Quote:
Does it mean I can remove BeSweet-related code?
No, as I said.. keep all the code there.. I'll remove it in time. Just don't bother with anything BeSweet related.. write your own dialogs and your own encoder derived from AudioEncoder.

Quote:
Does it mean we does'nt need "Show commandline" option @ configuration dialog?
No, I think that's still good.. it also helps in development (you immediately see what the commandline will be.. the only changes that can come are bitrate related when the bitrate is being automatically calculated).
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline   Reply With Quote
Old 18th January 2006, 12:00   #1329  |  Link
dimzon
BeHappy/MeGUI developer
 
dimzon's Avatar
 
Join Date: Oct 2003
Location: Moscow, Russia
Posts: 1,727
Audio via AviSynth disadvantage
Current implementation (reading audio data via VfW) can't provide detailed information about script error.
Workaround: to work with avisynth.dll directly (without VfW). Unfortunally it's impossible bcz AviSynth API can be accessed only via C++. I'm planning to write wrapper in Managed C++ to provide full power of AviSynth functionality to .NET world...
dimzon is offline   Reply With Quote
Old 18th January 2006, 12:09   #1330  |  Link
dimzon
BeHappy/MeGUI developer
 
dimzon's Avatar
 
Join Date: Oct 2003
Location: Moscow, Russia
Posts: 1,727
Quote:
Originally Posted by Doom9
No, as I said.. keep all the code there.. I'll remove it in time.
As you can see I'm altering AudioSettings class (adding new items in emunerations etc). So I cant "Just do not touch BeSweet code" bcz it's break compilation. There are 2 way - perform appropriate adjustments in BeSeet-related code or just remove it @ forget it...

Quote:
Originally Posted by Doom9
No, I think that's still good.. it also helps in development (you immediately see what the commandline will be.. the only changes that can come are bitrate related when the bitrate is being automatically calculated).
Does it mean I must invoke command-line creation logic twice (ones in audioSettingsDialog, ones before encoding startup)?
So does it mean I can do "getCommandLine()" - a virtual method for AudioSettings?
dimzon is offline   Reply With Quote
Old 18th January 2006, 12:50   #1331  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
Quote:
Current implementation (reading audio data via VfW) can't provide detailed information about script error.
Neither can any of the video tools.. that's why if I can't open the script via VfW, I do not allow encoding to proceed. I think your audio encoder should do something similar.. open it, see if the properties make sense, and if not, abort and ask the user to play the script in a media player.

Quote:
As you can see I'm altering AudioSettings class (adding new items in emunerations etc). So I cant "Just do not touch BeSweet code" bcz it's break compilation.
So use the variables you're going to add for the avisynth part, and leave the other ones in.. that means a bloated AudioSettings class, but that can be streamlined when we dump the besweet part.

Quote:
Does it mean I must invoke command-line creation logic twice (ones in audioSettingsDialog, ones before encoding startup)?
Yes.

Quote:
So does it mean I can do "getCommandLine()" - a virtual method for AudioSettings?
Since the encoder commandline is taken from the MeGUISettings class, that would mean your derived AudioSettings classes would need to be aware of the settings.. I don't think that's such a good idea. I like the current approch where the encoder and the GUI class have a reference to the settings better.. the job and its settings shouldn't be aware of settings which mostly don't affect them, should they?
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline   Reply With Quote
Old 18th January 2006, 13:53   #1332  |  Link
dimzon
BeHappy/MeGUI developer
 
dimzon's Avatar
 
Join Date: Oct 2003
Location: Moscow, Russia
Posts: 1,727
Quote:
Originally Posted by Doom9
Since the encoder commandline is taken from the MeGUISettings class
Encoder executable path, not commandline. It's possible to generate commandline arguments without full path (and add real path later).
dimzon is offline   Reply With Quote
Old 18th January 2006, 14:01   #1333  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
Quote:
Encoder executable path, not commandline.
Yeah, sorry about that. I think we can do away with the necessity of also showing the executable path in the codec configuration, but having the rest (generated of course) is really nice.
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline   Reply With Quote
Old 18th January 2006, 15:00   #1334  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
Sorry but i have an infection of the inner hear (dont know the english medical term) that causes me vertigos and other problems.
So i cant stay too much in front of the PC and cant read too much (i cant focus on text).
Bear with me... i'll be back.
Sharktooth is offline   Reply With Quote
Old 18th January 2006, 18:01   #1335  |  Link
dimzon
BeHappy/MeGUI developer
 
dimzon's Avatar
 
Join Date: Oct 2003
Location: Moscow, Russia
Posts: 1,727
@Doom9

Code:
    public interface IJobProcessor
    {
        /// <summary>
        /// sets up encoding
        /// </summary
        /// <param name="job">the job to be processed</param>
        /// <param name="error">output for any errors that might ocurr during this method</param>
        /// <returns>true if the setup has succeeded, false if it has not</returns>
        bool setup(Job job, out string error);
.NET Has PERFECT error reporting mechanism: Exceptions && Exceptions Hadling. Why does You try propose such ugly method?
dimzon is offline   Reply With Quote
Old 18th January 2006, 18:17   #1336  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
Quote:
.NET Has PERFECT error reporting mechanism: Exceptions && Exceptions Hadling. Why does You try propose such ugly method?
Because I don't like exceptions? It makes you have to wrap everything into a try/catch block.. and you shouldn't use exceptions for normal program flow.. For instance, if setup returns false because the encoder is not found, it would be a resource waste to resort to an exception for that. There are quite a few instances when an error is reported back that corresponds to regular program flow and thus shouldn't use an exception.
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline   Reply With Quote
Old 18th January 2006, 18:27   #1337  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Quote:
and you shouldn't use exceptions for normal program flow.
Are you sure? Never tried it but recently I thought it could be a cheap way to abort.
stax76 is offline   Reply With Quote
Old 18th January 2006, 18:29   #1338  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
Quote:
Are you sure?
It says so in all the literature I should get around to reading for my certification. And Exceptions are resource intensive (I don't recall the exact specifics... but throwing an exception slows you down quite a bit as opposed to using a return variable).
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline   Reply With Quote
Old 18th January 2006, 19:51   #1339  |  Link
Richard Berg
developer wannabe
 
Richard Berg's Avatar
 
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
I don't agree with dimzon in this specific example, but he has a good point. Having to pass error messages around as parameters -- making every caller store or otherwise handle them -- is usually unnecessary work for the programmer. The most helpful feature of exceptions isn't handling them, it's the option not to. If a method isn't equipped to handle some conditions, flow simply passes to the previous caller.

Throwing an exception is kinda expensive: it causes a hardware interrupt that has to be bubbled all the way up from the kernel. Figure a few thousand CPU cycles. But performance is totally irrelevant for asynchronous GUI apps like MeGUI...so long as you're not throwing exceptions in a tight loop you'd never notice.

A decent rule of thumb: exceptions should roughly correspond with problems that are important enough to show the user an error message. If a program throws & catches often without bothering the user, it's probably overusing exceptions. (It's crazy what you sometimes see if you run badly written software it under a debugger that's set to catch all native exceptions...)

With IJobProcessor.Setup, I think using an error parameter is appropriate. Any method that calls Setup should know what to do if it receives an error string. But it should be simpler: instead of having a bool and a string, just return a string; if it's not null, it's an error.
Richard Berg is offline   Reply With Quote
Old 19th January 2006, 00:01   #1340  |  Link
Mutant_Fruit
Registered User
 
Join Date: Apr 2004
Posts: 287
From what i've been told and what i've read:

Exceptions shouldn't be used to handle normal workflow. If a value you're using has a good chance of NOT being what you expect it to be, use an if statement to see if it's valid. Don't use try/catch to find out. Exceptions are what they say.... Exceptions. They should rarely (if ever) happen.

I'd agree with Richard Berg about not needing a bool AND a string. Thats about it from me... *looks for the 'i am a n00b' poster*
__________________
Nothing to see here...
Mutant_Fruit is offline   Reply With Quote
Reply

Tags
development, megui, not a help thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:58.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.