XviD 1.3.5 is out

[hajj_3]

Changes since 1.3.4:

xvidcore library
AmigaOS build patch by Fredrik Wikstrom

Support for applevel multithreading mode also for AVI output in xvid_encraw

Set interlacing flag in decoder correctly


VFW frontend
Re-add support to decode raw YV12 input FourCC video

Fix: Produce debug output only when debug option is enabled

DShow/MFT frontend
Fixed bug in thumbnail creation on Windows 7

Fix output buffer stride calculation in MFT

Setting interlaced flags on output pins correctly in DirectShow and MFT

Corrected pixel aspect ratio support in MFT


https://downloads.xvid.com/downloads/Xvid-1.3.5-20171208.exe

https://labs.xvid.com/source/#Release

[LigH]

MinGW-Win32/GCC 7.2.0 built CLI tools of Xvid 1.3.5 available in my MediaFire shares (see my signature).

[GMJCZP]

I tried it opening an avi with VirtualDubMod and it opened perfect! It's good that they put the VFW support back on.

[Brazil2]

MinGW-Win32/GCC 7.2.0 built CLI tools of Xvid 1.3.5 available in my MediaFire shares (see my signature).
I can't download it, I'm getting this error message:
File Blocked for Violation.

[LigH]

Unfotunately I don't know which terms of usage it might violate.

Fortunately I also uploaded it in the VideoHelp forums (https://forum.videohelp.com/threads/380072-Xvid-1-3-4-(VFW)#post2504525).

[Midzuki]

FWIW, and to whom it may interest, this archive includes the VfW interface.

https://forum.videohelp.com/threads/386192-Xvid-1-3-5-%28VfW-32-bits%29?p=2504552#post2504552

File Blocked for Violation.
0_o

[Groucho2004]

Unfotunately I don't know which terms of usage it might violate.

Fortunately I also uploaded it in the VideoHelp forums (https://forum.videohelp.com/threads/380072-Xvid-1-3-4-(VFW)#post2504525).
Your version of encraw shows version "xvid-1.4.0-dev" whereas Midzuki's build shows (correctly) "xvid-1.3.5".

[LigH]

Because I used SVN to retrieve the latest sources? ... OK, once again. Attached archive in VideoHelp post (https://forum.videohelp.com/threads/380072-Xvid-1-3-4-(VFW)#post2504525) updated (Win32 and Win64 builds from v1.3.5 source archive instead of SVN, incl. some legal files, and with max. 8192 zones).

[Groucho2004]

Because I used SVN to retrieve the latest sources?Yes, that was quite obvious. I just thought you may not have been aware that you checked out the latest instead of the release (1.3.5).

[GMJCZP]

Just for curiosity, I report that the file that Midzuki suggests makes when I try to play an AVI XVID in Windows Media Player in Windows 7 it chrashes, it does not happen that way with the 11 MB file of Koepi.

[Midzuki]

Just for curiosity, I report that the file that Midzuki suggests makes when I try to play an AVI XVID in Windows Media Player in Windows 7 it chrashes, it does not happen that way with the 11 MB file of Koepi.

Just do not use Windows Media Player, problem solved =)

Seriously: I cannot determine whether the problem is in WMP itself OR in some stupid automagic update from Microsoft themselves.

Someone please correct me if I am wrong... but WMP 12 does not use VfW at all for playing MPEG-4 ASP videos, right? :confused:

[Midzuki]

^ Right now I'm playing an Xvid-encoded AVI file in WMP12 and no, there are no problems at all, no crashes, glitches, or whatever.

I too use Windows 7, but differently from many /most people, I never let the operating system update itself.

P.S.: Equally possible, the cause of the problem is another software which your computer has but mine doesn't.

[clsid]

It installs both DirectShow and Media Foundation decoder. WMP12 uses MF by default, except if DirectVobSub is installed and a subtitle file is present.

[GMJCZP]

I also have LAV filters 0.71 installed, I do not know if it will have something to do so that only the Koepi file works.

[GMJCZP]

Well, I solved the problem in the following way:

1) I updated the system, although I did not see any related to WMP
2) I replaced the xvidvfw.dll file (the culprit of the crash, according to the Windows report) with the Koepi file and then ran the .bat file.

