known issues for development 0.28 features, already, problem, started, thread

andy

I just wanted to create a thread where I post what I know is not working yet (bugs or features), so that ppl will not hammering me with what I already know

Here we go:

as of alpha 3 - no serious issues for me

DivX3 is a nogo. Comp Check crashes the program, and when trying to encode Nandub isn't started.

Originally posted by Doom9
DivX3 is a nogo. Comp Check crashes the program, and when trying to encode Nandub isn't started.

I know what's the problem  correction I new, but after I fixed that the problem still exists  will have to chase Divx3 stuff another time

p.s. I have to chase lots of bugs of existing code actually on the way of debugging my code  (I mean some of them I don't even know how ppl didn't spotted before...)

I found it and uploaded alpha 3

(Wef - that bug with divx3 non working was due to your suggestion at the only beginning when I was trying to make vdubmod working without renaming  )

just checking the compcheck.. seems to be working.
Regarding the DivX5 support. It's sure good to be able to use newer codecs also.. but part of the success of GKnot comes from being able to not forcing people to handle those codec setup dialogues.. it would be great if all that could be automated again and the only additional parameter for divx5 would be the number of passes when using 5.03 or 5.04 (to give you a preview of my gknot ng design.. you'll find lots of those quot;make things easier for peoplequot; things in there).

First of all it is great to see that gknot is making such a promising progress again!

Originally posted by Doom9
but part of the success of GKnot comes from being able to not forcing people to handle those codec setup dialogues.. it would be great if all that could be automated again and the only additional parameter for divx5 would be the number of passes when using 5.03 or 5.04 (to give you a preview of my gknot ng design.. you'll find lots of those quot;make things easier for peoplequot; things in there)

thats also my opinion!

as i hope that gknot will also support xvid somewhere in the future, this will be even more important!perhaps the choosable options can be distributed like this:

usable options especially for divx5:
@ the encoder-gt;add job-gt;divx 5 tap the possibility to choose quot;number of passesquot; and the quot;psycho enhancementsquot;

usable options especially for xvid:
@ the (now not existing) encoder-gt;add job-gt;xvid tapquot;
the possibility to check quot;lumiquot;, quot;chromaquot; and to choose quot;vhqquot;

options for both xvid and divx:
@ the options tap the possibility to check things like b-frames, gmc, qpel

just my few unimportant proposals

Hi, what about mpegdecoder.dll suport for loading the vobs (would be faster right?) and BeSweet to extract and compress (or not) the audio files?

Thanks for listening, and best luck with developement of our loved Gordian Knot.

Originally posted by Doom9
just checking the compcheck.. seems to be working.
Regarding the DivX5 support. It's sure good to be able to use newer codecs also.. but part of the success of GKnot comes from being able to not forcing people to handle those codec setup dialogues.. it would be great if all that could be automated again and the only additional parameter for divx5 would be the number of passes when using 5.03 or 5.04 (to give you a preview of my gknot ng design.. you'll find lots of those quot;make things easier for peoplequot; things in there).

I see the point, but I see no simple solution for both approaches, i.e. support of future codecs without breaking current version and _robust_ automation of the process (i.e. not settings all the parameters for codec is not not robust from the user point of view)

Right now (may be I didn't make that clear) I wanted to pop up the dialog already with most of the values set, so the user ideally just have to press OK and that's it... (and I see no reasons to duplicating settings like B-frames etc in GK as long as they are really easy configurable in the codec...)
My point is - GK is not simple to use for complete newbie. One still have to go through the guides. And as long as you can describe what they have to do - everyone should be quite happy. What do you think ?

Perhaps using the sourceforge bug tracker would be better for this.(people are already using the requests stuff). Makes is easier for people mark bugs as resolved (well mods can delete the bug reports but noone else can). Also it makes it easier if people want to elaborate on a specific bug they can add a comment to the specific bug rather then this thread of all bugs.

DaveEL

@len0x: we absolutely must make gknot more automated in the future or it will eventually loose it's number one position. In a time where we are getting close to have almost fully automated DVD reauthoring (and that's a way more complicated subject than divx / xvid creation) requiring so many manual steps is a shame. Can't the DivX CLI strings be used without too much hassle? And afaik DVD2OGM also offers some codec settings inside the program without resorting to codec specific configuration dialogues.. and especially in the xvid world there are many many codec updates all the time (I finally gotta check out the program and see how well it can handle codec updates).
People are still using Flask and Co because GKnot is too complicated (not for us, but for beginners, and even we spend too much time doing stuff that we could automate since we know exactly how it has to be done).

