Xvid 1.3.5 CLI issues

[Selur]

I'm calling:

"I:\workspace\Hybrid\debug\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p -vsync 0  -f rawvideo - | "I:\workspace\Hybrid\debug\64bit\xvid_encraw.exe" -turbo -bitrate 1500 -pass1 "E:\Temp\test.stats" -w 640 -h 352 -csp i420 -framerate 25.000 -o NUL

and get

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 on the console and the stats file only contains:

# XviD 2pass stat file (core version 1.3.7)
# Please do not modify this file

i 0 0 0 0 0 0

-> any idea what I'm doing wrong? (same happens with '-csp yv12')
Got an example of a working command line with pipe input?

Cu Selur

[Selur]

Shortening the calls to:

"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"

doesn't help either :/

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

Cu Selur

[LigH.de]

According to this doom9 post, try:

-i stdin

(not tested by me, being busy...)

[Selur]

Nope, that does not help:

"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 -i stdin -w 640 -h 352 -csp i420 -framerate 25 -o "E:\Temp\test.m4v"
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert

Error opening input file stdin

Cu Selur

[LigH.de]

When I call xvid_encraw with -i NUL (to get the version number only), I get the following error:

Wrong input format, I want YUV encapsulated in PGM

I hope that's a hint towards the reason...

A "pgmyuv" format for ffmpeg is mentioned, but documentation is sparse.

PS: I asked to get this discussion separated from the original "new version" thread.

[Selur]

I hope that's a hint towards the reason...

May be the pipe format needs to be something else,... ?

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)

Explicitly adding '-type 0' to the encraw call doesn't help either.

[Baldrick]

Discuss in this thread.

Download from https://forum.videohelp.com/threads/386228-Xvid-1-3-5-%28CLI%29

[LigH.de]

@Selur: Try ffmpeg -f pgmyuv and xvid_encraw -type 1 maybe?

[Selur]

@LigH:

"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -pix_fmt yuv420p -f pgmyuv - | "I:\Hybrid\64bit\xvid_encraw.exe" -cq 3 -type 1 -w 640 -h 352 -csp i420 -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.
Wrong input format, I want YUV encapsulated in PGM

Tot: enctime(ms) =   0.00,               length(bytes) =       0
Avg: enctime(ms) =  -1.00, fps =-1000.00, length(bytes) =      -1

here ffmpeg fails:

[NULL @ 000002026c727f40] Requested output format 'pgmyuv' is not a suitable output format
pipe:: Invalid argument

looking at 'ffmpeg -formats' there's no pgm format with 'Muxing support' in ffmpeg :/

[LigH.de]

True, pgmyuv is only a demuxer.

May be necessary to study the sources.

[Selur]

I hope, studying the source (http://websvn.xvid.org/cvs/viewvc.cgi/trunk/xvidcore/examples/xvid_encraw.c?view=markup) can be avoided,..

I opened a thread over at doom9s about it.
https://forum.doom9.org/showthread.php?t=181894

[LigH.de]

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...

[Selur]

Sadly, adding '-frames 429' didn't help either.

[El Heggunte]

Question: ¿does the problem also happens on Linux or Mac OS
I have just perused the source-code of xvid_encraw and unless I am very mistaken, it doesn't have pipe support on Windows

[Selur]

Question: ¿does the problem also happens on Linux or Mac OS

No clue, at least I haven't tested it since I do most of the encoding I do on Windows.
(I guess named pipes might work on Linux, Mac and may be even on Windows, but I'd really like to avoid using them. )

[El Heggunte]

Ooops, it seems I didn't express myself clearly

I wrote "pipe", but I actually meant «stdin» =^.^=

[Selur]

looking at the source of xvid_encraw from http://forum.mediacoderhq.com/viewtopic.php?p=6578&sid=ec823340d2ac72a210714de0c57709d7 it looks like that version might work but it probably needs to be compiled against the current xvid version since the xvid_encraw binary does not seem to work with the current version,.. (or I'm doing something wrong)

Over at squid_80s site (http://members.optusnet.com.au/squid_80/) there is a xvid_encraw64 and xvid64 but I can't get them to work.

[El Heggunte]

looking at the source of xvid_encraw from http://forum.mediacoderhq.com/viewtopic.php?p=6578&sid=ec823340d2ac72a210714de0c57709d7 it looks like that version might work but it probably needs to be compiled against the current xvid version since the xvid_encraw binary does not seem to work with the current version,.. (or I'm doing something wrong)

Thanks for the useful info , later I will modify the current/latest xvid_encraw.c, if it works in here then I will share the g0ddamn binary.

[Selur]

Thanks!
---

got it working somehow a bit:

| "C:\Users\Selur\Desktop\xvid_test\xvid_encraw.exe" -w 640 -h 352 -framerate 100 -frames 2 -type 0 -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, 100.000fps (100/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

problem is I only get 2 frames as output (+ that version is really old)
(using a frames X with X more than two I only get one)

-> hoping that it works with a modified xvid_encraw.c and a current xvidcore.dll

[El Heggunte]

Ganz leicht ist es nicht

https://forum.doom9.org/showthread.php?p=1925174#post1925174

[Selur]

:/

[El Heggunte]

Fortunately Kurtnoise chimed in and fixed the stdin issue of the encraw.exe

https://forum.doom9.org/showthread.php?p=1925197#post1925197

[Selur]

Yup, strange thing is I'm pretty sure I had an xvid_encraw back in the days that worked properly with yuv4mpegpipe, but having rawvideo pipe support is good enough.
Hopefully whenever someone again changes something in the code he also adds some error message when there is a parameter that can't be parsed (due to a typo or similar).

[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

Ps.: mkvmerge doesn't support MPEG-4 ASP raw streams either :/ (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/270)
-> so ffmpeg seems to be the only tools that currently can remux such streams to mkv/mp4

[LigH.de]

Yes, that's the reason why 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.

[Selur]

Side note: GPAC folks fixed the muxing issue in MP4Box

[LigH.de]

Nice, to be reported to MeGUI then...

[Selur]

Update: Now works without any -i parameter (and -i stdin is not recognized anymore).

ideally both should work
But thanks for looking into it!

Cu Selur

[LigH.de]

If you need both, then you will have to convince wiiaboo in the Pull Request on github that he patches the alternative handling back in...

[Selur]

don't really 'need' both just think it's more consistent.
Personally I would prefer '-' for stdin
-> no biggy

Cu Selur