For whoever is interested, here is the resulting package:
Here (http://www.filedropper.com/xvid-135-win32)

[LigH]

So, you mixed Koepi's VfW interface DLL with a newer Xvid core DLL?

[GMJCZP]

So, you mixed Koepi's VfW interface DLL with a newer Xvid core DLL?

No, both are from version 1.3.5 (I took Koepi's xvidvfw.dll from System32), but maybe the version of the Midzuki link is bad compilated.

[Midzuki]

No, both are from version 1.3.5 (I took Koepi's xvidvfw.dll from System32), but maybe the version of the Midzuki link is bad compilated.

Since Xvid 1.3.5 and WMP12 work as they should on my PC which runs Windows 7 x64, the right conclusion is only one: the problem is yours, not mine.

[/E.O.D.]

[GMJCZP]

I said Midzuki link, not Midzuki compilation, it's a videohelp link only :rolleyes:

[Neillithan]

.....

[LigH]

Because MPEG4-ASP has uses you can't imagine. And may it just be: "Hey, my player still works, why buy another?"

[GMJCZP]

In addition, IMHO is less demanding for some players, and as it is less and less important the size of a file I think it is a good idea to code in XVID.

Edit: i have a LG DVK-9713N, it works like a charm.

[Neillithan]

Well, it's definitely not for me, that's for sure.

I feel like the best way to watch anything is on a PC, and if you want to watch it on a TV, just get a moderately long HDMI cable, or build a small form factor, HTPC and stream everything to it from your main PC or home NAS. Whatever.

If you're converting movies to xvid in 2018, you're just dragging out the inevitable. There are better formats out there and many players can handle them just fine with no issues.

Feel free to convince me otherwise.

Because MPEG4-ASP has uses you can't imagine.

This feels like a copout response.... as it doesn't elaborate enough to actually sustain itself as a valid reason. Feel free to elaborate.

[LigH]

There is no need to convince you that you should use Xvid when you know you can rather use something more advanced.

Other people may need Xvid for specific reasons. And I won't convince them to abandon Xvid at all costs. Only if convenient.

[orion44]

Cool!

I still prefer the natural look and feel of XviD encoded videos, instead of the perfectly clean, deblocked, artificial look of x264 encoded videos.

[Neillithan]

There is no need to convince you that you should use Xvid when you know you can rather use something more advanced.

Other people may need Xvid for specific reasons. And I won't convince them to abandon Xvid at all costs. Only if convenient.

Okay, so if you can't even remember something you said 1 post ago, then I will just settle on the fact that you have no clue what you're talking about.


Because MPEG4-ASP has uses you can't imagine.

ELABORATE.

Please and thank you.

[Neillithan]

I still prefer the natural look and feel of XviD encoded videos, instead of the perfectly clean, deblocked, artificial look of x264 encoded videos.

I don't think this is a universally true statement. It depends on the footage, the bitrate chosen, resolution, and the encode settings (grain preservation techniques, etc), and also, which details you tend to focus on more than someone else.

I've seen many XviD videos in my time, and they almost all look like an artifacting mess by comparison to x264 or x265. x264 and x265 look far more natural to me if you choose correct settings, which is actually very easy to do.

[Groucho2004]

Well, it's definitely not for me, that's for sure.Fair enough.

I feel like the best way to watch anything is on a PC, and if you want to watch it on a TV, just get a moderately long HDMI cable, or build a small form factor, HTPC and stream everything to it from your main PC or home NAS.That's your opinion, or rather what you "feel like". I for example use an excellent media player app in my smart TV to view stuff from my NAS. No HTPC necessary. Other people use dedicated set top boxes. Whatever floats ones boat.

If you're converting movies to xvid in 2018, you're just dragging out the inevitable.That statement makes no sense. What exactly is inevitable?

Feel free to convince me otherwise.That surely would be a waste of time.

[LigH]

The "please" doesn't make this request less demanding (and ALL CAPS is demanding); I don't enjoy being threatened.

I belong to the group of people who still occasionally use a mobile player (pocket size) which is not yet capable of decoding MPEG4-AVC, for which MPEG4-ASP is the optimum. And as long as it works, I see no reason to dump it. Of course, today I would not buy such a limited device anymore. But that's not the topic here.

I grant you your right to use "something better than Xvid", I don't mind. But I would mind if you deny other people the right to still use Xvid where it is appropriate for their limited features.

My parents taught me tolerance. What I don't like but can't fix, I may decide not to care about further.

[Neillithan]

Good-bye.

[Neillithan]

Good-bye.

[Neillithan]

Good-bye.

[LigH]

Is Xvid really missing a CLI parameter for xvid_encraw (like '-V' or '--version') which prints the version number and quits? I could only find one way to make xvid_encraw print it: When it passes the parameter sanity check and actually tries to encode something. There is no version number contained in the help output. So the fastest way to query the version seems to be:

xvid_encraw <NUL

Just for fun - nothing important happened, only a fresh compile in MABS.

Xvid CLI 1.3.5 (https://www.mediafire.com/file/menjnlnrzacpeeb/xvid_cli-1.3.5.7z/file) (MSYS2, MinGW32 / MinGW64 + GCC 9.1.0)

[Asmodian]

Mediafire says they blocked your upload for violation of terms of service. :(

[filler56789]

Mediafire says they blocked your upload for violation of terms of service. :(

That's the second time (AFAIR) MediaFire prove they don't like LigH :confused:

But fortunately there is another link: https://forum.videohelp.com/threads/386228-Xvid-1-3-5-(CLI)#post2555380

[LigH]

Support ticket submitted... may hopefully be released soonish.

[LigH]

Xvid CLI 1.3.7 (https://www.mediafire.com/file/menjnlnrzacpeeb/xvid_cli-1.3.7.7z/file) (MSYS2, MinGW32 / MinGW64 + GCC 9.3.0) pending, blocked automatically by MediaFire, as usual; mirror in the VideoHelp forum (https://forum.videohelp.com/threads/386228-Xvid-1-3-5-(CLI)#post2579694)

[LigH]

Xvid CLI 1.4.0-dev 4f02ef0c (https://www.mediafire.com/file/pgyodjn8a00avxd/xvid_cli-1.4.0-dev_4f02ef0c.7z/file) (MSYS2, MinGW32 / MinGW64 + GCC 10.3.0) probably blocked automatically by MediaFire, as usual; mirror in the VideoHelp forum (https://forum.videohelp.com/threads/386228-Xvid-1-3-5-(CLI)#post2619938)

[GMJCZP]

Thanks, but you must be registered to enter the link to videohelp. I suggest You FileDropper to uploads.

[LigH]

Then use MediaFire, it seems not to be blocked this time.

[GMJCZP]

Then use MediaFire, it seems not to be blocked this time.
I can't, 'cause My suggestion, Mediafire hates xvid

[Brazil2]

you must be registered to enter the link to videohelp.
Nah, he posted the link for a reply to the thread but you can get the file here without registering:
https://forum.videohelp.com/threads/386228-Xvid-1-3-5-(CLI)#post2619938

[GMJCZP]

Nah, he posted the link for a reply to the thread but you can get the file here without registering:
https://forum.videohelp.com/threads/386228-Xvid-1-3-5-(CLI)#post2619938

Thanks

[filler56789]

Nah, he posted the link for a reply to the thread

LigH surely needs more coffee :D

[LigH]

Strange. I was pretty sure I copied the link from the post... :o