Franko30
16th October 2002, 09:50
Hello everybody,
Please note, that I wrote this, assuming, that the Dshow Filter was the reason for my problem - but actually it is the XVID.dll, as Nandub uses the DLL not the Dshow Filter.
Just skip this thread, I'm so ashamed of how dumb I am...
until yesterday I was still using Koepis XVID build of August 18th and was only lurking in the forum on a weekly basis to keep up withn the reading.
But now as Qpel seems to be working, I decided to give it a try - and it really works well! In the 2-pass encoding of a Star Trek Original Series capture, the average Quant of the new Koepi development build (October 12th) was about 0.25 lower than with the old August build. I'm going to do some more testing to verify that.
BUT:
As I capture audio and video separately, and I capture a lot, I'm 3 months behind with the muxing of the movies.
Now, when I open a movie encoded with the August 18th build (and before) in Nandub, keyframe accurate editing is not possible anymore. When jumping from keyframe to keyframe, setting start and end points, the resulting clip has different end and start points than the ones set. Noticing that, I tried Nandub again and found out, that the frame dispalyed by Nandub as a keyframe is actually a frame way after or even before the actual keyframe. When jumping forward to the next "keyframe" and then back, a completely different frame gets displayed... When moving on a frame by frame basis in Nandub, I could find the correct keyframe - but when marking it, I still don't get the start and end points I wanted in the finished clip.
Exchanging only the XVID.ax with that of the August build doesn't help.
Exchanging the current XVID.dll and XVID.ax with those of the August build solves the problem (as the old Dshow filter relies on the XVID.dll - is that right?).
There's no problem at all when editing the files encoded with the new XVID build mentioned above.
So this has to be a problem of the new Dshow Filter with the old files.
In the thread "An XviD bug, a newer DShow filter & my new site" people ask for new features to be added to the Dshow Filter. If I would be asking for s.th. (which I don't), all I would be asking for is some kind of "backward compatibility" :D :D
For now, I just replace the XVID.dll and XVID.ax files with the older ones for editing and muxing; until I cath up with the new encoded clips from now onwards and everything is fine ;)
Cheers, and thanks for all the work to all people involved.
Frank
Please note, that I wrote this, assuming, that the Dshow Filter was the reason for my problem - but actually it is the XVID.dll, as Nandub uses the DLL not the Dshow Filter.
Just skip this thread, I'm so ashamed of how dumb I am...
until yesterday I was still using Koepis XVID build of August 18th and was only lurking in the forum on a weekly basis to keep up withn the reading.
But now as Qpel seems to be working, I decided to give it a try - and it really works well! In the 2-pass encoding of a Star Trek Original Series capture, the average Quant of the new Koepi development build (October 12th) was about 0.25 lower than with the old August build. I'm going to do some more testing to verify that.
BUT:
As I capture audio and video separately, and I capture a lot, I'm 3 months behind with the muxing of the movies.
Now, when I open a movie encoded with the August 18th build (and before) in Nandub, keyframe accurate editing is not possible anymore. When jumping from keyframe to keyframe, setting start and end points, the resulting clip has different end and start points than the ones set. Noticing that, I tried Nandub again and found out, that the frame dispalyed by Nandub as a keyframe is actually a frame way after or even before the actual keyframe. When jumping forward to the next "keyframe" and then back, a completely different frame gets displayed... When moving on a frame by frame basis in Nandub, I could find the correct keyframe - but when marking it, I still don't get the start and end points I wanted in the finished clip.
Exchanging only the XVID.ax with that of the August build doesn't help.
Exchanging the current XVID.dll and XVID.ax with those of the August build solves the problem (as the old Dshow filter relies on the XVID.dll - is that right?).
There's no problem at all when editing the files encoded with the new XVID build mentioned above.
So this has to be a problem of the new Dshow Filter with the old files.
In the thread "An XviD bug, a newer DShow filter & my new site" people ask for new features to be added to the Dshow Filter. If I would be asking for s.th. (which I don't), all I would be asking for is some kind of "backward compatibility" :D :D
For now, I just replace the XVID.dll and XVID.ax files with the older ones for editing and muxing; until I cath up with the new encoded clips from now onwards and everything is fine ;)
Cheers, and thanks for all the work to all people involved.
Frank