xvid_encraw how to use pipe input?

[Selur]

Looking at 'xvid_encraw -help':
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert

xvid_encraw built at 20:58:26 on Apr 9 2020
Usage : xvid_encraw [OPTIONS]

Input options:
-i string : input filename (stdin)
-type integer : input data type (yuv=0, pgm=1, avi/avs=2) (0)
-w integer : frame width ([1.4096])
-h integer : frame height ([1.4096])
-csp string : colorspace of raw input file i420, yv12 (default)
-frames integer : number of frames to encode (all)

Output options:
-dump : save decoder output
-save : save an Elementary Stream file per frame
-o string : save an Elementary Stream for the complete sequence
-avi string : save an AVI file for the complete sequence

Rate control options:
-framerate float : target framerate (auto)
-bitrate [integer] : target bitrate in kbps (700)
-size integer : target size in kilobytes
-single : single pass mode (default)
-cq float : single pass constant quantizer
-pass1 [filename] : twopass mode (first pass)
-full1pass : perform full quality first pass (disabled)
-pass2 [filename] : twopass mode (2nd pass)
-max_key_interval integer : maximum keyframe interval (300)
-zones [zones] : use `-help zones' for usage guidelines
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight

Single Pass options:
-reaction integer : reaction delay factor (16)
-averaging integer : averaging period (100)
-smoother integer : smoothing buffer (100)

Second Pass options:
-kboost integer : I frame boost (10)
-kthresh integer : I frame reduction threshold (1)
-kreduction integer : I frame reduction amount (20)
-ostrength integer : overflow control strength (5)
-oimprove integer : max overflow improvement (5)
-odegrade integer : max overflow degradation (5)
-chigh integer : high bitrate scenes degradation (0)
-clow integer : low bitrate scenes improvement (0)
-overhead integer : container frame overhead (0)
-vbvsize integer : use vbv buffer size
-vbvmax integer : vbv max bitrate
-vbvpeak integer : vbv peak bitrate over 1 second

BFrames options:
-max_bframes integer : max bframes (2)
-bquant_ratio integer : bframe quantizer ratio (150)
-bquant_offset integer : bframe quantizer offset (100)

Other options
-noasm : do not use assembly optimized code (use)
-turbo : use turbo presets for higher encoding speed (don't use)
-quality integer : quality ([0..6]) (6)
-vhqmode integer : level of R-D optimizations ([0..4]) (1)
-bvhq : use R-D optimizations for B-frames (don't use)
-metric integer : distortion metric for R-D opt (PSNR:0, PSNRHVSM:1) (0)
-qpel : use quarter pixel ME (don't use)
-gmc : use global motion compensation (don't use)
-qtype integer : quantization type (H263:0, MPEG4:1) (0)
-qmatrix filename : use custom MPEG4 quantization matrix
-interlaced [integer] : interlaced encoding (BFF:1, TFF:2) (1)
-nopacked : disable packed B-frames mode (enabled)
-noclosed_gop : disable closed GOP mode (enabled)
-masking [integer] : HVS masking mode (None:0, Lumi:1, Variance:2) (0)
-stats : print stats about encoded frames (don't print)
-ssim [integer] : print ssim for every frame (accurate: 0 fast: 4) (2)
-ssim_file filename : output the ssim stats into a file
-psnrhvsm : print PSNRHVSM metric for every frame (don't print)
-debug integer : activate xvidcore internal debugging output (don't activate)
-vop_debug : print some info directly into encoded frames (don't print)
-nochromame : disable chroma motion estimation (enabled)
-notrellis : disable trellis quantization (enabled)
-imin integer : minimum I Quantizer (1..31) (2)
-imax integer : maximum I quantizer (1..31) (31)
-bmin integer : minimum B Quantizer (1..31) (2)
-bmax integer : maximum B quantizer (1..31) (31)
-pmin integer : minimum P Quantizer (1..31) (2)
-pmax integer : maximum P quantizer (1..31) (31)
-drop integer : frame Drop Ratio (0..100) (0)
-start integer : starting frame number (0)
-threads integer : number of threads (auto)
-slices integer : number of slices (1)
-progress [integer] : show progress updates every n frames (10)
-par integer[:integer] : set Pixel Aspect Ratio (1)
1 = 1:1
2 = 12:11 (4:3 PAL)
3 = 10:11 (4:3 NTSC)
4 = 16:11 (16:9 PAL)
5 = 40:33 (16:9 NTSC)
other = custom (width:height)
-help : print this help message

NB: You can define up to 8192 zones via both the -zones and the -z[qw] options as needed.
I assumed:
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -pix_fmt yuv420p -f rawvideo - | "I:\Hybrid\64bit\xvid_encraw.exe" -cq 3 -w 640 -h 352 -csp i420 -framerate 25 -o "E:\Temp\test.m4v"
should work, but it only gives me:
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert

xvidcore build version: xvid-1.3.7
Bitstream version: 1.3.7
Detected CPU flags: ASM MMX MMXEXT SSE SSE2 SSE3 SSE41 TSC
Detected 16 cpus, using 16 threads.
-1: key=0, time= 0, len= -5 | type=I, quant= 0, len= 0

Tot: enctime(ms) = 0.00, length(bytes) = 0
Avg: enctime(ms) = -1.00, fps =-1000.00, length(bytes) = -1
N frames: 1 frames, size = 0/ 0
as output.
The ffmpeg decoding part works fine. (saving to a file instead of piping properly saves yuv data)
I tried '-csp yv12', which didn't help.
I tried adding '-type 0', which didn't help.
I tried adding '-i stdin' or '-i -' but those aborted with 'Error opening input file stdin' and 'Error opening input file -'.

=> Does anyone know how to use xvid_encraw with pipe input?

Cu Selur

Ps.: I know when doing no filtering and the input is avi, directly using xvid_encraw might work, but I'd like to use vspipe and ffmpeg to pipe content to xvid_encraw.

[ChaosKing]

Try with -f yuv4mpegpipe instead of rawvideo.

[LigH]

@Selur:

I guess that xvid_encraw is unable to determine the number of frames of a pipe stream (because it cannot seek to the end of a file and possibly returns a size of 0 bytes), so you may have to add the number of frames explicitly as parameter...

@ChaosKing:

The sources of xvid_encraw don't look like Y4M header parsing is implemented. Even PGM header parsing appears in TODO's.

[Selur]

@LigH: adding '-frames 429'
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -pix_fmt yuv420p -f rawvideo - | "I:\Hybrid\64bit\xvid_encraw.exe" -cq 3 -w 640 -h 352 -csp i420 -frames 429 -framerate 25 -o "E:\Temp\test.m4v"
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert

xvidcore build version: xvid-1.3.7
Bitstream version: 1.3.7
Detected CPU flags: ASM MMX MMXEXT SSE SSE2 SSE3 SSE41 TSC
Detected 16 cpus, using 16 threads.
-1: key=0, time= 0, len= -5 | type=I, quant= 0, len= 0

Tot: enctime(ms) = 0.00, length(bytes) = 0
Avg: enctime(ms) = -1.00, fps =-1000.00, length(bytes)
doesn't help either. :/

@ChaosKing: yuv4mpegpipe doesn't work either and I agree with LigH doesn't seem like there's code to parse y4m headers.

[filler56789]

.............

@ChaosKing: yuv4mpegpipe doesn't work either and I agree with LigH doesn't seem like there's code to parse y4m headers.

Ouch, that suxxx indeed :eek:
I have just run a fast encoding test... yes, xvid_encraw reads Avisynth files, but does not accept the output(s) from avs2yuv :confused:
:-/

Anyway, that's not so unexpected from devilopers who think "nobody will ever need more than 64 zones" :rolleyes: and believe Cygwin still is relevant :D

[LigH]

So, @Selur, your best chance is probably to use Xvid inside ffmpeg...

[Selur]

@LigH: last time I checked ffmpeg doesn't support vhq and some other options. (iirc mbd is similar to vhq) -> I'll check that again just to be sure
So atm. I'm stuck with mencoder for xvid encoding.


Comparing https://www.ffmpeg.org/ffmpeg-codecs.html#libxvid and http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt mencoder clearly wins.
A few examples:

mencoder ffmpeg
vhq=<0-4> mbd=<simple,bits,rd>
qmin/qmin or I/P/B qmin/qmax same for all (or just I ?)
quant_intra/inter_matrix no custom matrix as far as I see

+ some more missing options in ffmpegs libxvid support.
=> It's a pain, but either I find a modified xvid_encraw or I'm stuck with mencoder.

Cu Selur

[Selur]

@LigH: since you got an environment setup where you can compile xvid, could you try to compile xvid_encraw with the source from squid_80 http://forum.mediacoderhq.com/viewtopic.php?p=6578&sid=ec823340d2ac72a210714de0c57709d7 ?
That source seems to define stdin for Windows, but the binary in that thread doesn't seem to work with current xvidcore.dll and the link to the xvidcore.dll which it should work with doesn't work anymore. :/

squid_80 (http://members.optusnet.com.au/squid_80/) also has a 64bit xvid_encraw and a xvid64bit but sadly that doesn't seem to work either.

----

experimenting with the xvid64 and xvid_encraw64 from squid_80:
.. | "C:\Users\Selur\Desktop\xvid_test\xvid_encraw.exe" -o "E:\Temp\test.m4v"
gives:
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Trying to retrieve width and height from input header
xvid [error]: Bad Framerate 0.000000 (25/1)

.. | "C:\Users\Selur\Desktop\xvid_test\xvid_encraw.exe" -w 640 -h 352 -o "E:\Temp\test.m4v"
gives:
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

xvid [error]: Bad Framerate 0.000000 (25/1)

.. | "C:\Users\Selur\Desktop\xvid_test\xvid_encraw.exe" -w 640 -h 352 -framerate 25 -o "E:\Temp\test.m4v"
gives:

xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

xvid [warn]: Single pass defaulting to quant 4.00
xvid [info]: Input is 640 x 352, 25.000fps (25/1), starting from frame 0
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected 16 cpus, using 16 threads.
3: key=0, time= 4, len= 3399 | type=I, quant= 4, len= 16093

this creates only one output frame.
same with:
.. | "C:\Users\Selur\Desktop\xvid_test\xvid_encraw.exe" -w 640 -h 352 -framerate 25 -frames 429 -type 0 -o "E:\Temp\test.m4v"

adding '-debug' doesn't work,... :(

... | "C:\Users\Selur\Desktop\xvid_test\xvid_encraw.exe" -w 640 -h 352 -framerate 25 -frames 2 -o "E:\Temp\test.m4v"
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

xvid [warn]: Single pass defaulting to quant 4.00
xvid [info]: Input is 640 x 352, 25.000fps (25/1), starting from frame 0
xvid [info]: Number of frames to encode: 2
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected 16 cpus, using 16 threads.
1: key=0, time= 2, len= 6 | type=I, quant= 4, len= 16093
-1: key=0, time= 0, len= -5 | type=P, quant= 4, len= 6

Tot: enctime(ms) = 4.00, length(bytes) = 16099
Avg: enctime(ms) = 2.00, fps = 500.00, length(bytes) = 8049
I frames: 1 frames, size = 16093/ 16093, quants = 4 / 4.00 / 4
N frames: 1 frames, size = 6/ 6
outputs 2 frames, using '-frames X' with X > 2 any I only get 1 frame :/

[filler56789]

Hummm, I have tried some modifications on xvid_encraws's code, but they didn't work as expected :-/
According to squid80's mod, adding "include io.h ++ include fcntl.h" apparently is sufficient only if the compiler = MSVC :-/
Evidently I replaced "MSVC" with "_WIN32" so that the recipe could be used by MinGW, but the effectivel «trick» is less simple than I thought.

[Kurtnoise]

I've got something working here using this build (https://filebin.net/yhha4b4gjpmp6ato/xvid-1.3.7.zip?t=hh8uvcek) within yuv4mpegpipe & stdin switches...

ffmpeg .... -f yuv4mpegpipe - | xvid -type 0 .... -i stdin -o output.m4v

[filler56789]

I've got something working here using this build (https://filebin.net/yhha4b4gjpmp6ato/xvid-1.3.7.zip?t=hh8uvcek) within yuv4mpegpipe & stdin switches...

:goodpost: and :thanks:

First, the good part :)

Now encraw.exe's -i stdin accepts the outputs from avs2yuv.

Secondly, the bad part :-/

encraw.exe swaps the chroma channels (U & V) :scared: when avs2yuv uses the -raw switch and does even worse things :eek: when avs2yuv doesn't use the -raw option.

My conclusion: now it should be clear that xvid_encraw is just an EXAMPLE application, not a production-model frontend. Therefore in my humble opinion trying to fix it is not worth the hassle :-/

By the way, and just for a comparison, the Theora fanboys were smarter for creating a frontend based on ffmpeg (ffmpeg2theora), instead of trying to reinvent the wheel.

[Selur]

output from:
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -pix_fmt yuv420p -f yuv4mpegpipe - | "C:\Users\Selur\Desktop\xvid-1.3.7\examples\xvid_encraw.exe" -cq 3 -i stdin -w 640 -h 352 -csp i420 -framerate 25 -o "E:\Temp\test.m4v"
looks fine here.
@filler5689: have you tried with '-csp i420'?

Cu Selur

Ps.: strange thing is that '-w 640 -h 352' is still required.

[filler56789]

@filler5689: have you tried with '-csp i420'?

You are right, with "-csp i420" the stupid EXE finally worked as expected.
As I always say, evil devilopers love to choose stupid :angry: default settings :D

Ps.: strange thing is that '-w 640 -h 352' is still required.

Lazy (lack of) coding, granted :p

[Selur]

Okay, somwhere I mixed stuff up,
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -i "F:\TestClips&Co\files\test.avi" -an -sn -pix_fmt yuv420p -f yuv4mpegpipe - | "C:\Users\Selur\Desktop\xvid-1.3.7\examples\xvid_encraw.exe" -type 0 -w 640 -h 352 -csp i420 -framerate 25 -frames 10 -i stdin -o "E:\Output\test.m4v"
doesn't work, but (using rawvideo):
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -i "F:\TestClips&Co\files\test.avi" -an -sn -pix_fmt yuv420p -f rawvideo - | "C:\Users\Selur\Desktop\xvid-1.3.7\examples\xvid_encraw.exe" -type 0 -w 640 -h 352 -csp i420 -framerate 25 -frames 10 -i stdin -o "E:\Output\test.m4v"
thought I copy&pasted the command line before, but apparently I didn't.

[Selur]

Argh,... now that xvid_encraw works MP4Box fails me.
A simple:
MP4Box -add "E:\Temp\2020-10-07@17_16_39_1610_01.m4v" -tmp "E:\Temp" -new "E:\Output\2020-10-07@17_16_39_1610__02.mp4"
gives me:
[Importer] Error probing E:\Temp\2020-10-07@17_16_39_1610_01.m4v
Error importing E:\Temp\2020-10-07@17_16_39_1610_01.m4v: Filter not found for the desired type

-> I opened an issue for it in the gpac bug tracker (https://github.com/gpac/gpac/issues/1609).


Cu Selur

[filler56789]

FWIW,
MP4Box - GPAC version 0.8.0-rev1-gc1990d5c-master is what I've been using since "ages ago".

Filter not found for the desired type

Evidently that happened because the GPAC guys became exceedingly-busy :rolleyes:

https://sourceforge.net/p/gpac/discussion/287546/thread/43881fa9/

[Selur]

Okay, muxing to mkv using mkvmerge (v51) doesn't work either,..
Seems like MPEG4 ASP raw streams are not supported by mkvmerge. (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/270)
iirc xvid_encraw doesn't use opendml so file size is limited to 2GB which kind of kills .avi as output for me. :/
So to mux to mp4 or mkv one either needs a xvid_encraw version which supports mkv or one needs to use ffmpeg for muxing,.. :/

[LigH]

MeGUI needs this workaround too: xvid_encraw doesn't create OpenDML AVIs >2GB (and MKV support is marginal, if enabled at all), so it has to create raw MPEG-4 ASP, and then it can't mux it with the optimal tools. Somehow, xvid_encraw is really only a test tool, not a production application.

As already mentioned: It may not even have a YUV4MPEG parser. Hence it doesn't expect any header.

@Kurtnoise: Is your magic available as patch, or may it not even work with GCC?

[Kurtnoise]

@Kurtnoise: Is your magic available as patch, or may it not even work with GCC?
here is the pach I did :
Index: xvidcore/examples/xvid_encraw.c
===================================================================
--- xvidcore/examples/xvid_encraw.c (revision 2196)
+++ xvidcore/examples/xvid_encraw.c (working copy)
@@ -38,6 +38,14 @@
* Use ./xvid_encraw -help for a list of options
*
************************************************************************/
+#ifdef _WIN32
+/* The following two defines must be located before the inclusion of any system header files. */
+#define WINVER 0x0500
+#define _WIN32_WINNT 0x0500
+#include <windows.h>
+#include <io.h> /* _setmode() */
+#include <fcntl.h> /* _O_BINARY */
+#endif

#include <stdio.h>
#include <stdlib.h>
@@ -350,6 +358,7 @@
double totalenctime = 0.;
float totalPSNR[3] = {0., 0., 0.};

+ FILE *in_file = stdin;
FILE *statsfile;
frame_stats_t framestats[7];

@@ -991,6 +1000,12 @@
if (avi_in_stream) AVIStreamRelease(avi_in_stream);
AVIFileExit();
}
+ else if (ARG_INPUTFILE == NULL || strcmp(ARG_INPUTFILE, "stdin") == 0) {
+#ifdef _WIN32
+ _setmode(_fileno(stdin), _O_BINARY);
+#endif
+ in_file = stdin;
+ }
else
#endif
{


Yes it works w/ gcc.

Sources including this patch are available in the package linked previously...

[LigH]

I'll suggest this to media-autobuild suite, including their previously applied sed patch for 8192 zones max.

[Selur]

side note:
- the GPAC Team fixed the muxing of MPEG-4 ASP raw streams (https://github.com/gpac/gpac/issues/1609), so MP4Box can be used to mux raw MPEG-4 ASP to mp4 again. :)
- Sadly Mosu is not interested to spend time on MPEG-4 ASP (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/270#note_425653157).

[filler56789]

Sadly Mosu is not interested to spend time on MPEG-4 ASP (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/270#note_425653157).

At least he has always been very honest, which surely is a good thing :cool:
Quite different from the gpackers who shamelessly lie about "lack of time" because they don't have the courage to say "give us N thousand US$s and only then we'll do what you want us to implement in our software".
ANYWAY: "everybody" :) creates ASP-in-AVI because "nobody" :p creates ASP-in-MP4, this the reason why ASP in Matroska by default uses the VfW-compatible mode instead of the "native" MPEG-4 mode ;)

- the GPAC Team fixed the muxing of MPEG-4 ASP raw streams (https://github.com/gpac/gpac/issues/1609), so MP4Box can be used to mux raw MPEG-4 ASP to mp4 again. :)

Just keep using the old builds of MP4Box, problem solved :)
What isn't broken doesn't have to be "upgraded" ;) :sly:

[LigH]

I made a combined patch (incl. MAX_ZONES 8192) that applies in MABS and got xvid_encraw built with GCC 10.2; unfortunately, it does not work when the -i parameter is omitted, but it works with -i stdin alternatively. Will upload it later in the VideoHelp forum (https://forum.videohelp.com/threads/386228-Xvid-1-3-5-(CLI)) (MediaFire likes to block files containing the string "xvid", I believe)...

@Kurtnoise: wiiaboo wondered if in_file is declared twice now.

[LigH]

The media-autobuild team is developing things further; the next release will work correctly without any -i parameter (and not need -i stdin nor support it anymore). They try to create a git fork from the current SVN so it takes a little while...

[filler56789]

The media-autobuild team is developing things further;
the next release will work correctly without any -i parameter (and not need -i stdin nor support it anymore).
They try to create a git fork from the current SVN so it takes a little while...

That looks promising :)
If the changes are big enough and good enough then it will be fair to give a new name to the application :sly:
I have never liked the "encraw" part and the underscore before it.
Something like "xvidencoder" would sound much better IMNSHO.

[Selur]

Personally I like encraw = enc raw = encode raw as a name or an application that is meant to encode to raw (in this case MPEG-4 ASP) video,...

[filler56789]

Personally I like encraw = enc raw = encode raw as a name or an application that is meant to encode to raw (in this case MPEG-4 ASP) video,...
okay...
#define XVID_AVI_OUTPUT
...
#ifdef XVID_MKV_OUTPUT
#include "matroska.cpp"
#endif
...
...
char *outavifilename; /* output avi filename */
char *outmkvfilename; /* output mkv filename */

:rolleyes: :D

[filler56789]

^ FOLLOW-UP:

one thing I have not understood yet...

¿why neither xvid_encraw nor x264 include an MP4 multiplexer in their respective source-codes? :confused:

I mean:
x264 by default is compiled with an FLV muxer and an MKV muxer, but if one wants an MP4 output, then they must first compile and install L-Smash or (blargh!)GPAC;
and
xvid_encraw doesn't even have such lazy option(s);;

then my question is:
¿is it that difficult to write a .C or .CPP file + a .H file dedicated to multiplex only ASP or AVC elementary streams to an MP4 container? :confused:

[LigH]

As already mentioned, xvid_encraw was rather merely a usage demonstration than a production application. The AVI muxer does not even create OpenDML, bad for target sizes >2 GB.

Talented developers are possibly able to create a really useful encoder application based on this. But ... how many people do still need MPEG4-ASP these days? So, how much efforts is such a tool worth now?

Anyway, MABS now uses its own fork: https://github.com/m-ab-s/xvid.git ... and AFAIK, MABS also supports private local patches in its profile system.

PS: MP4Box was recently fixed to support multiplexing raw MPEG4-ASP to MP4 again.

[filler56789]

@LigH: thanks for saying that my question is irrelevant :D

.......
Anyway, MABS now uses its own fork: https://github.com/m-ab-s/xvid.git ... and AFAIK, MABS also supports private local patches in its profile system.

Thanks for the URL as well. IF my lazyness is not too big then maybe :rolleyes: I will open some issues in their repository... for example, MABS did not remove the problematic mno-cygwin references in the makefile of the VfW DLL :facepalm_emoji:
...and to make things worse, they insist on the stupid and useless "miniconverter"
:unamused_emoji:
and like the original Xvidders, they don't care that the infamous "Bitrock InstallBuilder" installers cannot be unpacked by third-party applications.

[LigH]

Well, MABS forked the whole repo but in fact only uses what's required for the CLI EXE. The current setup does not even "install" the xvidcore.dll to the local output directories anymore.

[LigH]

:( wiiaboo scolded me, I was wrong where I mentioned ideas about adding features for xvid. This repo only exists for convenience to load xvid sources from using git instead of SVN, to build them in MABS. It is not an active fork for further development.

So if you want to contribute to xvid, you may have to register as xvid developer in their organization to obtain commit rights to their main SVN repo, or discuss contributions in their developer mailing list.

[filler56789]

:( wiiaboo scolded me, I was wrong where I mentioned ideas about adding features for xvid. This repo only exists for convenience to load xvid sources from using git instead of SVN, to build them in MABS. It is not an active fork for further development.

Thanks for the clarification.
Well, one thing that I would suggest to the MABS people is remove from their Xvid "mirror" everything that they don't use, such as the "xvidextras" and the VFW interface.

So if you want to contribute to xvid, you may have to register as xvid developer in their organization to obtain commit rights to their main SVN repo, or discuss contributions in their developer mailing list.

No, thanks, I'd better keep using DivX forever :)

«discuss contributions in their developer mailing list.»

Not even that. I cannot expect very much from programmers who think a miniconverter and a lousy installer are an excellent idea :(

DivX let's the user adjust the sensitivity of the the scene-change detection. This is a good idea that the Xvidders should have "copied" (I mean, implemented) ages ago, but they didn't, because they insist that the "zones" thing is an acceptable workaround.
:Person_Shrugging_Emoji: