Hi Ferni ! Argentina is a very beautiful country ! If Your DVD/MPEG-4 Player don't have a problem with B-VOP (with or without Packet Bitstream), You try to use it. AviRecomp set B-VOP=1 -> this parameter set maximum simultaneous B-frames. B-VOP is a "between frames" compression (Bidirectional Video Object Plain). This solution allow to save bits in Your compressed movie. Please, if You have a little more time, try to read this web pages :
Hi Ferni Hope you don't mind, I'm not hijacking your thread but it is so related to what I have to say that it is not worth starting a new one.
Firstly B-Frames, compressed digital video doesn't save all the frames, it save the "differences" between the frames. It then uses these "differences" to reconstruct the frames as it plays. Not all scenes have action in them, indeed many frames have nothing changed from the preceding or following frame. In these cases xvid and divx save a few bits by using a B(idirectional)-Frame. Theoretically a few more bits can be saved in these circumstances by using a unique xvid feature called the N(ull Coded)-vop. This is essentually a place holder and can be used instead of a B-Frame. All well and good unless you are a Philips 642 user. The 642 just does not "see" N-vops. As far as the 642 is concerned each N-vop it encounters is a dropped frame. This causes jerky video and a progressive audio synch problem which worsens as it encounters more and more N-vops. The 642 don't care about packed or unpacked bitstream. It don't even care about a few consecutive B-frames. The N-vop was not a problem using ARC 1.0 with xvid 1.0 but with successive versions of ARC using xvid1.1 it has become a big problem.
The problem is with xvid 1.1. With Xvid 1.0 if B-frames were enabled and the frame drop ratio was zero no N-vops were produced. With Xvid 1.1 some N-vops are produced no matter how you set xvid up. Switching off B-Frames causes enormous amounts of N-vops to be produced.
I thought I had overcome the problem by dropping back to xvid 1.03. Using AGK 2.26 with xvid 1.03, I did a few videos, sizing was correct and no N-vops were made. I tried ARC 1.1 with xvid 1.03 and got lots of N-vops. I tried ARC 1.1.2 with xvid 1.03, with B-frames activated (no check in the box) I got lots (260) N-vops and no B-Frames. I am now trying ARC 1.1.2, xvid 1.03 with B-Frames deactivated (Check in the box) to see what happens. Maybe the B-frame control is ass-backwards.
Maybe I should go back to xvid 1.0 because I just opened up xvid config to check something and I can't find an option to activate/deactivate B-frames in 1.03, so maybe xvid 1.03 is broken as well as 1.1.
Well I'm starting to wonder if this is some kind of source problem. Result with ARC with B-frames deactivated was just the same as with B-frames activated. Loads of N-vops and no B-frames at all. Bit stream is unpacked in both instances. Tried with AGK and got exactly the same results.
Looks like the only way I'm gonna get this kiddie on the 642 is with >dare I say it< Divx. Damn I really wanted to burn in them subs too. regards..
jrfer.
Virgin Media are to send all your browsing data through Phorm. Find out why this is wrong at
Well Divx did it without a murmur. Packed bitstream, no n-vops and plenty of non consecutive B-Frames. Theres a slight quality loss compared to xvid but at least it will play on the 642. It looks like xvid 1.03 is as duff as xvid 1.1 is, as far as n-vops and the 642 is concerned. With all these xvid versions that don't perform xvid is getting to be more trouble than it is worth. Seems to me that no xvid version since 1.0 has been able to make compatable 642 avi. regards..
jrfer.
Virgin Media are to send all your browsing data through Phorm. Find out why this is wrong at
"jrfer" wrote ... Strangely whatever version of xvid is installed ARC always says N/A??
This can be a main reason ! As you know every version of XviD is different. The settings are more or less different. So ARC must detect the right version of XviD to be able to send the right settings to the codec (different settings when XviD 1.0.3 detected, different when XviD 1.0 detected, etc.) Unfortunately the authors of XviD are negligent XviD is distributed as a library (DLL). Every library is and application and it should include its version number. Just try to find avisynth.dll or vobsub.dll in your system directory and right-click on the file, then choose Properties. You will then see the Version tab. You will be able to get the detailed info (file version, product version, language and the like) Do the same with xvidvfw.dll. You will get nothing. Seems the authors don't care about this little but very important detail That's why many various tools like AVI Codec or GSpot are not able to detect the version of XviD codec. So how ARC detects the version of XviD ? ARC always looks for a special file located in XviD install directory. This file contains the release notes and its name is releasenotes.txt. Unfortunately there are many various compilations of XviD available. Not every compilation is distributed as an installer. Not every compilation creates the install directory, not every one includes releasenotes. That's why sometimes ARC is not able to detect the version of codec. I would be very very happy if the authors of XviD decided to add the version numbers to their compilations ! Maybe we should write such a request somewhere at the official XviD site. Is is also very possible that AGK has the same problems. I have just run ARC with XviD 1.1.0 final installed. What are the compilations that you install ? Original Koepis ?
I loaded 3 samples and recompressed them without disabling B-VOPs (Disable BVOPs unchecked) and got 3 outputs with no N-VOPs. I have to hurry as I am invited to the party. I will surely visit this topic again after I come back home. Greets, Prozac
Thankyou for a great App and I hope you have a great time at your party.
You may have hit the nail on the head with your suggestion, although to prove the point the problem must be overcome first.
I too have been frustrated by not being able to determine which version of Xvid is installed so I was interested to learn how ARC determines the version.
Looking in my xvid folder I see I have a Koepi version of xvid 1.03 and that the release notes are present and correct. Now the only other thing is - where does ARC look for the xvid install directory. I would hazard a guess that it looks in C:Program Files. My file system is not standard in that my HDD is partitioned and most of my programs which includes ARC, AGK and Xvid are installed in a partition labeled F:.
So I will clean my system of xvid 1.03 and install Koepi xvid 1.1 final 30122006 this time to my C:Program files.
I will let you know how it works out.
>I would be very very happy if the authors of XviD decided to add the version numbers to their compilations ! >Maybe we should write such a request somewhere at the official XviD site.
With regard to the above. If my theory proves to be correct, all that needs to be done is to let people know where ARC expects to find the Xvid installation folder. I have recommended ARC to several people and a couple of them just could not get it to run properly. I knew it was a codec problem and advised them to reinstall xvid, rebooting after the uninstall and rebooting after the reinstall, but to no avail. Maybe they too had non standard file systems?
The only thing that is strange is that ARC 1.0 worked flawlessly. Hehe well that is PC's for you. Never any consistencies.
Jrfer. regards..
jrfer.
Virgin Media are to send all your browsing data through Phorm. Find out why this is wrong at
Now that ARC can determine the xvid version I am getting sensable results. Annoyingly though n-vops are still being produced but now only in minimal quantities according to mpeg4modifier.
Packed bitstream: Yes QPel: No GMC: No Interlaced: No Aspect ratio: Square pixels Quant type: H.263
For the moment I still have to determine how the current ARC output under xvid 1.1 with minimal n-vops population plays back on the 642.
Is there a difference between an N-Vop and a N-Vop(D)?
OK Delving deeper I have just examined a Divx which doesn't have n-vops and find loads of n-vop(D)'s so I'm deducing that an N-Vop(D) is a (D)ummy. If that is indeed the case then mpeg4modifier when reporting N-VOPs: 1 (0.00%) actually means that somewhere amongst the myriad dummy N-Vops there is just 1 REAL N-Vop. I will surmise that the effect of the 642 encountering just 1 N-Vop in a avi file would have such a small effect on audio synch as to be quite undiscernable to the human ear.
Hopefully my problems with xvid 1.1 are now over. regards..
jrfer.
Virgin Media are to send all your browsing data through Phorm. Find out why this is wrong at
XviD version detection Let me tell you more about searching for XviD that ARC performs. Indeed ARC is looking for XviD install dir directly in Program Files directory. But... the name of Program Files directory can be different dependently on Windows language version. For English version its name is Program Files, for Polish the same, but the name of Program Files directory is specific to Windows version. So first ARC looks for a registry key: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion This registry key contains an entry named ProgramFilesDir and its value contains the right name and path of Program Files directory. After searching for this value ARC looks for XviD directory located in the path that was found in a registry. As you can see it is not perfect since someone may have XviD installed in a different location. I have just found one more registry key that can be more accurate to detect XviD installation directory: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstallXviD_is1 As you can see there is also a version info stored under this key. One of the previous versions of ARC got the version number from that place. But since I noticed that not every XviD installer creates a valid version info in this place I aborted searching there. It is all really terrible we have to search for one program version in such ways I see you are fairy advanced in computing so your every suggestion will be very appreciated Maybe together we will be able to improve our tool and get over the problems
"jrfer" wrote ... The only thing that is strange is that ARC 1.0 worked flawlessly.
Yes, because before ARC always detected the XviD version dependently on xvidvfw.dll file size That was one of my previous methods for searching the version. So it could work well but it was very risky so I stopped using this way.
Supported XviD versions Now, lets talk about XviD support. When I started working on ARC the newest stable version of XviD was 1.0.3 This time ARC always set XviD to use AS @ L5 profile during the encoding. After XviD 1.1.0 beta was released I decided to use its new profile DXN HT to get a full DVD player compatibility. But when the final version of XviD 1.1.0 was released the authors changed the profile names and removed DXN HT So for XviD 1.1.0 I decided to use Home Theatre profile which is also present in XviD 1.2 beta. For the time being ARC supports every version of XviD starting from 1.0.3 But... it is another risky behaviour. If ARC is not able to detect the valid version then it is not able to set the right profile !!
XviD profiles We were talking about AutoGK. I know Anton (len0x) very well. I was wondering how he solved the problem of searching for XviD version. I was going to ask him but before I did it I decided to look at his FAQ. Just look what I have found there:
wrote ... 4.3 Which codecs are supported? - At the moment the only supported codecs are: XviD 1.1.x, DivX 5.2.1 Pro and DivX 6.0.3+ (as of 2.25). If you're using MTK/Sigma compatibility option then you HAVE to use XviD build supplied with AutoGK
So, as you can see our Russian friend Anton was also not able to get over this problem.
N-VOPs Now, shortly about NVOPs. I have to go back to my work. Personally I use Philips 630/02 and 762/02 players. I haven't ever noticed any problems. MPEG4 Modifier is a nice tool - I wish the author continued working on his project. Indeed, N-VOP(D) means dummy N-VOPs. According to my knowledge no real N-VOPs are used when the Packed Bitstream is used. So your analyses are correct.
I see you are one of the most active persons on the forum. It is nice to work with you Let me invite you to our beta-testing section. There are a few forum sections that are not visible for a common user. They are available only for beta-testers. This is a good place to discuss about such things. There you can download the newest version of ARC and post your reports. For the time being we have 5 beta-testers but sometimes nobody has a time to perform the tests. I am not able to check a new version alone. It always should be tested on more then one computer and operating system. So if you have a free time, if you like ARC feel invited to the beta-testers group. Just let me know so that I will change your forum range and give you an access to the special sections.
Maybe together we will be able to improve our tool and get over the problems 