Originally posted by Doom9
@len0x: we absolutely must make gknot more automated in the future or it will eventually loose it's number one position.Something striked me with this words  We can make GK indeed whatever we want as long as quot;wequot; do it not just me
Lets look at this from different point of view. What I'm trying to do for 0.28 is basically hacking, rather than proper development. Why do I involve in this at all ? Coz I use GK a lot (and 99% of the time it takes me  exactly 1 min (apart from comp test) to set an encode for it, even with the 0.28 I'm developing) and I want to be able to continue to use it. And it just happened to be written in deplhi which I know. that's it. So 0.28 is basically the solution for the only situation where ppl are happy with 0.27 but cannot use it anymore.

My worries here that I'll be the only one doing that much of development and I'll stop doing that as soon as _I_ (nobody else) satisfied with what I've got...

Originally posted by Doom9
In a time where we are getting close to have almost fully automated DVD reauthoring (and that's a way more complicated subject than divx / xvid creation) requiring so many manual steps is a shame. True, but you are thinking in terms of product manager point of view.
I'm sure if you have to do all development on your own in your spare from work time, you'd be not so ambitious
I'm a professional programmer and can tell you that the only reason I'll do unpaid programming now is when I'm doing something for myself (well I'm not teenage anymore  ). If that happens to be what somebody else like - great. If not - I'm still doing that for myself.
Just wanted to explain my position on that.

So to sum up: I'll agree with all you guys - GK has to be as automated as possible. But don't expect it to be exacly what you want until I'm solo hacker here. I'm sure you understand that...

Originally posted by len0x
I see the point, but I see no simple solution for both approaches, i.e. support of future codecs without breaking current version and _robust_ automation of the process (i.e. not settings all the parameters for codec is not not robust from the user point of view)See thewefs ideas for codec config here showthread.php?s=amp;threadid=50093

Also i havn't tried out r4r yet but it certainly looks good for a lot of the things gk was in general bad at. Perhaps we should look at just making the knot fill in the gaps which remain at the end of r4r at least for now (video encoding and the audio muxing i believe). It may simplify the task somewhat if we remove a lot of the duplicated code. Then if we wish to implement the entire process in one open source app we can slowly work backwards along the r4r chain until we can just take a dvd and produce an output video.

The only problem i see here is that its difficult to process the entire job in a linear order i for instance decide on audio formats based on a comp test results.

Sorry im using quot;wequot; too much here. I do plan at some point making some time to contribute to the project but final year project forbids it currently.

DaveEL

Originally posted by DaveEL
Perhaps using the sourceforge bug tracker would be better for this.(people are already using the requests stuff). Makes is easier for people mark bugs as resolved (well mods can delete the bug reports but noone else can). Also it makes it easier if people want to elaborate on a specific bug they can add a comment to the specific bug rather then this thread of all bugs.

People have started using the sf bug tracker so i think again keeping all the bugs in one place would be useful.

Oh and does anyone mind if i redirect to sf homepage to this forum for the moment until we get a real homepage it seems the most relevant info(as the homepage for gk is 0.27 based currently) perhaps just a plain page with a link to the official gk page the gk forum and the dev forum.

DaveEL

Originally posted by DaveEL
See thewefs ideas for codec config here showthread.php?s=amp;threadid=50093Yeah, I saw that - looks nice for me, indeed.

Originally posted by DaveEL

Then if we wish to implement the entire process in one open source app we can slowly work backwards along the r4r chain until we can just take a dvd and produce an output video.The moment fully automated solution will be produced and published (i.e. 2-3 clicks for the _whole_ process) MPAA kicks ass of everybody  I still think they are not that active (say only tried to go for deCSS author) only because most of the comp users don't have a clue how to rip the video

@len0x: well.. the 2-3 click tools are already here.. you can judge for yourself what the MPAA is doing about it.

Now I do understand your point about time and doing it for free (heck, you won't find many people having done more for the whole dvd backup thing than me, at least time wise.. I've been doing this full steam for 3 years), and I don't won't to force you to anything... just trying to give you some ideas. I know pretty well what a ripping program has to do and I bet my years of experience can be put of some use.
Now, assuming that the codec thing is already solved theoretically, once we have divx5 and xvid support and since you're already using vdubmod, the next logical step would be to offer ogm support. This shouldn't be too hard as you can control it pretty much the way vdub is controlled now. I plan to have a look at dvd2ogm anyway and I'll see if I can find some useful information on how ogm is done there (I suppose using vcf files), so the ogm thing wouldn't really be a huge task either.
And, with these things done all the basic functionality is already there... from that point on it's only putting the code pieces together in another order  Hopefully by that time we'll find some more active developers (if you need some publicity support you know where to ask  so that this can be achieved quickly and efficiently.

And I suppose you haven't had a look at r4r yet.. it does a lot of the work for a perfect process already... for instance you no longer have to worry about audio encoding as this is done in r4r (@daveel: I believe that most users settle for a certain audio base quality, so the automatization should assume that, if not you can always go back to r4r and re-encode the audio only once you see your actual bitrate). A lot of features in GKnot are also not needed today. Looking at the tab in GKnot the following can be left away: ripping, nandub files, stats editor, subs, file list writer (the special nandub stuff could possibly placed in another tool designed to only do that... of course that's no job for you and I'm wondering if anybody still bothers to manually edit stats files anyway).

as for the bugtracker.. I guess it's a question of how people can get used to it. It's a good mechanism, but badly persented at sf (search on this forum is much more flexible for instance).

Originally posted by Doom9
Now I do understand your point about time and doing it for free (heck, you won't find many people having done more for the whole dvd backup thing than me, at least time wise.. I've been doing this full steam for 3 years), and I don't won't to force you to anything... just trying to give you some ideas. I know pretty well what a ripping program has to do and I bet my years of experience can be put of some use.No doubt about that!
I never said I don't wanna hear anything, just that I don't wanna do everything by myself
Anyway your comments are highly appreciated!

Originally posted by Doom9

Now, assuming that the codec thing is already solved theoretically, once we have divx5 and xvid support and since you're already using vdubmod, the next logical step would be to offer ogm support. This shouldn't be too hard as you can control it pretty much the way vdub is controlled now. I plan to have a look at dvd2ogm anyway and I'll see if I can find some useful information on how ogm is done there (I suppose using vcf files), so the ogm thing wouldn't really be a huge task either.You can see in some other thread I said that actually for simple support of codec/tools I'd like many thing to be rewritten (basically full job engine). If this and efficient profiling system is implemented (as wef proposed) then indeed evrything else will quite easy be plugged on top of the core system.

Originally posted by Doom9

A lot of features in GKnot are also not needed today. Looking at the tab in GKnot the following can be left away: ripping, nandub files, stats editor, subs, file list writer (the special nandub stuff could possibly placed in another tool designed to only do that... of course that's no job for you and I'm wondering if anybody still bothers to manually edit stats files anyway).I DO agree with that - at the moment actually full divx3 support holding me down a bit (coz I cannot start writing something from scratch for divx5/xvid worriyng that I still need divx3 support)

So are you saying I can really start removing things like subs/ripping/filelist/ stat editor ?Originally posted by Doom9

as for the bugtracker.. I guess it's a question of how people can get used to it. It's a good mechanism, but badly persented at sf (search on this forum is much more flexible for instance).

yeah but at least you can see summary of the bugs and how many of them actually exists

Originally posted by Doom9
Now I do understand your point about time and doing it for free (heck, you won't find many people having done more for the whole dvd backup thing than me, at least time wise.. I've been doing this full steam for 3 years), and I don't won't to force you to anything... just trying to give you some ideas. I know pretty well what a ripping program has to do and I bet my years of experience can be put of some use.I think the comments were more about
quot;we absolutely must make gknot more automated in the futurequot; the quot;wequot; is inaccurate to say the least. So lets try to revise that to
You absolutely must make gknot more automated in the future
No still wrong worse in fact how about
I think it would be a good idea to make gknot more automated in the future
That's better don't you agree. Now, assuming that the codec thing is already solved theoretically, once we have divx5 and xvid support and since you're already using vdubmod, the next logical step would be to offer ogm support.
Bitrate calc is the major blocker on ogm support imo as i have posted in the ogm feature request on sourceforge.

And I suppose you haven't had a look at r4r yet.. it does a lot of the work for a perfect process already... for instance you no longer have to worry about audio encoding as this is done in r4r (@daveel: I believe that most users settle for a certain audio base quality, so the automatization should assume that, if not you can always go back to r4r and re-encode the audio only once you see your actual bitrate). A lot of features in GKnot are also not needed today. Looking at the tab in GKnot the following can be left away: ripping, nandub files, stats editor, subs, file list writer (the special nandub stuff could possibly placed in another tool designed to only do that... of course that's no job for you and I'm wondering if anybody still bothers to manually edit stats files anyway).All the code required to edit nandub stats files need to be included to do divx3 support anyway the gui elements should just been hidden away where anyone who doesn't need them will not find them.

Ok people will argue that nandub is outdated and isnt required but in some situations it still looks better and more importantly to some people it always looks better as some people prefer the type of artifacts generated in 3.11 to the other codecs.
Aside from that i totally agree with simplification of gordian knot to do only those parts which r4r cant cope with better.
as for the bugtracker.. I guess it's a question of how people can get used to it. It's a good mechanism, but badly persented at sf (search on this forum is much more flexible for instance).

But once you start to deal with lots of bug reports it becomes unmanageable
1) you need to look everywhere to find the bugs as they are not in one place.
2) no clear indication of which bugs have been resolved or are invalid - this happens a lot on the xvid forum
3) no indication of what needs to be done next or at least what needs to be done before the next release.

ok the sf setup isnt the best but a full bugzilla setup would be overkill IMO (plus we would need to host it somewhere).

DaveEL
ps this thread is getting rather off topic ill see if i get some time tomorrow if i can reorganise it a bit, if noone has any objections.

I guess first bugs/feature requests/other random conversations that made it into this thread need to be seperated

I think it would be a good idea to make gknot more automated in the future
That's better don't you agree.

Indeed you're correct. I didn't choose the right words. In other posts I've always tried to use conditionals and starting sentences with quot;I thinkquot;.

Bitrate calc is the major blocker on ogm support imo as i have posted in the ogm feature request on sourceforge.

I suppose the ogm folks on this board could be of some help here.

All the code required to edit nandub stats files need to be included to do divx3 support anyway the gui elements should just been hidden away where anyone who doesn't need them will not find them.

hmm.. I forgot about the curve stuff. But isn't the curve simply linearly scaled by default? I doubt all the range control functions, manual corrections, etc. are being used. Wef?

As for sf, that should be up to the developer to decide. I personally have no problem with a bugtracker, it's definitely a good thing for a programmer, I just voiced some concern that some users might not be able to properly handle it.

(oggds 0.9.9.5 is already 5 months old and still quite buggy)!?

and dont forget about matroska/mcf! perhaps suiryc can give you his matroskadub muxing code, which already exists...

@len0x,

For me the GKnot is used only as Calculator, AVSGenerator, and Comp. Checker. All ripping and encoding process I prefer to do it manually.

So with your latest AutoCrop addition, it's much better for me,
I don't have to adjust the crop value manually anymore  LoL!