xvid_encraw - Patched with AviSynth input support

[S_O]

I already made a more or less working of xvid_encraw with AviSynth input support (I simply copied the code from avs2yuv) several month ago (when 1.1.0 beta1 was released), but I somehow borked the source and I never published it.
Now I copied the changes into XviD 1.1.0 beta2, but more cleanly now and did some other changes:
-Added VBV-Buffer options (don´t ask me how to use them - I have no idea)
-Disabled the statistic display for every frame by default
-Added progress display
-Added stats at the end that displays how many I/P/B/S-VOPs with avg. quant and size.

How to use it:
For example: xvid_encraw -i script.avs -type 2 -asm -quality 6 -qpel -single -bitrate 1000 -max_bframes 2 -o rawmpeg4.m4v
For mor details use xvid_encraw -h
It only outputs raw streams, no MP4! You can use mp4box to mux the stream into mp4:
mp4box -add rawmpeg4.m4v video.mp4

Known bugs:
-Time/fps in statistics is ..hmm.. not realistic (I don´t know if I introduced the bug or if it has always been there)
-With B-Frames enabled stat says that more than 100% of the source frames were encoded.

If you like to compile it yourself using VC++, copy the xvid_encraw.cpp and the avs2yuv-dir in the examples-dir of xvidcore, open the main project, delete the xvid_encraw.c from the xvid_encraw project and add xvid_encraw.cpp.

I noticed another problem (not in this release): I had many for me unexplainable bugs in stats display, every time I fixed one another display broke. I hunted bugs over 3 hours. I couldn´t explain why a the value of variable which I set to 0 is somewhere else outputted as 875644. But when I add messagebox in between, that displays another value - it works.
I fixed the problem by changing compiler from "Optimize for speed" to "Standard" (this has only affected the frontend, not xvidcore.dll). Now it works exactly as it´s supposed to work. I don´t know if I write crappy code or Microsoft crappy compilers... (or both)

Edit: Release 3 is ready:
for changes goto:
http://forum.doom9.org/showthread.php?p=698181#post698181
http://forum.doom9.org/showthread.php?p=698555#post698555
Attachment has been approved by Koepi, please download and test, and post here how it works for you (or if you have found any bugs).

[Doom9]

thank you. Now we just need somebody to pick up the slack and add the missing options and this will be an awsome tool.

[Sirber]

Once more stable, I will add it to RealAnime :D Keep the good work!

[S_O]

thank you. Now we just need somebody to pick up the slack and add the missing options and this will be an awsome tool.What options are missing exactly? I´ll try to add them.
Once more stable, I will add it to RealAnime Keep the good work!Thanks

Edit: I yust looked into xvid.h and the vfw interface, there are lot´s of options missing. I´ll try to add them.

[Sirber]

Can mkvmerge merge M4V stream into MKV?

[Doom9]

What options are missing exactly?
interlaced: bff
quantization type
adaptive quantization
par
1 pass mode: reaction delay factor, averaging period, smoother
2 pass mode, 2nd pass: iframe boost, iframes closer than, reduced by, overflow control strength, max overflow improvement, max overflow degradation, high bitrate scenes degradation, low bitrate scenes improvement
vhq mode
vhq for b-frames
chroma motion
turbo
frame drop ratio
trellis
min/max quantizer for i/p/b frames
and zones also have: begin with keyframe, cartoon mode, grayscale, chroma optimizer and bvop sensitivity
last but not least custom quantization matrices

phew, quite a long list, isn't it?

[S_O]

Can mkvmerge merge M4V stream into MKV?No, but it shouldn´t be that difficult to add.

It seems that xvid.h offers much more options than the vfw-interface uses (some of them might be grouped toghether). I´ll try to add all.

Edit: @Doom9: The list is even longer.

[Doom9]

I'd have some more ideas but I'll keep them to myself for now, as I've already flooded you.

[Sirber]

Well, thanks a lot for your efforts! I won't bug you longer either :)

[bond]

really great stuff, thx a lot! :)

[S_O]

I yust noticed that the quality presets automatically activate features. At quality 6 for example Trellis, Inter4MV, Halfpel and Chroma Motion are always used.

Yust for curiosity: It seems that XviD allows a new Quant Matrix at every I-VOP (if I read the code correctly I can even force a new quant matrix without a new I frame).
In theory it should be possible if the VOL would be written again. But for seeking, the VOL should be repeated at every I-VOP, otherwise the decoder would need to scan the entire file back until it finds a quant matrix.
Is that allowed by the specs? Also I found informtion how inverse quantisation with the different methods work (H.263; MPEG) and how this is indicated in the bitstream, I couldn´t find one sentence saying it is allowed or not (maybe it´s more general, like "VOL is not allowed to change in a stream"). I remember XviD had an option some time ago to automatically switch between H.263 and MPEG quant, but it was removed, because its not ISO compliant. Where in the specs is that written? In theory, where a VOL can be (are they only allowed in front of a I-VOP?), there could be new quantisation.

[sysKin]

maybe it´s more general, like "VOL is not allowed to change in a stream"Yes this is exactly it. I don't remember where it is exactly, but although VOL can be repeated accross the stream, it must not change.

[edit]oh, I almost forgot: great work, I'll commit it to cvs when it's ready :)

[bond]

as syskin said its not allowed to have varying vols

eg when placing the raw m4v stream in .mp4 the vol is placed only once in the file (as it cant change anyways) and its also not placed together with the i-frames

[IgorC]

it's sumary usefull tool. Many settings were mentioned to apply. And Full quality first pass?
I don't care much about -debug , but it crashes here.

-bitrate (bps) . -bitrate 800000 . NOT -bitrate 800

[multicone]

Can this tool be patched with Haali MKV writing lib from x264, so it will write native MPEG4 MKV ?

[Doom9]

@multicone: sure... are you volunteering your time? We've dumped too many things on poor S_O already.. I have a feeling the more it gets the more likely it'll never get done - it's kinda annoying to have a classroom full of people clamoring I want this and that ;)

[S_O]

Ok, that´s all switches I want to implement, have I missed something (except zones). Note that the description is either taken from vfw or directly from xvid.h, what means I don´t what they are all good for. I also reorderd them in the help display:
Input options:
-i string : input filename (default=stdin)
-type integer: input data type (yuv=0, pgm=1, avisynth=2)
-w integer: frame width ([1.2048])
-h integer: frame height ([1.2048])
-frames integer: number of frames to encode

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

Bitstream options:
-prf profile : indicated profile ([S0.S3] or [AS0.AS5])
(default=unrestricted)
-par aspect_ratio : pixel aspect ratio ([VGA11; PAL43; NTSC43; PAL169;
NTSC169]) (default=VGA11)
-custom_par X Y : custom pixel aspect ratio
-divx_ud : write DivX-userdata
-vol_ivop : repeat VOL at every I-VOP

General encoding options:
-quality integer: quality ([0..6]) presets
-hqacp : high quality ac prediction
-inter4v : use 4 motion vectors per MB
-gmc : use global motion compensation
-interlaced : use interlaced encoding (this is NOT a deinterlacer!)
-i_tff : top field first (interlaced encoding)
-i_alt : alternate scan (interlaced encoding)
-reduced_res : enable reduced resolution
-force_rrv : force all frames to be reduced resolution
-greyscale : greyscale mode, all chroma is ignored
-cartoon : use 'cartoon' mode
-chroma_opt : enable chroma-optimizer pre-filter
-frame_drop integer: frame drop ratio (in percent)

BFrames options:
-max_bframes integer : max bframes (default=0)
-bquant_ratio integer : bframe quantizer ratio (default=150)
-bquant_offset integer : bframe quantizer offset (default=100)
-packed : packed mode (DO NOT USE! WILL CORRUPT OUTPUT!)
-closed_gop : closed GOP mode

Rate control options:
-framerate float : target framerate (>0 | default=25.0)
-bitrate integer : target bitrate
-single : single pass mode
-pass1 filename : twopass mode (first pass)
-pass2 filename : twopass mode (2nd pass)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-max_key_interval integer : maximum keyframe interval

Single Pass options:
-cquant float : target quantizer (use instead of bitrate)
-reac_delay integer : reaction delay factor
-avg_period integer : averaging period
-smoother integer : smoother

Pass 1 of 2 options:
-full_1p : Full first pass

Pass 2 of 2 options:
-size integer : target size of video (use instead of bitrate)
-keyframe_boost integer : keyframe boost (in percent)
-close_i_red intA intB : I frames closer than A frames are reduced by B%
-ccp_high integer : high bitrate degradation (in percent)
-ccp_low integer : low bitrate improvement (in percent)
-max_oi integer : max overflow improvement (in percent)
-max_od integer : max overflow degradation (in percent)
-overf_cs integer : overflow control strength (in percent)
-dxn_prf profile : apply DXN-Profile ([HH; PPAL; PNTSC; HTPAL;
HTNTSC; HDTV])
-vbv_size integer : buffer size (bits)
-vbv_initial integer : initial buffer occupancy (bits)
-vbv_maxrate integer : max processing bitrate (bps)
-vbv_peakrate integer : max average bitrate over 3 seconds (bps)

Zone options:
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight

Quantization options:
-iquants min max : I-frame quantizer restriction ([1.31])
-pquants min max : P-frame quantizer restriction ([1.31])
-bquants min max : B-frame quantizer restriction ([1.31])
-trellis : use trellis based R-D "optimal" quantization
-mpeg_quant : use MPEG quantization instead of H.263
-mpeg_cqm filename : use custom MPEG quantization matrix (intra & inter)
-mpeg_intra_cqm filename : use custom MPEG quantization matrix (intra only)
-mpeg_inter_cqm filename : use custom MPEG quantization matrix (inter only)
-lumimasking : use lumimasking/adaptive quantization algorithm

Motion estimation options:
-hpel : use half pixel ME
-qpel : use quarter pixel ME
-chromap : use P-Frame chroma for ME
-chromab : use B-Frame chroma for ME
-me_advd16 : use advanced diamonds as search pattern
-me_advd8 : use advanced diamonds for extended 8x8 search
-me_sqr16 : use squares as search pattern
-me_sqr8 : use squares for extended 8x8 search
-me_hpelr16 : enable halfpel refine 16
-me_qpelr16 : enable quarterpel refine 16
-me_hpelr8 : enable halfpel refine 8
-me_qpelr8 : enable quarterpel refine 8
-me_gmer : enable GME refine
-me_exts16 : extend PMV by more searches
-me_exts8 : extended 8x8 search

Rate disortion options:
-vhq integer : R-D presets ([1.4])
-rated : enable R-D
-rd_simple : use simplified R-D mode decision
-rd_bf : enable R-D for B-frames
-rd_hpelr16 : use R-D halfpel refine 16
-rd_qpelr16 : use R-D quarterpel refine 16
-rd_hpelr8 : use R-D halfpel refine 8
-rd_qpelr8 : use R-D quarterpel refine 8
-rd_chk_pred : check vector equal to prediction
-rd_exts : perform R-D-based search using square patterns

Turbo options:
-turbo : turbo preset
-t_fr16 : low-complexity 16 refinement
-t_fr8 : low-complexity 8x8 sub-block refinement
-t_skipds : skip b-frame delta search
-t_fmi : partly skip interpolate mode
-t_bfes : stop b-frame search early
-t_dsm : detect stationary scenes

Other options
-asm : use assembly optmized code
-stats : print stats about encoded frames
-debug : activates xvidcore internal debugging output
-vop_debug : print some info directly into encoded frames
-help : prints this help message

NB: You can define 64 zones repeating the -z[qw] option as many times as needed.Please tell if I seem to have forget anything.
I´ll have a look how to add zones properly, with the flexibility to change all parameters that are allowed by the specs and are possible with xvid.
All the extended zone stuff (cartoon, greyscale, b-vop threshold...) is handled directly by the vfw and not by xvidcore and manually applied every frame.

Is there only one format for quant-matrix (I don´t know the english plural of matrix), the raw format (128 Byte)?
I don't care much about -debug , but it crashes here.Was it the last parameter in your commandline? It seems to requires some kind of argument, but it doesn´t check if there is one.
Can this tool be patched with Haali MKV writing lib from x264, so it will write native MPEG4 MKV ?There was C++ class for matroska writing once (based on libebml/libmatroska), i don´t know if it´s still up-to-date. It should be rather simple to add mkv support with it (as compile time option like avisynth).
eg when placing the raw m4v stream in .mp4 the vol is placed only once in the file (as it cant change anyways) and its also not placed together with the i-framesThat would of course brake changing quant-matrix.

Edit: I´m yust thinking that the option -asm should become -noasm, because most probably want to use asm and many will forget to set -asm.

[S_O]

@multicone: sure... are you volunteering your time? We've dumped too many things on poor S_O already.. I have a feeling the more it gets the more likely it'll never get done - it's kinda annoying to have a classroom full of people clamoring I want this and thatCurrently I have (summer!?) holidays (also temperature is more like autumn) and so I have time.
I´ll first add all the other stuff before I start thinking about mkv.

[bond]

Please tell if I seem to have forget anything.hm the -packed option should be removed, as it only borks the stream with raw output

afaik the reduced resolution option is borked too, but i dunno the details

the dxn profiles should be grouped together with the normal profile settings, as its not possible to have both, a mpeg-4 and a dxn profile
the point of profiles is (dis)allowing specific options and setting the vbv (and setting the profile/level indication in the stream of course)
so if the tool isnt able to take this into account when the user sets a profile its better to not allow the setting of the profiles at all (and leave this up to a gui)

I´ll have a look how to add zones properly, with the flexibility to change all parameters that are allowed by the specs and are possible with xvid.probably its a good idea to allow the same features to be set via zones as the vfw gui allows
most things (like qpel, gmc, matrix aso) are not allowed to vary in the stream anways

Is there only one format for quant-matrix (I don´t know the english plural of matrix), the raw format (128 Byte)?yes, there is
if you search around you will find lots of cqm for xvid (i assume the vfw code handles the parsing of these)
people definitely dont use different cqm files for inter and intra

[S_O]

the dxn profiles should be grouped together with the normal profile settings, as its not possible to have both, a mpeg-4 and a dxn profile
the point of profiles is (dis)allowing specific options and setting the vbv (and setting the profile/level indication in the stream of course)
so if the tool isnt able to take this into account when the user sets a profile its better to not allow the setting of the profiles at all (and leave this up to a gui)
What I thought by separating the DXN profiles from the normal one:
The normal profiles are indicated in the VOL, DXN are not. So I can apply a DXN profile which restricts VBV buffer while at the same time the stream can be marked as AS@L3. This can be perfectly fine, if the encoding parameters are reduced to the least common denominator.
Also profile indication cannot be left to gui (except DXN), since it´s stored in the bitstream and xvidcore does not automatically set the profile, xvid_encraw (or vfw) has to tell it which profile to indicate. Currently it is hardcoded to AS@L4 (better would have been unrescricted, I haven´t done it), xvidcore doesn´t care if the stream complies to it or not. If I set profile to 0xc4, it probably won´t complain either. This is yust 1 byte information in the bitstream. It´s up to the interface if it checks the parameters to profile compliance and xvid_encraw currently does not. But I´ll add a warning if a profile is indicated thoghether with a not compliant feature.
probably its a good idea to allow the same features to be set via zones as the vfw gui allows
most things (like qpel, gmc, matrix aso) are not allowed to vary in the stream anwaysIt seems that many things like turbo, ME options, trellis, some rd options, force reduced resolution can be chnaged during encode, but of course the most important things are the ones included in vfw.
hm the -packed option should be removed, as it only borks the stream with raw outputYes, you´re probably right. Also I added a warning, people might think "do not use - this must be the expert-only switch for super-high-ultra-quality, yust like -k is in lame"
if you search around you will find lots of cqm for xvid (i assume the vfw code handles the parsing of these)
people definitely dont use different cqm files for inter and intraAll I found were the normal 128 byte files, which xvid vfw seems to handle.
I also haven´t found different files for intra/inter, but maybe somebody only wants to use a custom inter matrix and leave the intra matrix untouched, or use intra and inter from different files. I´ll add it this way:
Intra/inter-matrix: only 128 byte files accepted
intra-matrix only: 64/128 byte files accepted, for 128 byte first matrix will be used.
inter-matrix only: 64/128 byte files accepted, for 128 byte second matrix will be used.
What I originally meant, there is no format containing several cqms with the names, designed goals etc. stored in the file, only raw.

[bond]

What I thought by separating the DXN profiles from the normal one:
The normal profiles are indicated in the VOL, DXN are not. So I can apply a DXN profile which restricts VBV buffer while at the same time the stream can be marked as AS@L3. This can be perfectly fine, if the encoding parameters are reduced to the least common denominator.
Also profile indication cannot be left to gui (except DXN), since it´s stored in the bitstream and xvidcore does not automatically set the profile, xvid_encraw (or vfw) has to tell it which profile to indicate.well people could set a mpeg-4 profile (like simple profile) together with a dxn profile (using for example b-frames) which wouldnt fit

i think the way how its handled currently in vfw is fine: set the mpeg-4 profile being equivalent to the dxn profile
eg dxn home theather profile is equivalent to asp@l5 (it makes no sense to allow a different mpeg-4 profile to be set)

Currently it is hardcoded to AS@L4 (better would have been unrescricted, I haven´t done it), xvidcore doesn´t care if the stream complies to it or not. If I set profile to 0xc4, it probably won´t complain either. another easy possible way would be to signal simply always the highest possible profile: asp@l5

This is yust 1 byte information in the bitstream. It´s up to the interface if it checks the parameters to profile compliance and xvid_encraw currently does not. But I´ll add a warning if a profile is indicated thoghether with a not compliant feature.well i am no dev, but if encraw is already able to detect that a feature is not part of the set profile, how much work would it be to disable this feature automatically?

[yokem55]

Is there a way to build this on linux? I don't need the avs input as setting up mencoder to dump into a raw yuv fifo works fine, but the extra options would be nice to have available/play with.

[S_O]

Is there a way to build this on linux? I don't need the avs input as setting up mencoder to dump into a raw yuv fifo works fine, but the extra options would be nice to have available/play with.Yes, that will be possible, you yust need to delete/comment "#define AVISYNTH_INPUT" at the beginning.
well people could set a mpeg-4 profile (like simple profile) together with a dxn profile (using for example b-frames) which wouldnt fit

i think the way how its handled currently in vfw is fine: set the mpeg-4 profile being equivalent to the dxn profile
eg dxn home theather profile is equivalent to asp@l5 (it makes no sense to allow a different mpeg-4 profile to be set)What I mean is, that DXN restriction is partly different than the normal is (VBV buffer), and DXN profiles also only work in 2pass mode, because the vbv restriction stuff is part of the 2pass-plugin. With single pass the output probably won´t comply to the DXN specs.
That´s why I added the DXN stuff to 2pass mode in help: It only makes sense there! And the iso profiles are added to bitstream options and described "indicate profile", because it´s yust one byte in the VOL for xvidcore. I can set this byte to whatever I like (except to 0, then xvidcore sets it automatically):

if reduced_resolution -> ARTS@L4
if GMC or QPEL -> ASP@L5
everything else will get SP@L3

that´s all. In other words when I create a stream 60fps, 1440x960 with 3 bframes at 4mbps, it will automatically get SP@L3 (max: 352x288; 15fps; 384kbps; no b-frames).
The switch is yust to set the byte, not to force the profile. Of course, that means files with a wrong profile may be created, but that can happen with vfw as well, because it also doesn´t check everything.
But I will add a warning, like with " -dxn_prf XY -prf AS5 -par PAL43 -reduced_res":
Warning: Aspect Ratio for DXN-Profiles must be VGA 1:1. Stream will not comply to DXN XY Profile
Warning: Reduced resolution is not supported by Profile AS@L5. Stream will not comply to indicated profile!

Unfortunately I have no complete list of the profiles and their ids. There is a list here http://www.m4if.org/resources/profiles/ with more than 50 profiles/levels (like "Core Studio" or "Advanced Core"). Unfortunately the ids are not included.

well i am no dev, but if encraw is already able to detect that a feature is not part of the set profile, how much work would it be to disable this feature automatically?encraw is not able to detect it, I have to tell him what complies to specs and what not. Of course I can also disable stuff like Qpel, GMC or B-Frames or reduce bitrate, but fps or frame size is not easy to change (and vfw doesn´t check that either).

[bond]

What I mean is, that DXN restriction is partly different than the normal is (VBV buffer), and DXN profiles also only work in 2pass mode, because the vbv restriction stuff is part of the 2pass-plugin. With single pass the output probably won´t comply to the DXN specs.
That´s why I added the DXN stuff to 2pass mode in help: It only makes sense there!exactly the same goes for the mpeg-4 profiles...
i dunno if you know it but if you signal asp@level5 you also have to use the vbv if you want to be spec compliant...
the mpeg-4 profiles/levels influence the vbv too, not only the encoding options. basically the dxn profiles are private mpeg-4 profiles, nothing less, nothing more

check out what mpeg-4 profile/level gets signalled when a dxn profile is set! afaik the dxn home theater profile sets the asp@l5 profile/level, now what if the user additionally tries to set a different mpeg-4 profile/level
it doesnt make sense to seperate the two and its also not differentiated in the vfw gui

again, checkout how things are handled in xvid vfw! its uptodate and the people who wrote the vfw codec knew what they did (cause after all practically the xvid codec is the vfw codec)

another point showing this i brought up before too, which you seem to ignore, is that reduced resolution is not working correctly in xvid
the code might still be there but if you look at the vfw gui you will see that reduced resolution (and the arts profile) is not available, this also happens for a reason

And the iso profiles are added to bitstream options and described "indicate profile", because it´s yust one byte in the VOL for xvidcore. I can set this byte to whatever I like (except to 0, then xvidcore sets it automatically):

if reduced_resolution -> ARTS@L4
if GMC or QPEL -> ASP@L5
everything else will get SP@L3

that´s all. In other words when I create a stream 60fps, 1440x960 with 3 bframes at 4mbps, it will automatically get SP@L3 (max: 352x288; 15fps; 384kbps; no b-frames).
The switch is yust to set the byte, not to force the profile. Of course, that means files with a wrong profile may be created, but that can happen with vfw as well, because it also doesn´t check everything.no, with vfw this cant happen, as the gui doesnt let the user enable incompliant settings (of course framerate, bitrate and resolution gets ignored, but i dunno any player which cares about these three)

But I will add a warning, like with " -dxn_prf XY -prf AS5 -par PAL43 -reduced_res":
Warning: Aspect Ratio for DXN-Profiles must be VGA 1:1. Stream will not comply to DXN XY Profile
Warning: Reduced resolution is not supported by Profile AS@L5. Stream will not comply to indicated profile!

encraw is not able to detect it, I have to tell him what complies to specs and what not. Of course I can also disable stuff like Qpel, GMC or B-Frames or reduce bitrate, but fps or frame size is not easy to change (and vfw doesn´t check that either). ok but here is my point: how hard is it to make xvid automatically disable incompliant settings? i mean if you already have the goodie implemented that it tells the user that a chosen setting is incompatible

something like a message saying "b-frames disabled as not complying with chosen profile/level"

[S_O]

no, with vfw this cant happen, as the gui doesnt let the user enable incompliant settings (of course framerate, bitrate and resolution gets ignored, but i dunno any player which cares about these three)
I yust tested and confirmed result in hexeditor:
Set profile to unrescricted, enable some ASP features (except Qpel / GMC) like B-Frames and mpeg quant, now encode your file:
The stream is marked as SP@L3 also it contains B-Frames and MPEG quantization!

In my opionen the best place for automatic profile decision is xvidcore, not the frontend.
i dunno if you know it but if you signal asp@level5 you also have to use the vbv if you want to be spec compliant...
the mpeg-4 profiles/levels influence the vbv too, not only the encoding options. basically the dxn profiles are private mpeg-4 profiles, nothing less, nothing moreSeems you are right, I thought the ISO profiles were yust limiting encoding features and fps/bitrate/resolution and that´s why DXN introduced their profiles.
But since they both have this vbv stuff you are of course right and separating doesn´t makes much sense.
But I wouldn´t call them "private profiles", because they are not indicated in bitstream, if they were using some reserved values to indicate their profiles this trem would be adequate, but in my opinion it´s yust some extra rescrictions for DXN promotion that do not interfere with the ISO standard at all.
dxn home theater profile sets the asp@l5 profile/levelNo, it is set to "auto-detect" by xvidcore (see vfw source (config.c, line 149) and xvidcore-source (bitstream.c, line 1076 - 1117)!), which means, if you don´t use Qpel/GMC it´s marked as SP@L3.
another point showing this i brought up before too, which you seem to ignore, is that reduced resolution is not working correctly in xvid
the code might still be there but if you look at the vfw gui you will see that reduced resolution (and the arts profile) is not available, this also happens for a reasonSorry, I must have missed that sentence. In case it´s not working correctly it should of course be removed.
The reason why reduced resolution has been removed:
From sysKin:
* it's now a long time we planned removing support for RRV as it
adds complexity to the ME, to the decoder and this feature fits
nowhere in any MPEG4 profile we plan to support.I don´t know if it has only been removed from vfw yet, or if it´s already removed (or will be ever removed) from xvidcore and only the flags are still there.
again, checkout how things are handled in xvid vfw! its uptodate and the people who wrote the vfw codec knew what they did (cause after all practically the xvid codec is the vfw codec)That´s what I do all the time, and as far as I can tell you, profiles are not handled perfectly (see demonstration at the beginning of this post)
ok but here is my point: how hard is it to make xvid automatically disable incompliant settings? i mean if you already have the goodie implemented that it tells the user that a chosen setting is incompatible

something like a message saying "b-frames disabled as not complying with chosen profile/level"As already said, in my opionen the best way to handle this would be if xvidcore checks the features and automatically sets the profile. That ensures that every frontend sets the right profile.
When profile is set by frontend xvidcore yust confirms that the encoding features are allowed by the profile, and in case not allowed features are used it refuses to encode and exits (except and override flag is set like "XVID_VOL_IGNOREPROFILE").

The question is now: What profile has to be set when no profile matches the encoding features? The maximum resolution even for AS@L5 is 720x576.

[sysKin]

RRV has been removed from xvid 1.1. Flags will stay, so that API remains backward compatible with 1.0's API.

[bond]

I yust tested and confirmed result in hexeditor:
Set profile to unrescricted, enable some ASP features (except Qpel / GMC) like B-Frames and mpeg quant, now encode your file:
The stream is marked as SP@L3 also it contains B-Frames and MPEG quantization!hm, thats not good :/

As already said, in my opionen the best way to handle this would be if xvidcore checks the features and automatically sets the profile. That ensures that every frontend sets the right profile.indeed, but i assume its hard to code taking everything into account
and than there is the issue of enforcing the vbv too (but i assume the profile code can do that already, at least in the case of the dxn profiles its a must, or is this done by the vfw gui?)

When profile is set by frontend xvidcore yust confirms that the encoding features are allowed by the profile, and in case not allowed features are used it refuses to encode and exits (except and override flag is set like "XVID_VOL_IGNOREPROFILE").cool

The question is now: What profile has to be set when no profile matches the encoding features? The maximum resolution even for AS@L5 is 720x576. well i would simply ignore the framerate and resolution issue, cause i really dunno any player who needs this to be correct

if you ignore the two than the profile to be set should be imho simply asp@l5, cause it covers everything (except reduced resolution, which is borked anyways)

[S_O]

RRV has been removed from xvid 1.1. Flags will stay, so that API remains backward compatible with 1.0's API.Unfortunately this is not written in xvid.h. The flags are there yust like all others, without any notice that they are only for compatibility and rrv doesn´t work. Also there is still code inside xvidcore to deal with rrv, the function BitstreamWriteVolHeader checks for rrv being enabled and sets the flags in bitstream.
and than there is the issue of enforcing the vbv too (but i assume the profile code can do that already, at least in the case of the dxn profiles its a must, or is this done by the vfw gui?)Yes, everything is done by the frontend, xvidcore doesn´t know at all a DXN profile is applied (it doesn´t even know that they exist).
When a profile is selected, vfw enables/disables the features in the dialog and sets the vbv buffer stuff (and for DXN profile also maximum peak-bitrate). In case of ISO profiles it also sets the profile id (the 5th byte in a raw stream, directly after the video object sequence start code).
Without 2pass mode the vbv buffer is not set, since this feature is part of 2pass plug-in.
well i would simply ignore the framerate and resolution issue, cause i really dunno any player who needs this to be correct

if you ignore the two than the profile to be set should be imho simply asp@l5, cause it covers everything (except reduced resolution, which is borked anyways)OK, I yust looked in the specs and this page: http://www.m4if.org/resources/profiles/ again. fps is nowhere mentioned, and resolution is called "typical resolution" not "maximum resolution". In other words, we don´t need to care about that. Unfortunately I can´t find ISO 14496-2 AMD2 containing advanced simple profile defiition.
If I get a full definition of the profiles I´ll see how difficult it is to implement working auto-profile setting in xvidcore.

Oh, in case you haven´t notice: I uploaded a new version (contains only changed files, if you do not have XviD 1.1 installed you need xvidcore.dll from zip of first post).
Chnages:
Lot´s of (nearly all) options added. See -h for details. You may notice that some options are not -xy but +xy: "+" means enable, "-" disable. So you can use presets (-quality, -vhq, -turbo), but you can easily disable some options again like "-quality 6 -trellis", means use -quality 6 (which enables trellis), but disable trellis. Disable switches always override enable switches.
I also added this switches, because I have an idea how to handle advanced zones and there I also need them.

Note 1: cartoon is not exactly the same here and in vfw! When you check cartoon in vfw, it enables cartoon mode and "detect static motion". So "+cartoon +t_dsm" equals vfw cartoon mode (I may change it to avoid confusion).

Note 2: I coded several hours and did one test. I mean one 30 sec clip (but that was fine). So the chances for bugs are very high. Consider this as very alpha. And please report all bugs here. The frame display is not yet fixed. And I said the encoding time is screwed up: It´s not: It´s _only_ the encoding time. If encoding takes 3 minutes but encraw says 1 minute, it means that the other 2 minutes was avisynth processing!

Still missing: Profile settings, fix quant mode, full 1st pass and advanced zones.

Edit: Outdated, see first post for latest

[buzzqw]

would be possible to implement an automatic 2 pass mode to hit final size (mb)

thanks

BHH

[Doom9]

would be possible to implement an automatic 2 pass mode to hit final size (mb)That's a feature for a GUI. MeGUI and RealAnime will do that for you when the time is right.

[S_O]

would be possible to implement an automatic 2 pass mode to hit final size (mb)I not quite sure what you mean, but you can use -size instead of -bitrate for 2pass mode, allowing you to set the final size of the video (note: Frame overhead is 0, but in vfw it´s set to 24 bytes (AVI), so you have calculate the container overhead yourself)

[Sirber]

That's a feature for a GUI. MeGUI and RealAnime will do that for you when the time is right.
So far, RealAnime don't produce a fixed size and work by bitrate or quality only. It include at least a bitrate calculator :).

[Doom9]

note: Frame overhead is 0, but in vfw it´s set to 24 bytes (AVI), so you have calculate the container overhead yourselfdoes that have any influence in bitrate mode? in the VfW and mencoder, the bitrate contains 24 byte container overhead.

[S_O]

does that have any influence in bitrate mode? in the VfW and mencoder, the bitrate contains 24 byte container overhead.No, it doesn´t seem so. I looked into xvid source and it seems that this parameter is only used with filesize parameter in 2pass mode, very simple, like this:
newsize = oldsize - frames*overhead.
(see plugin_2pass2.c; line 404).
Because xvid_encraw outputs raw stream I set this to 0 (with vfw the avi-file have the filesize enterd, with encraw the raw-file will have the filesize). So this parameter isn´t special, you can calculate it yourself.

Has nobody noticed that I uploaded a new version? No feedback until now... I don´t think that´s why because it works perfect and does not contain bugs.

[CiNcH]

No, it is because download doesn't work ;) ... still not approved.

[S_O]

http://forum.doom9.org/attachment.php?attachmentid=4477
Works for me, also after log-out.

[CiNcH]

Not for me.

Invalid attachment specified. If you followed a valid link, please notify the webmaster

[S_O]

You seem to be right. It seems to work because of cookies, when I try another browser it doesn´t work.
I´ll see if I can upload it somewhere else.

[Doom9]

It might just be that you can see your own attachments even while they're still pending.. I know that happens with mine but then again as admin I get to see everything. I have just approved the attachment. It might not be a bad idea to have just one attachment in the first post and edit the thread with changelog updates rather than to have multiple attachments all over the place.

[S_O]

It might not be a bad idea to have just one attachment in the first post and edit the thread with changelog updates rather than to have multiple attachments all over the place.Yes, I´ll do so next time and delete the others then.

[S_O]

OK, next release is ready:
Added advanced zones:
Now you have -z "zone_type start_frame quant/weight [advanced options]"
To see which options are allowed as advanced zones options see -h.
Note: Like in VirtualDub first frame is 0, not 1!

Fixed bugs:
Frame display finally works, you encode 100% of your movie.

Known bugs:
-Advanced zones will not start exactly at the specified frame in case B-Frames are enabled
-N-VOPs are not displayed correctly in stats (always 0 N-VOPs).

Missing features:
-Single pass fixed quant encoding
-Full 1st pass
-Profiles

Download is in first post!

[IgorC]

VHQ for b-frames? is it -rd_bf?

[S_O]

VHQ for b-frames? is it -rd_bf?Yes.
-rd_bf : enable R-D for B-framesR-D is Rate Disortion, "VHQ" is just another name for it (in fact the "VHQ"-modes are some presets for the R-D switches).
Edit:
How I can disable a setting which is enabled by default?Nothing is enabled by default. But if you have a preset activated like -quality 6, you can disable parts of it again, with, for example "-trellis" (disable trellis). Only the switches marked with "+" in the help screen can be disabled.
Tomorrow (or today, when I wake up again), I´ll post the normal switches that eqauls to.

[IgorC]

chroma optimization is bugy with this coomand line

xvid_encraw -i mxskal.avs -o raw.m4v -type 2 -asm -quality 6 -bitrate
900 -max_bframes 2 -croma_opt

[S_O]

xvid_encraw -i mxskal.avs -o raw.m4v -type 2 -asm -quality 6 -bitrate
900 -max_bframes 2 -croma_optYou disabled chroma optimizer (it is already disabled by default).
chroma optimizer is enable/disable switch, to enable it you have to use +chroma_opt.

Edit: it is +chroma_opt, not +croma_opt

[IgorC]

ok , I get it.

chroma was my fault. Thanks to point

[S_O]

+trellis
Yes. Trellis is enabled with this switch
+lumimasking
No. Lumimasking cannot be enabled/disabled. It´s yust -lumimasking
+chroma opt
Yes, it´s +chroma_opt to enable it and, if you like to disable it, for example inside a zone: use -chroma_opt as advanced parameter in the zone.

[IgorC]

I think a good GUI will be nice :)

[S_O]

I think a good GUI will be nice Yes.
I have taken this idea with "+" and "-" switches from a Real/Helix tool, I think it was dt_drive, it has also this kind of options.

[Doom9]

I think a good GUI will be niceMeGUI will eventually support it.
Speaking of which, two things that will be requested at some point will be MP4 and MKV output. Considering that such output is currently broken at 23.976fps in x264, and that that kind of output is most likely going to be integrated in the very same way, I'd hold off until these bugs are fixed. On the other hand, AVI output might be something where those problems won't ocurr, and with AVI output, encraw can serve as a full mencoder replacement in MeGUI.

[bond]

MeGUI will eventually support it.
Speaking of which, two things that will be requested at some point will be MP4 and MKV output. Considering that such output is currently broken at 23.976fps in x264, and that that kind of output is most likely going to be integrated in the very same way, I'd hold off until these bugs are fixed. On the other hand, AVI output might be something where those problems won't ocurr, and with AVI output, encraw can serve as a full mencoder replacement in MeGUI.if .avi output is wanted, why not use mencoder right away? or even the vfw codec

i dont see the point in wasting time adding avi output to this tool, if xvidvfw's avi output is stable for years already. sounds like reinventing the wheel

[Doom9]

if .avi output is wanted, why not use mencoder right away?Because mencoder is bloated beyond reason, doesn't fully support xvid and cannot support any option that contains double points (so xvid custom quantizer matrices as an example) because double points are used to separate encoder options in mencoder.
Considering that you can put any VfW codec into MKV using MKVToolnix, by your analogy mkv output in another other tool would also be reinventing the wheel ;)

[bond]

my few cents:

1) this +/- sheme is confusing. on some options there is only the "-" valid on others both? on some you enable the feature with "-" on others you disable it?

imho this is not really good. a better way would be imho to simply disable a feature when its not explicitely set in the cmdl (meaning by default everything is disabled).
or do it like x264 and enable some features by default which are known to be useful, and than offer an option to disable them, like "-no-qpel"

2) about .mp4 output

the mpeg4ip project offers an own commandline encoder using xvid and outputting .mp4 directly via the mpeg4ip mp4 lib. maybe its easy to take the .mp4 writing code from that and add it to "xvidcli" too?

the mpeg4ip lib should work perfectly fine

3) about .mkv output
Considering that you can put any VfW codec into MKV using MKVToolnix, by your analogy mkv output in another other tool would also be reinventing the wheel ;)nope, cause afaik no mkv tool can atm create native mpeg-4 in mkv fully supporting all features (b-frames)

so if native mpeg-4 mkv output is added to this tool this would be something new and it would also make sense to use this cli tool than ;)

[Doom9]

the mpeg4ip project offers an own commandline encoder using xvid and outputting .mp4 directly via the mpeg4ip mp4 lib. maybe its easy to take the .mp4 writing code from that and add it to "xvidcli" too?You told me once that GPAC creates less overhead... I don't recall the technical details why though.
nope, cause afaik no mkv tool can atm create native mpeg-4 in mkv fully supporting all features (b-frames)What's wrong with VfW mode? While not officially supported, it works just fine.. muxing avc-in-avi into mkv via mkvmerge has yet to cause any problems.

and then there's the old mp4box can handle raw input argument.. since you'd hardly find yourself not adding any audio, raw will work just fine for mp4, but where's the avi packer for raw streams? Just not liking AVI doesn't count ;)

[stephanV]

What's wrong with VfW mode? While not officially supported, it works just fine.. muxing avc-in-avi into mkv via mkvmerge has yet to cause any problems.
You get decoding delays. 1 frame in case of b-frames +1 extra frame if b-pyramid is used.

there is a tool called AVC2AVI provided with the x264 source code,

[bond]

You told me once that GPAC creates less overhead... I don't recall the technical details why though.it does, but with avc, not asp

What's wrong with VfW mode? While not officially supported, it works just fine.. muxing avc-in-avi into mkv via mkvmerge has yet to cause any problems. well stephanv answered + the mkv specs define how to place mpeg-4 (avc and asp) in .mkv (aka native mode) and thats not followed when going via vfw, which might cause interoperability problems aso

and then there's the old mp4box can handle raw input argument..hm i dont understand what you mean with that. mp4creator can handle raw streams fine too

since you'd hardly find yourself not adding any audio, raw will work just fine for mp4, but where's the avi packer for raw streams? Just not liking AVI doesn't count ;) what do container muxer tools have to do with thinking that adding avi output to this xvid encoder should be really low priority, as you dont get anything new if you add it?

i am pretty sure that its possible to mux raw streams into avi, eg via ffmpeg

[Doom9]

hm i dont understand what you mean with that. mp4creator can handle raw streams fine toowhy should encraw support direct mp4 output if you're going to mux audio (and subs, chapters, whatnot) afterwards anyways?
You get decoding delays. 1 frame in case of b-frames +1 extra frame if b-pyramid is used.alright, that's a very good point. By the way, does that apply to both ASP and AVC? Right now I use AVI as intermediate format for MKV output for Snow, lavc MPEG-4 and XviD.
there is a tool called AVC2AVI provided with the x264 source codeand its relevance for asp would be? Can it mux raw ASP content as well?
I'd like to have AVI output to be able to support all 3 containers directly in MeGUI. I don't have any vested agenda in any container, unlike some other participants here. I'll rest my case now.

[stephanV]

alright, that's a very good point. By the way, does that apply to both ASP and AVC? Right now I use AVI as intermediate format for MKV output for Snow, lavc MPEG-4 and XviD.
It applies to both ASP and H264 yes. It has no relevance to snow as it doesn't have b-frames AFAIK (VFW mode is fine there) and you could work around the delay with XviD if you use packed bistream... but uhm... yeah. :)

There is a native MPEG4 ASP MKV mode in MKVMerge which *should* also accept AVI input, but I forgot the command switch. Anyways, using the VFW mode for XviD is still the "normal" way for MKVMerge so I don't see why you should worry about that either then. I also believe Mosu has stated the same before.

A 1 frame decoding delay is not that big of a deal in any case.


and its relevance for asp would be? Can it mux raw ASP content as well?
Not any. Admittedly I got a bit confused in all the XviD and x264 crosstalk and I thought to understand you were looking for a way to put raw H264 in AVI. Pardon me.

[bond]

why should encraw support direct mp4 output if you're going to mux audio (and subs, chapters, whatnot) afterwards anyways?because with .mp4 output you can edit the output in various tools and dont need mp4box or mp4creator :p

[Doom9]

but I forgot the command switch.I'm off to the mkvmerge manpage then.

[multicone]

I'm off to the mkvmerge manpage then.

I guess you won't find it there, because it hasn't been officially released yet. But it works quite stable already, more testing welcome of course.

--engage -nativeMPEG4

This was difficult to add IIRC, as Mosu needed code to read the MPEG4ES headers to find out the exact frame type ( P or B ), when parsing the AVI as it only know P frames.

[S_O]

1) this +/- sheme is confusing. on some options there is only the "-" valid on others both? on some you enable the feature with "-" on others you disable it?Yes, it´s bit confusing, but it´s needed for zones, but it´s needed for zones, if you want to enable something for zones use +xyz, if you like to disable it, use -xyz. I thought this is simpler than -xyz and -no-xyz.

You can remember it like this: Options that don´t need an argument are +/- , all others are yust - (I know, that´s not true for all, like gmc or qpel, but I´ll change it).

My thoughts about the container stuff:
When mp4, matroska, avi, ogm (?)... support is added this encoder becomes more or less a second ffmpeg, I don´t think that is what it is supposed to be. Also it´s nonsense to support these formats while there is no support for directly muxing audio (which means you have to remux it anyway). It´s better to add m4v support to the muxing apps, because in probably 98% of all encoding situation you want add audio. If you go for mp4, it doesn´t matter if mp4box / mp4creator reads the video from m4v or mp4.
But I´ll also understand that it´s annoying first to create a m4v raw stream, then mux it to mp4 and then to make mkv or what ever of it (or edit it as Bond said).
So my idea: stdin/stdout: I already added stdout support to xvid_encraw and I was able to successfully watch the video with a for stdin input patched tmp4 (Skal´s MPEG-4 Encoder/Decoder) while encoding.
I also tried to mux, but neiter mp4box, mp4creator nor ffmpeg seem to support m4v via stdin.
I tried to add stdin support to mp4box, but without any success. Is anybody here in contact with the author? Maybe someone could ask him to implement stdin support (it shouldn´t be to difficult for him, since he knows his code).

This was difficult to add IIRC, as Mosu needed code to read the MPEG4ES headers to find out the exact frame type ( P or B ), when parsing the AVI as it only know P frames.If he has that already and is quite familar with basic m4v, it shouldn´t be too difficult to add a complete m4v parser.

BTW: @Doom9: Why don´t you add xvid directly to MeGUI? If it is coded in C/C++ it should be quite simple.

[Doom9]

If it is coded in C/C++ it should be quite simple.It isn't, and simply being able to plug in a new exe without having to worry about recompiling is a nice thing to have.

[Mosu]

I guess you won't find it there, because it hasn't been officially released yet. But it works quite stable already, more testing welcome of course.

--engage -nativeMPEG4

Not quite, it's "--engage native_mpeg4". It should be working well by now. The only reason I don't make this the default is that there would be problems on playback because most apps don't support V_ISO/MPEG4/* (apart from AVC) yet, I guess. It would be deliberately breaking playback for a LOT of people, something that I have done in the past and don't really want to repeat.

[bond]

My thoughts about the container stuff:
When mp4, matroska, avi, ogm (?)... support is added this encoder becomes more or less a second ffmpeg, I don´t think that is what it is supposed to be. Also it´s nonsense to support these formats while there is no support for directly muxing audio (which means you have to remux it anyway). It´s better to add m4v support to the muxing apps, because in probably 98% of all encoding situation you want add audio. If you go for mp4, it doesn´t matter if mp4box / mp4creator reads the video from m4v or mp4.
But I´ll also understand that it´s annoying first to create a m4v raw stream, then mux it to mp4 and then to make mkv or what ever of it (or edit it as Bond said).
So my idea: stdin/stdout: I already added stdout support to xvid_encraw and I was able to successfully watch the video with a for stdin input patched tmp4 (Skal´s MPEG-4 Encoder/Decoder) while encoding.
I also tried to mux, but neiter mp4box, mp4creator nor ffmpeg seem to support m4v via stdin.
I tried to add stdin support to mp4box, but without any success. Is anybody here in contact with the author? Maybe someone could ask him to implement stdin support (it shouldn´t be to difficult for him, since he knows his code).well i wouldnt say that necessarily every output will get muxed with audio, some might use the output for editing or whatever
its like saying that virtualdub outputting to .avi even without encoding audio is senseless, i think its not
an encoder should be able to output something useable right away imho, and raw .m4v isnt imho, cause you need a second tool for muxing the stream and there arent lots of tools being able to handle raw input
(btw ffmpeg's mp4 writing is not working correctly, only mp4creator from mpeg4ip and mp4box from gpac do that correctly)

if what you say is true, that raw output should be the way to go, than i wonder why every normal encoder tool on earth outputs into a container ;)

but well you are the dev, i cant force you to anything...
all i can say it might be very easy to add mp4 output when looking at the mpeg4ip sources i pointed you to
or you use the lib from gpac (as used in mp4box)

Not quite, it's "--engage native_mpeg4". It should be working well by now. The only reason I don't make this the default is that there would be problems on playback because most apps don't support V_ISO/MPEG4/* (apart from AVC) yet, I guess. It would be deliberately breaking playback for a LOT of people, something that I have done in the past and don't really want to repeat.this also works correctly with packed bitstream, packed bitstream + real n-vops and vfw delay frames?

[S_O]

well i wouldnt say that necessarily every output will get muxed with audio, some might use the output for editing or whatever
its like saying that virtualdub outputting to .avi even without encoding audio is senseless, i think its notI think in most cases audio is used. Also there is difference between xvid_encraw and VirtualDub: VirtualDub is an audio/video processing application, xvid_encraw is an XviD MPEG-4 video encoder.
an encoder should be able to output something useable right away imho, and raw .m4v isnt imho, cause you need a second tool for muxing the stream and there arent lots of tools being able to handle raw inputYes, that´s indeed a good point: m4v is not supported very well (only ffmpeg, MP4Box and mp4creator are able to read it (and tmp4)).
if what you say is true, that raw output should be the way to go, than i wonder why every normal encoder tool on earth outputs into a containerAll MPEG Audio Layer 1/2/3 encoder I know output raw streams (In fact, most MP3 players cannot even handle MP3 muxed into normal MPEG-1, also it´s the standard container for it).
but well you are the dev, i cant force you to anything...
all i can say it might be very easy to add mp4 output when looking at the mpeg4ip sources i pointed you to
or you use the lib from gpac (as used in mp4box)OK, mp4 support might be good, because raw m4v is nearly unuseable, I´ll have at look at it.
It isn't, and simply being able to plug in a new exe without having to worry about recompiling is a nice thing to have.Plug in a new xvidcore.dll... without having to worry about changed command line syntax... But it´s your tool, your decision.

Has anybody tested the tool so far? Please post your experience with it.

[bond]

any news about the project?

[S_O]

I´m currently waiting for bug reports. I don´t think it´s fine to always add new features without fixing bugs, that makes the tool unuseable.
So please, report something like
"I used it with commandline ... and noticed that ...." or yust "I used it with commandline ... and it seemed to work fine"
But without any feedback I can´t fix anything (or I doesn´t even know that there is nothing to fix).

[Doom9]

is there going to be any change in the commandline interface (akin what bond suggested) or is it going to remain as it is?
And at the risk of flogging a dead horse, so far ffmpeg is the only app that can put a raw m4v into an AVI. For the forseeable future, XviD is most likely to be stored in AVI (existing tools that are available, standalone compatiblity). This might change over time but for now it would be really nice to not having to use ffmpeg. raw streams are much more workable when you add them to mp4 because that's where we have the tools that can handle those streams. avi would also help for mkv (at least until the native storage becomes the standard for asp content).

[buzzqw]

maybe :stupid:

but i not realized how to use -size parameter (i always get the same size)

could you write 2 line for example ?

Thanks a lot

BHH

[bond]

i think one of the points of using this tool is to make it easier to not have to go via .avi
i doubt many people will use it for .avi output, cause vfw is simply better known and accepted

better add .mp4 support :D

[Doom9]

cause vfw is simply better known and acceptedTrue.. but think if we can get people to move away from VDub.. it's not like most users insist on VDub, it's that the apps they use (GKnot, AutoGK, etc) require these tools. If they used a generic purpose encoder (like MeGUI does), it will become much easier to switch out the container once they are ready to.. MP4 output instead of AVI is just a few clicks away in MeGUI. But that move will not happen over night.. it takes time and it's best to give people a soft update path (first the tool, with the output staying the same), then at some later point the container can change as well.

[bond]

thats indeed a point

i just fear the glue of virtualdub. simply look at how many people use x264vfw, altough the cli blows the vfw codec away clearly :scared:

[Sirber]

it takes time and it's best to give people a soft update path (first the tool, with the output staying the same), then at some later point the container can change as well.Like when I removed RMVB output from RealAnime? ;)

[Doom9]

Like when I removed RMVB output from RealAnime?You can of course always force people to their luck :)
i just fear the glue of virtualdubVirtualdub is sticky mostly because of the editing features. I think encoding could easily be switched out (except of course for the codecs that are only available as VfW version, filtering has long since moved mostly to AviSynth, audio encoding is done via other tools because there's no VBR in VDub, but there's no tool that allows you to open an MP4 or MKV and to navigate to frames, set cut points, split and merge. True, we can split and merge but those are non graphical tools, and as long there's no preview, the "why doesn't VirtualDub open MP4 files" question will stick around. But perhaps a DShow based preview tool that serves as a cutting / merging and muxing / demuxing frontent for the existing mp4/mkv tools might scratch that itch just enough.

[S_O]

is there going to be any change in the commandline interface (akin what bond suggested) or is it going to remain as it is?
I´m currently thinking about it. Do you (or anybody else) have a good idea how to change it in a way, that it is still possible to aktivate greyscale in general, but deactivate it again in a zone etc.
XviD options can be very complex, controlling it all via commandline is difficult.
And at the risk of flogging a dead horse, so far ffmpeg is the only app that can put a raw m4v into an AVI. For the forseeable future, XviD is most likely to be stored in AVI (existing tools that are available, standalone compatiblity). This might change over time but for now it would be really nice to not having to use ffmpeg. raw streams are much more workable when you add them to mp4 because that's where we have the tools that can handle those streams. avi would also help for mkv (at least until the native storage becomes the standard for asp content).
Yesterday 23:34Is there no application for avi muxing that accepts stdin input? It should be quite simple for every GUI to directly mux to avi. I´m not familar with avi, but it should be possible.
but i not realized how to use -size parameter (i always get the same size)

could you write 2 line for example ?It could be like this:
xvid_encraw -i script.avs -type 2 -o output.m4v -quality 6 -pass1 statsfile
for first pass and for second pass:
xvid_encraw -i script.avs -type 2 -o output.m4v -quality 6 -pass2 statsfile -size 102400
This will (should) create a 100MB m4v.
i think one of the points of using this tool is to make it easier to not have to go via .avi
i doubt many people will use it for .avi output, cause vfw is simply better known and accepted

better add .mp4 supportThat´s also my opinion
True.. but think if we can get people to move away from VDub.. it's not like most users insist on VDub, it's that the apps they use (GKnot, AutoGK, etc) require these tools. If they used a generic purpose encoder (like MeGUI does), it will become much easier to switch out the container once they are ready to.. MP4 output instead of AVI is just a few clicks away in MeGUI. But that move will not happen over night.. it takes time and it's best to give people a soft update path (first the tool, with the output staying the same), then at some later point the container can change as well.You´re right, but I still think avi support is not directly needed inside, what about an external avi muxer, with stdout/stdin
Virtualdub is sticky mostly because of the editing features. I think encoding could easily be switched out (except of course for the codecs that are only available as VfW version, filtering has long since moved mostly to AviSynth, audio encoding is done via other tools because there's no VBR in VDub, but there's no tool that allows you to open an MP4 or MKV and to navigate to frames, set cut points, split and merge. True, we can split and merge but those are non graphical tools, and as long there's no preview, the "why doesn't VirtualDub open MP4 files" question will stick around.A new VirtualDub is really needed, not based on the limitations of vfw/acm, and platform-indipendant, using it´s own plug-in system, also for muxing/demuxing. ChristianHJW claimed to start a tool like this months/years ago (I think it was called "The Core Media Editor"). Never seen anything of it.

[Sirber]

Could you add MKV support too? I'm not very friendly with MP4... :D Thanks!!

[buzzqw]

Quote:
but i not realized how to use -size parameter (i always get the same size)

could you write 2 line for example ?
It could be like this:
xvid_encraw -i script.avs -type 2 -o output.m4v -quality 6 -pass1 statsfile
for first pass and for second pass:
xvid_encraw -i script.avs -type 2 -o output.m4v -quality 6 -pass2 statsfile -size 102400
This will (should) create a 100MB m4v.

Thanks !

BHH

P.S. : i like too mp4/mkv support

[dimzon]

i like too mp4/mkv support
And don't forget about CQM ;)
:thanks:

[S_O]

And don't forget about CQMIs already supported:
-mpeg_quant -mpeg_cqm filename
CQM File is the same format used by XviD vfw or ffdshow

With containers, I´ll see.

[Brother John]

I´m currently thinking about it. Do you (or anybody else) have a good idea how to change it in a way, that it is still possible to aktivate greyscale in general, but deactivate it again in a zone etc.
Two ways of doing this come to my mind:

1.
Exclusively use + to turn an option on and - to turn it off. For the cases, where this doesn't make sense (e.g. input file) use --. That way we would get a nice and clear
xvid_encraw --i script.avs --type 2 --o output.m4v --pass1 stats.file +greyscale --z w 1000 0.5 -greyscale

2.
Always use - to start an option and add a trailing + or - where appropriate. That way -gmc+ would turn GMC on and -gmc- would turn GMC off.

[bond]

is using "+" also possible on for example linux based systems?

[S_O]

is using "+" also possible on for example linux based systems?I can use everything. There is no rule that says commandline switches have to start with a special char.
Exclusively use + to turn an option on and - to turn it off. For the cases, where this doesn't make sense (e.g. input file) use --. That way we would get a nice and clearIndeed, that´s pretty nice.
I think it´s better than a trailing + or -

[bond]

I can use everything. There is no rule that says commandline switches have to start with a special char.hm there are things which can conflict, eg you cant use ";" in a cmdl for linux prompt compatibility

Indeed, that´s pretty nice.yep, i also think that it should be the same for all options: + for enabling, - for disabling

i dont think the -- is necessary, it maybe just makes things complicated, i would simply use + here too

I think it´s better than a trailing + or - hm i would prefer the trailing +/- cause using + at the front somehow looks very very strange :D

[The Link]

i dont think the -- is necessary, it maybe just makes things complicated, i would simply use + here too

Wouldn't "--" make sense if one just want to use a quality preset (and this way doesn't have to care about individually switching features on or off)? Or did I misunderstand sth. in this regard?

[dimzon]

yep, i also think that it should be the same for all options: + for enabling, - for disabling
i prefer 1 for enabling and 0 for disabling :)

[bond]

i would say keep it simple and use the same logic everywhere

[Doom9]

for booleans, wouldn't it be better to either have the commandline contain something, or not contain anything which would mean the opposite? e.g. why -gmc if gmc is not turned on by default? why not -gmc to turn it on, and if there's no option called gmc, it's not turned on at all? a boolean, after all, can only have two values: true or false... there's no undetermined state so to me it makes no sense to introduce such a third state via commandline. After all, what do you do if somebody leaves out -/+gmc? Aborting in this state would meant that every possible parameter has to be crammed into the commandline, which may just cause problems simply for the fact that commandlines can't have an arbitrary length (so long zone strings are potential cause for cutoffs), and then with such long commandlines there's a much higher probability of a typing error.

And for zones, why not use a similar format to what other cli encoders. I envisaged the following format if I ever added full xvid zones to mencoder (I wrote the patch to add basic zones): -zones 1,100,w,0.5,KGOC3/200,300,q,20,K/400,500,q,20/600,700,q,20

where KGOC are exactly the options used in the VfW: K = start with a keyframe, G = grayscale mode, O = use chroma optimizer, C = cartoon mode and if there's any number in that string, it's the bvop sensitivity. The rest of the options is as follows:
start frame, end frame, weight/quantizer, modifier. If there's a 4th comma, whatever comes after it and before the / (or a space which signifies the end of the zones string) are modifiers for the current zone.

And I'm not aware of a commandline that muxes raw streams from the stdin. Plus there's always the issue about these tools not always be willing to cooperate when used from a programming environment. E.g. whihle avs2yuv and mencoder can be piped just fine on the commandline, or running a batch file, no matter how I tried, I couldn't pipe the avs2yuv stdout to mencoder's stdin.. mencoder would always exit for no good reason, leaving avs2yuv pumping out data that had to be discarded.

[bond]

for booleans, wouldn't it be better to either have the commandline contain something, or not contain anything which would mean the opposite? e.g. why -gmc if gmc is not turned on by default? why not -gmc to turn it on, and if there's no option called gmc, it's not turned on at all? +/- allows easier handling of zones

if you only have one option for enabling you either
1) cant disable anything in a zone which is set in the main settings if the main settings are valid for the whole enocde
2) or you have to set all options in every zone seperately if there are no main settings valid for the whole encode, which is a real pita (imagine someone setting a keyframe for every chapterpoint (very likely situation imho) you would need to repeat the whole settings for every chapterpoint zone...)

[Doom9]

1) cant disable anything in a zone which is set in the main settings if the main settings are valid for the whole enocdeuhh, the way I read the source code of the VfW encoder, before a frame is encoded, the zones are consulted. If a zone is found which includes the frame in question, the properties requested from the encoder are updated to match what the zone asks for. Thus, it's perfectly possible to have the bvop sensitivity on a zone override the one set as global parameter. Likewise for chroma, and the rest of the options are mutually exclusive (there's no option in the zones and in the general config), at least in the VfW.

I've just been browsing the code again and looking at the platform SDK in the background: A frame is compressed via the ICM_COMPRESS (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_icm_compress.asp) and this is mapped to the compress function in codec.c (the mapping is in driverproc.c). And if you look at that function (which is called for every frame), it contains a call to apply_zone_modifiers and that function does exactly what I described above. Hence your point is invalid, it's perfectly possible to apply these 5 modifiers for each zone completely independent of what's configured for the entire movie. Furthermore, my suggestion also takes care of the following problem: a user does not realize that a frame extends from it's start frame to the start of the subsequent zone.. it's perfectly possible to add a zone end frame (not so straightforward to code though because the zone struct still makes it to the encoder, so you can't just change it and the alternative is having a separate list of zone ends, or make a patch to the core which adds that property - then somebody could expose ithis in the VfW frontend as well.


or you have to set all options in every zone seperately if there are no main settings valid for the whole encode, which is a real pitafor the abovementioned, this isn't the case at all. Stuff like the number of b-frames, quantizer matrix, qpel, gmc, etc, it's all global, the only thing that applies to zones are the 5 parameters I mentioned.

Plus you know very well that zones to match chapters are completely superfluous. Any proper DS decoder can jump to any given frame, and even standalone players have no problem jumping to an arbitrary position via the go-to function.. at least the 3 I have can do that without problem (but not a single one supports chapters ;)) An "apply these zone modifiers to all zones" would be a GUI function imho.. not even the VfW offers this and I've not come across any complaints there, but if there's a demand for such a function, I could always add it to MeGUI.

[Doom9]

upon looking at the full list of supported options in the latest release... phew, that's a lot to take in. I expected to only find what's in the VfW. How is the separation between "applies to a zone" and applies overall made? Using an approach where you have one zone string would take care of that.. anything outside that string is a general option, anything inside a zone string only applies to that zone.

Here's an example: -zones 0,q,20,+trellis+hpel/101,w,1.0,+greyscale
(other options with some separator between the modifiers are also possible of course, like a comma)

Using that approach, it's even possible to switch out +option with -option. Looking at the options that begin with a +, none uses a minus anywhere in the string, so you could use the standard -option to activate, and nothing means not activated. That way, there is no dual sign approach that might be confusing. I think that when zones are used, they would be grouped together in the commandline anyway for a better overview, so why not join them into a single string.

[bond]

Using that approach, it's even possible to switch out +option with -option. Looking at the options that begin with a +, none uses a minus anywhere in the string, so you could use the standard -option to activate, and nothing means not activated. That way, there is no dual sign approach that might be confusing. I think that when zones are used, they would be grouped together in the commandline anyway for a better overview, so why not join them into a single string.hm now if you want to be sure that 50 frames become keyframes how would the cmdl look like?

[Doom9]

-zones A,w,1.0,-if/B,w,1.0,-if/C,w,1.0,-if/etc

If I'm reading the manual right, right now it would look like this:

-z "A w 1.0 -if" -z "B w 1.0 -if" -z "C w 1.0 -if" etc

there's no "make these 50 frames to a keyframe" function anyway, you have to define every zone start frame, zone type, modifier (1.0 since you only want to force a keyframe), and any other options you like (in your case -if to force the I-frame at the start). Thus either way, there's a lot of typing to be done. But I could imagine a file open dialog in a GUI app that would read a list of frame numbers from a file, and create such zones automatically for you to simplify things. Thinking about megui, that wouldn't be so hard to add with the zone functionality I already have. Unlike xvid's core, I can extend the zone struct to accomodate additional flags (and they already support a start and end frame, the end frame is just never used in case of xvid.. unlike this is about to change in xvid's core) and -if is definitely a flag I would add.

[Sagittaire]

@ S_O

this project will be really interessing I think ...

Ready for global ISO 14496 open source project ... ???

x264 is perhabs at this time the best video codec (only beta for Nero HP). XviD or Libavcodec are some excellent MPEG4 ASP codec. FAAC a good AAC encoder. MP4Box an excellent muxer, splitter and more for mp4 ...

Why not a global fusion of all these project:
- ISO 14496-14 container MP4: MP4Box
- ISO 14496-17 subtitles TTXT: MP4Box
- ISO 14496-02 video MPEG4 ASP: XviD or Libavcodec
- ISO 14496-10 video MPEG4 AVC: x264
- ISO 14496-03 audio MPEG4 AAC: FAAC

ISO14496.exe CLI like producer.exe CLI for RV10 ... ???

[Doom9]

@saggitaire: isn't that just a tad bit ot here?

[Doom9]

@S_O: any thoughts on the proposed changes?

[Isochroma]

I cannot find a way to set the framerate - the -framerate option specified anywhere in the command line doesn't affect the output - which is always 25.00 FPS!

xvid_encraw -i "G:\Shinjuku\AVISynth Scripts\Ghost in the Shell\GITS-RS.Tex.AVS" -framerate 23.976 -type 2 -w 720 -h 464 -custom_par 32 27 -quality 6 +hqacp +inter4v -max_bframes 4 -bitrate 10000000 -single -qpel +me_advd16 +me_advd8 +me_hpelr16 +me_hpelr8 +me_qpelr16 +me_qpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_qpelr16 +rd_qpelr8 +rd_exts -iquants 1 1 -pquants 1 1 -o "d:\test.m4v"

[Doom9]

I've found a means to mux raw m4v into AVI so I'm all game for integrating encraw into MeGUI, but I'd like to have the commandline thing settled..

[S_O]

I've found a means to mux raw m4v into AVI so I'm all game for integrating encraw into MeGUI, but I'd like to have the commandline thing settled..Expect a new release in a few days, the commandline structure will change like proposed here.
I cannot find a way to set the framerate - the -framerate option specified anywhere in the command line doesn't affect the output - which is always 25.00 FPS!I can confirm the bug, the fps-switch is ignored when reading avs, the avs framerate is always used (you can work around by setting another framerate in your script). Expect it to be fixed in next release.

[Isochroma]

The framerate in my AVS was 23.976

[S_O]

The framerate in my AVS was 23.976Are you sure? What has been displayed?
Oh, I think I have an possible explanation of what happend:
xvid_encraw has used 23,976 fps, no problems. But framerate is not stored in the bitstream, so when you mux it with mp4box, mp4box uses a default framerate of 25fps. You need to add "-fps 23.976" in the mp4box commandline.

[Doom9]

doesn't mp4box only pick up the framerate if you feed it with an mp4 containing video (or perhaps avi as well). iirc you always need to specify the framerate for raw content, regardless of whether the bitstream contains the framerate or not.

[S_O]

In avi or mp4 the bitrate is stored, so mp4box reads it when it opens such a file. But in raw m4v a bitrate is never stored. So mp4box uses default value of 25fps. In case you mux a raw-movie now with a framerate other than 25fps, you need specify this in the commandline using the -fps switch, otherwise the movie will have a wrong framerate of 25fps, and I think that´s exactly the problem that Isochroma has noticed.

[JoeBG]

Expect a new release in a few days, the commandline structure will change like proposed here.


Any new releases? Great projekt :thanks:

[Doom9]

since it seems to take longer than anticipated (hey, it happens), could you tell us which of the proposed schemes you're going to adopt so that I can start my preparations?

[JoeBG]

Hi guys,

since 4 hours I´m testing my tesclip (885 frames) xvid_encraw. I get horrible pictures with the following skript and can´t improve it with ever I try:

echo Pass 1 Xvid
echo ************
echo.
xvid_encraw -i Film.avs -type 2 -asm -par PAL169 -quality 6 -pass1 Xvid.log -bitrate 1400 -max_bframes 2 -qpel -vhq 4 -turbo -z "q 800 40" -o Film.m4v
echo.
echo Pass 2 Xvid
echo ************
echo.
xvid_encraw -i Film.avs -type 2 -asm -par PAL169 -quality 6 -pass2 Xvid.log -bitrate 1400 -max_bframes 2 -qpel -vhq 4 -z "q 800 40" -o Film.m4v

[JoeBG]

I found the mistake myself. If I rename "Xvid.log" to "statsfile" in both passes, everything works fine. I really don´t know why.

Edit:
Just one word to the tool: It´s great. Mencoder Xvid is slower and always creates too small outputs. But my first tests with xvid_encraw are all very good.

[JoeBG]

Sorry guys, I´m testing the tool and there are two other questions coming up :)

-vhq, default is [1.4]. Does this mean a range between 1 and 4 and can I choose 4 like in vfw codec?

-quality 6: Which features does this include? All features with a "+" ? So that I can deaktivate them when I want? I´m interested in a complete list please. :)

Sorry for so many questions. But it´s agreat tool and I will use it correct :)

[Yuri Khan]

I've found a means to mux raw m4v into AVI so I'm all game for integrating encraw into MeGUI, but I'd like to have the commandline thing settled..
Could you please elaborate? Is it an external commandline muxer that accepts m4v input, or just an idea how to implement one?

To put it short, my typical use case is a series of 26 24-minute episodes, each of which has to be encoded in a separate file and wants an individual bitrate (sometimes up to 100% difference), but with all other settings common. So the only part of the encoder settings that changes is the stats filename and the target size. And I’m looking for a command line driven encoder that I could invoke from a generated batch file (or maybe even from a makefile).

For now, I see three candidates: (1) VirtualDubMod (but then I have to understand how it encodes the binary codec settings and to watch for settings changes when upgrading the codec); (2) mencoder (but it undersizes each episode by ~20MB); and (3) xvid_encraw which seems almost perfect but I need to find out what to do with raw m4v output.

[JoeBG]

...but I need to find out what to do with raw m4v output.

mux it into mp4 with mp4box or mux it into mkv with mkvtoolnix

[Yuri Khan]

-quality 6: Which features does this include? All features with a "+" ? So that I can deaktivate them when I want? I´m interested in a complete list please. :)
Judging by the source:
-quality 1 implies +me_advd16
-quality 2 adds +me_hpelr16 and +hpel
-quality 3 adds +me_advd8, +me_hpelr8, +inter4v, and if you’re using -qpel, then also +me_qpelr8
-quality 4 adds +chromap and +chromab
-quality 5 adds +trellis
-quality 6 adds +me_exts16, +me_exts8 and +hqacp

mux it into mp4 with mp4box or mux it into mkv with mkvtoolnix
And then remux into avi… I think I’d rather take a plunge into mencoder sources :)

[Doom9]

mencoder can mux raw ASP streams into an avi.. the commandline is the same as what megui uses for the AVI muxer, just with an .m4v instead of an .avi input. Once encraw is ready to be incorporated, I'll unlock the filetype selector in the avi muxer to make it possible to directly mux in MeGUI. even raw AVC muxing should be possible, but due to yet another bug in mencoder, only if you specify the FPS of the source.

[Yuri Khan]

Heh, figured it out too…
mencoder -ovc copy -ffourcc XVID test.m4v -o test.aviSomehow, without -ffourcc, it puts FMP4 in the headers.

Not that I’m happy with using a sophisticated tool like mencoder for mundane muxing tasks, but hey, if it works, why not :)

[Beave]

to mix the raw file into avi with mencoder I tried the cli from megui:
"mencoder.exe" "test.m4v" -ovc copy -oac copy -audiofile "test.ac3" -mc 0 -noskip -o "test.avi"
It just stops without ending. I guess I need to add framerate and Aspect information to the commandline, right?

[Yuri Khan]

@Beave:
You need to specify the audio parameters such as bitrate, sample rate and channel count. Interestingly, you can get the required information with mplayer:
mplayer.exe -frames 0 -identify test.ac3and watch for lines starting with:
ID_AUDIO_BITRATE
ID_AUDIO_RATE
ID_AUDIO_NCHYou then issue a command like this:
mencoder.exe -ovc copy -oac copy -audiofile test.ac3 -audio-demuxer 20 -demuxer lavc -rawaudio format=0x2000 -rawaudio bitrate=384000 -rawaudio channels=6 -rawaudio rate=48000 test.m4v -ffourcc XVID -o test.avisubstituting your own values for 384000, 6 and 48000.

@Doom9:
I have found that, with most raw XviD .m4v files, mencoder selects libavformat demuxer and the resulting avi is all right, but some files are identified as MPEG4-ES. In the latter case, it produces an avi file whose headers contain zeros in the video width and height fields. It is not exactly b0rked, as mplayer still can play them; but also not completely compatible as, for example, Media Player Classic refuses to render such 0×0 files. Thus, I suggest that the switch -demuxer lavf be used explicitly to select libavformat demuxer, which passes the correct width and height to the muxer.

[Doom9]

@S_O: any news?

[naysayer]

I have a feature request: output to stdout.

I used to pipe avs2yuv to ffmpeg via stdin/stdout, with no temp file, to save to avi like this:
avs2yuv 1.avs - | ffmpeg -f yuv4mpegpipe -i - 1.avi

I've been using xvid_encraw now, and saving with "-o out.m4v", and then using mencoder or ffmpeg to mux into an avi.
What would be great though, is if I could avoid the temp m4v file and pass the video to ffmpeg like I used to with avs2yuv, like:
xvid_encraw -i 1.avs -o - | ffmpeg -f rawvideo -i - 1.avi

I tried variations of "xvid_encraw -i 1.avs -o -" already, and it only writes to disk with a file named " - "...

[708145]

I have a feature request: output to stdout.

I used to pipe avs2yuv to ffmpeg via stdin/stdout, with no temp file, to save to avi like this:
avs2yuv 1.avs - | ffmpeg -f yuv4mpegpipe -i - 1.avi

I've been using xvid_encraw now, and saving with "-o out.m4v", and then using mencoder or ffmpeg to mux into an avi.
What would be great though, is if I could avoid the temp m4v file and pass the video to ffmpeg like I used to with avs2yuv, like:
xvid_encraw -i 1.avs -o - | ffmpeg -f rawvideo -i - 1.avi

I tried variations of "xvid_encraw -i 1.avs -o -" already, and it only writes to disk with a file named " - "...

what about named pipes? they work under cygwin at least.

bis besser,
T0B1A5

[708145]

Is -frames ignored in avs mode?
And a related question: could -start be added as well as in x264.exe?

That would help me a lot with ELDER :)

P.S.: What's the status on avi output? If it's not planned then I have to ship ffmpeg with ELDER... just want to avoid depending on too many tools.

bis besser,
T0B1A5

[JoeBG]

@S_O: any news?

Any News?

[Doom9]

I know S_O is still around but not posting anymore. Sad :(

[JoeBG]

I know S_O is still around but not posting anymore. Sad :(

He is preparing something special I hope :yes:

[mirthandir]

When I compile and run the xvid_encraw.cpp posted it throws an exception

LN 1004: "res = env->Invoke("Import", AVSValue(&arg, 1));"

Anybody have any suggestions? Is there something moronic that I'm missing?

[JoeBG]

Any news?

[Zero1]

It's great to be able to finally use encraw :)
I was going to make some anamorphic ASP in MP4, for some testing, and I came across this weird error. To try and eliminate the cause I re-encoded it without the AR tag.

I was wondering if there are any knowns errors, or perhaps someone could tell what the problem is by looking at it and suggest disabling a feature manually?

This is the command I am using:
xvid_encraw.exe -i "Video1.avs" -framerate 23.976 -type 2 -w 704 -h 480 -quality 6 -vhq 4 -chroma_opt -max_bframes 2 -bitrate 1500000 -pass2 stats.log -max_key_interval 240 -iquants 2 31 -pquants 2 31 -bquants 2 31 -o "test2.m4v"

And here is the "artifact" (not so much of an artifact, just looks like b0rked Macroblocks?).

http://img420.imageshack.us/img420/6896/encrawblocks6wj.th.jpg (http://img420.imageshack.us/my.php?image=encrawblocks6wj.jpg)

(That was made using directshowsource)

Many thanks

[JoeBG]

Still hoping for an update :)

[Doom9]

Me too - I'd love to use this in megui to offer the full featureset of xvid, but it looks like somebody else has to start coding.

[Kopernikus]

Is there anything else than zones for enc_raw that I didnt see when looking through the thread?

I think zones could easy be implemented as a plugin, but I don't know if I have time to try it.

[Doom9]

zones are included.. it's just the syntax that is a bit weird. S_O said he was going to change it - then nothing ever happened...

[Kopernikus]

is the syntax proposed by BrotherJohn the one that should be implemented?

[Doom9]

I still insist the one I proposed (which corresponds to syntax other codecs use) is better. Are you volunteering to finishing encraw? I would except I have no time (there will be a new codec comparison, and when I have time I should continue working on MeGUI) and don't like C (and I don't suppose you could do this project in Visual Studio).

[JoeBG]

For me there is still the open question with the stats file. You have to give the the stats file of the second pass another name than the one of the first pass. This looks like as if the stats file of the first pass is not used in the second pass. I tested this and if you only make a second pass ( without any first pass) the quality is the same as if you make a first pass and a second pass. => The first pass with xvid_encraw seems to be totally useless. Can someone confirm?

[Zero1]

Syntax like the ones used in x264.exe CLI would be absolutely ideal in my opinion.

Any comments on my messed up screenshot yet guys?

Cheers :)

[JoeBG]

Syntax like the ones used in x264.exe CLI would be absolutely ideal in my opinion.

Any comments on my messed up screenshot yet guys?

Cheers :)

Where is your total commandline? No first pass is used?

[Zero1]

This wasn't the command I used at the time (since then I've edited my batch and lost the settings) but these settings reproduce the problem.

xvid_encraw.exe -i "Video1.avs" -framerate 23.976 -type 2 -w 704 -h 480 -quality 6 -vhq 4 -chroma_opt -max_bframes 2 -bitrate 1500000 -pass1 stats.log -max_key_interval 240 -iquants 2 31 -pquants 2 31 -bquants 2 31 -o "test1.m4v"
xvid_encraw.exe -i "Video1.avs" -framerate 23.976 -type 2 -w 704 -h 480 -quality 6 -vhq 4 -chroma_opt -max_bframes 2 -bitrate 1500000 -pass2 stats.log -max_key_interval 240 -iquants 2 31 -pquants 2 31 -bquants 2 31 -o "test2.m4v"

Yes, the first file was 2 pass, the line I posted was from the second pass. IIRC the first pass was identical except for --pass and the output was to a different file. It still used the same log file as pass 2 though.

Thanks :)

[JoeBG]

This wasn't the command I used at the time (since then I've edited my batch and lost the settings) but these settings reproduce the problem.

xvid_encraw.exe -i "Video1.avs" -framerate 23.976 -type 2 -w 704 -h 480 -quality 6 -vhq 4 -chroma_opt -max_bframes 2 -bitrate 1500000 -pass1 stats.log -max_key_interval 240 -iquants 2 31 -pquants 2 31 -bquants 2 31 -o "test1.m4v"
xvid_encraw.exe -i "Video1.avs" -framerate 23.976 -type 2 -w 704 -h 480 -quality 6 -vhq 4 -chroma_opt -max_bframes 2 -bitrate 1500000 -pass2 stats.log -max_key_interval 240 -iquants 2 31 -pquants 2 31 -bquants 2 31 -o "test2.m4v"

Yes, the first file was 2 pass, the line I posted was from the second pass. IIRC the first pass was identical except for --pass and the output was to a different file. It still used the same log file as pass 2 though.

Thanks :)


So you have the same problem like me. Give the statsfile of the second pass another name and it will look better. But you (and me) will never know if the first pass was totally useless.

[Doom9]

It seems encraw in the CSV has been updated as well and it should support all options available in the VfW except the profiles, and AviSynth input. So fire up your compilers ladies and gentlemen.

[Kopernikus]

I dont see any changes in the CVS. The last update of encraw dates 8 weeks ago. (at least here :))

[JoeBG]

Sorry for pointing this again:

Xvid Encraw ist useless because it does not use the statsfile of the first. Can someone confirm this?

[Doom9]

well, Isibaar told me what I posted here.. I'm sure I'll get a copy shortly to check this for myself and since I'm using MP4 for the next codec comparison, I plan to use the commandline encoder rather than the VfW encoder if somehow possible.

[JoeBG]

well, Isibaar told me what I posted here.. I'm sure I'll get a copy shortly to check this for myself and since I'm using MP4 for the next codec comparison, I plan to use the commandline encoder rather than the VfW encoder if somehow possible.

Sorry for bagging you so soon. Any news?

[Doom9]

when the time comes you'll know... it is not up to me to release unreleased software.

[JoeBG]

when the time comes you'll know... it is not up to me to release unreleased software.

But it´s hot news. So please keep us informed - thank you :)

[sysKin]

Hi, what's the current status of xvid_encraw? I volunteer to add anything I can add - this weekend if needed. What's left/broken/wrong? Any patches waiting to be checked in?

[Doom9]

@syskin: you might wanna talk to Isibaar about that.

@JoeBG: I run a news site so you can bet you'll know when I have something to share.

[Sagittaire]

Hi, what's the current status of xvid_encraw? I volunteer to add anything I can add - this weekend if needed. What's left/broken/wrong? Any patches waiting to be checked in?

cool ... :cool:

1) psnr calculation
2) it's xvid_encoraw but mp4 output could be great
3) all possible advanced ME search
4) multipasse encoding : we can use pseudo multipass with XviD vfw and zone option. For example if my final average quant encoding is ~q4 I use q4 for first pass in zone option. First pass -> write 1pass.log, second pass -> read 1pass.log and write 2pass.log ... etc

[bond]

basically enabling all xvid options in the cli would be great (you can use S_Os code as a startpoint)
.mp4 output, well ;) you can use mpeg4ip's or gpac's lib which are save (mpeg4ip has a xvid cli outputting mp4 in their cvs, which might be a modified encraw?)
.avs input

[Doom9]

guys, please. I have it on good authority that encraw is done (except for the profiles you can select in the GUI), it would make little sense for syskin to re-invent the wheel.

[bond]

guys, please. I have it on good authority that encraw is done (except for the profiles you can select in the GUI), it would make little sense for syskin to re-invent the wheel.with .mp4 output and .avs input?

[Doom9]

I doubt there's mp4 output. But if anybody were going to add that, it's better to wait until the CSV code (I don't know why you can't see it.. is there a shadow CSV? In the past year I've not seen much of activity anywhere so I'm wondering if development has moved to channels I'm not aware). Anyway, the submission deadline for codecs is the 16th so by that time I should have that encraw and if it's ready for release it will show up here as well.

[bond]

I doubt there's mp4 output. But if anybody were going to add that, it's better to wait until the CSV code (I don't know why you can't see it.. is there a shadow CSV? In the past year I've not seen much of activity anywhere so I'm wondering if development has moved to channels I'm not aware). Anyway, the submission deadline for codecs is the 16th so by that time I should have that encraw and if it's ready for release it will show up here as well.so .avs input is supported?

[Doom9]

yes, as I said, there is no point continuing the source from this thread. Now, patience is a virtue..

[Sagittaire]

$Id : xvid_encraw.c, v1.11.2.282003/06/2523:23:21 edgomez Exp $

xvid_encraw is edgomez's code ... ???

[JoeBG]

Hi, what's the current status of xvid_encraw? I volunteer to add anything I can add - this weekend if needed. What's left/broken/wrong?

I have posted the following problem very often but never got a feedback:
For me it seems to be that the first pass in xvid_encraw is useless because I have the suspicion, that xvid_encraw does not use the informations of the statsfile. The second pass is totally independent from the first pass. I have just the request, that someone with more skills than me can check this before the next release - thank you very much :)

[sysKin]

For me it seems to be that the first pass in xvid_encraw is useless because I have the suspicion, that xvid_encraw does not use the informations of the statsfile. The second pass is totally independent from the first pass. I have just the request, that someone with more skills than me can check this before the next release - thank you very much :)

I just looked around, apparently you need to specify stats filename with
-pass1 xvid.stats

and then

-pass2 xvid.stats

If you don't, everything goes weird. I fully admit encoder should be more rebust than this (and should not allow -pass1 and -pass2 in the same command, just in case).

[JoeBG]

I just looked around, apparently you need to specify stats filename with
-pass1 xvid.stats

and then

-pass2 xvid.stats

If you don't, everything goes weird. I fully admit encoder should be more rebust than this (and should not allow -pass1 and -pass2 in the same command, just in case).

I don´t think so. Please look at the problem if the commandlinde works:

@echo off
title Jempeg4-1400
echo.
echo Pass 1 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass1 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -turbo -o %Videofolder%\Film.m4v
cls
echo.
echo Pass 2 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass2 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -keyframe_boost 100 -close_i_red 1 20 -ccp_high 0 -ccp_low 5 -max_oi 5 -max_od 6 -overf_cs 10 -o %Videofolder%\Film.m4v
cls



To say it directly: This does not work: statsfile will not get read in the second pass and it would be very nice, if someone could check this or if someone could tell me my the mistake.

I can only point out, that xvid_encraw does not work and I hope that I´m making a mistake. Please confirm :)

[Sagittaire]

little test with xvid_encraw.exe

1) 2 pass encoding work fine
2) it's possible to make NPass encoding ... lol

here CLI for Multipasse with XviD

xvid_encraw.exe -i Encodage.avs -type 2 -o first.m4v -pass1 statsfile1 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o second.m4v -pass1 statsfile2 -pass2 statsfile1 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o third.m4v -pass2 statsfile2 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats

MP4Box.exe -nodrop -add third.m4v third.mp4


Multipass example:

I want 13500 Ko final size for my encoding

first pass q2 done 34741 Ko
second pass with first stat file done 13312 Ko
third pass with second stat file done 13500 Ko

and quality for 3 pass is better than 2 pass quality with better target bitrate and certainely better vbv reliability (if vbv are used) ... lol

[IgorC]

Sagi
thank you for information.

[JoeBG]

little test with xvid_encraw.exe

1) 2 pass encoding work fine
2) it's possible to make NPass encoding ... lol

here CLI for Multipasse with XviD

xvid_encraw.exe -i Encodage.avs -type 2 -o first.m4v -pass1 statsfile1 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o second.m4v -pass1 statsfile2 -pass2 statsfile1 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o third.m4v -pass2 statsfile2 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats

MP4Box.exe -nodrop -add third.m4v third.mp4


Multipass example:

I want 13500 Ko final size for my encoding

first pass q2 done 34741 Ko
second pass with first stat file done 13312 Ko
third pass with second stat file done 13500 Ko

and quality for 3 pass is better than 2 pass quality with better target bitrate and certainely better vbv reliability (if vbv are used) ... lol

You are not right with this. 2 pass Encoding is broken. If you try the following you will see, that you only get ggod quality if you rename statsfile of second pass to statsfile 2 and that you get the same quality without any first pass.

But try yourself:
xvid_encraw.exe -i Encodage.avs -type 2 -o first.m4v -pass1 statsfile1 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o second.m4v -pass2 statsfile1 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats

[JoeBG]

No Reaction?

Sorry, but this problem is bagging me since months and Sagittaire did not use a 2 pass commandline for his test. I´m really wondering, why noone is interested in this? Did noone test this? Xvid_Encraw is such an interesting project. Noone interested in this? Noone is testing a 2 pass commandline since months and noone is corresponding to this problem.

@ All

If noone will answer on this problem again, the xvid commandline for xvid_encraw will be dead - and I really wonder why noone is interested.

@ doom9

Don´t use xvid_encraw before this important problem is fixed. The first pass is useless.

But more important is, why noone is intersted in this problem? MeGUI with mencoder-Xvid is very bad because it never matches the size. Xvid Encraw is a solution but noone is really interested. But why? I dont understand all this. Has someone answers?

[dimzon]

Xvid Encraw is a solution but noone is really interested. But why? I dont understand all this. Has someone answers?
I can tell you only about myself. I'm switched from XviD to x264 encoding 6 month back...

[708145]

broken 2pass explains a lot. I use xvid_encraw in ELDER's xvid mode and had strange size matching problems.

A bugfix would help me, too.

bis besser,
T0B1A5

[JoeBG]

broken 2pass explains a lot. I use xvid_encraw in ELDER's xvid mode and had strange size matching problems.

A bugfix would help me, too.

bis besser,
T0B1A5

But noone is interested in this - there will be no help for you :(

I can tell you only about myself. I'm switched from XviD to x264 encoding 6 month back...

Do you think we shoul close this request? I´m really looking every day at this threat but noone is answering and noone is interested.

@ doom9

I´m so disappointed with this project. Mencoder is really a bad solution for meGUI, xvid_encraw is really a much worser solution than mencoder for meGui. So we should forget our targets for a Xvid commandline solution? Have you ever seen a video with a 2 pass xvid_encraw commandline?

[bond]

didnt doom9 say that there is already someone working on the cli? simply be patient ;)

[JoeBG]

didnt doom9 say that there is already someone working on the cli? simply be patient ;)

OK. But after such a long time with this problem and no solution for it I really don´t think that doom9 has the time to test it - especially the quality of the resulting videos. Do you really have hope for this project?

[Kurtnoise]

@echo off
title Jempeg4-1400
echo.
echo Pass 1 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass1 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -turbo -o %Videofolder%\Film.m4v
cls
echo.
echo Pass 2 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass2 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -keyframe_boost 100 -close_i_red 1 20 -ccp_high 0 -ccp_low 5 -max_oi 5 -max_od 6 -overf_cs 10 -o %Videofolder%\Film.m4v
cls



To say it directly: This does not work: statsfile will not get read in the second pass and it would be very nice, if someone could check this or if someone could tell me my the mistake.

I can only point out, that xvid_encraw does not work and I hope that I´m making a mistake. Please confirm :)

I just tested with xvid_encraw from the 1.1.0 sources and it seems to work fine without specifying an output file for the 1st pass...

xvid_encraw.exe -i Birth_test.avs -type 2 -pass1 Birth_test.stats -quality 6 -bitrate 50000 -max_bframes 2 -turbo
xvid_encraw.exe -i Birth_test.avs -type 2 -pass2 Birth_test.stats -o Birth_out.m4v -quality 6 -bitrate 50000 -max_bframes 2 -vhqmode 4 -bvhq

[snherbst]

Hi

Iam not good in this commandline tool either. Thats proberly because its not possible to just chose a profile. But any way which command line would be equal to the "Advanced Simple @ L5" Profile.

[Sagittaire]

I just tested with xvid_encraw from the 1.1.0 sources and it seems to work fine without specifying an output file for the 1st pass...

you can post this version here ... ???

[Kurtnoise]

sure...http://kurtnoise.free.fr/xvid_encraw-1.1.0.zip

[JoeBG]

sure...http://kurtnoise.free.fr/xvid_encraw-1.1.0.zip

You make my day :) By the way: -bitrate 50000 <- seems to be a littly high ;)

Edit:

Same Problem here. You have to give the statsfile of the second pass another name than the statsfile of the first pass if you want quality. => Xvid_Encraw does not read from statsfile of the first pass -> the statsfile of the first pass and the first pass itself is totally useless. If you only make a second pass without the first pass you have the same quality.

=> Sorry Kurt, your commandline does not work.

[Kurtnoise]

By the way: -bitrate 50000 <- seems to be a littly high ;)
It was just a crash test... :)


Same Problem here. You have to give the statsfile of the second pass another name than the statsfile of the first pass if you want quality.
huh ? for what for ?

=> Xvid_Encraw does not read from statsfile of the first pass
mmh...to be sure : make only a 1st pass first. Then, rename the stats file or put it in other folder. Second, make an encode with 2 pass (by using the same filename concerning stats file) and compare the different stats files...(diff is good for that). I'm pretty sure that the files are the same. This means that xvid_encraw read the stats from the 1st pass.

[buzzqw]

very dumb question

how i can mux/play with the resultin .raw file ??? :stupid:

BHH

[Yong]

very dumb question

how i can mux/play with the resultin .raw file ??? :stupid:

BHH
First you have to rename the raw xvid file to *.xvid extension,
then mux the raw xvid file with mp4box or mp4creator.
You can playback the raw xvid file with mplayer. ;)

[buzzqw]

@Yong
Thanks !

i successfully muxed raw xvid with mp4creator but latest versione of mp4bix (on celticdruid site) failed with an "unknow input file type"

thanks !

BHH

[Doom9]

mp4box can mux it just fine.. but it expects the .m4v extension. That also works for mp4creator by the way.

[buzzqw]

Thanks too Doom9 !

renaming movie.raw to movie.m4v resolved the unkown input error with mp4box !

BHH

[JoeBG]

Same Problem here. You have to give the statsfile of the second pass another name than the statsfile of the first pass if you want quality. => Xvid_Encraw does not read from statsfile of the first pass -> the statsfile of the first pass and the first pass itself is totally useless. If you only make a second pass without the first pass you have the same quality.

=> Sorry Kurt, your commandline does not work.

I really think, that noone ever tested xvid_encraw like I did.

Which tool makes snapshots from raw files or mp4 files? I will post my results in pictures to show you the problem.

@ Kurt

I have made a first pass, then copied the statsfile into a new folder. Then I made the second pass. How can I compare the two statsfiles? Diff is not a commandline function isn´t it?

[Kurtnoise]

this is a command line tool...;) Check this site (http://gnuwin32.sourceforge.net/packages.html). (diffutils)

And to be more clear...I said.

1/ Make an encode in one pass and save the statsfile.
2/ Make a full encode with 2 passes like you do by changing the filename.
3/ Then compare the stats files...

[Yong]

I think this cli apps indeed have problem,
like JoeBG said.
I tried encode video with 2nd pass without 1st pass stats file, it doesnt show any error when encoding start :rolleyes:

But xvid_encraw does use 1stpass stats file, without it xvid_encraw will create a big files ;)

[JoeBG]

And to be more clear...I said.

1/ Make an encode in one pass and save the statsfile.
2/ Make a full encode with 2 passes like you do by changing the filename.
3/ Then compare the stats files...

I will never understand this testing procedure or the difference to what I already did.


1/ Make an encode in one pass and save the statsfile.
Do you mean a first pass of an 2 Pass Encode? That´s what I already did. I wrote a skript with a stop after the first pass.



2/ Make a full encode with 2 passes like you do by changing the filename.
Why not starting the second pass? Why new encoding in 2 passes. Why changing the filename. I already stored a copy of the statsfile in a different folder.
=> I think I´m not intelligent enough to understand the procedure :(


3/ Then compare the stats files..

Which ones?

[bond]

guys, please. I have it on good authority that encraw is done (except for the profiles you can select in the GUI), it would make little sense for syskin to re-invent the wheel.ok now 1 month is gone. any news on this "done" tool? isibaar? :D

[Doom9]

well.. what was done was posted here. I compiled a list of missing options from that release and sent it to syskin.

[bond]

well.. what was done was posted here. I compiled a list of missing options from that release and sent it to syskin.hm, you mean the 1.1 compile from kurtnoise includes all the changes from isibaar? or did i oversee some other thingie being posted?

i wonder because when i look at the cvs (http://www.xvid.org/cvs/chora/cvs.php/xvidcore/examples?login=2&sbt=1)i only see changes being 3 months old, made by suxen_drol, but not by isibaar!?

[Doom9]

hm, you mean the 1.1 compile from kurtnoise includes all the changes from isibaar?I don't know who wrote it, but it's the current state of encraw. And considering there's a whole new codec not in the CVS I could start a whole series of rumours about a parallel secret CVS or whatnot. Bottom line.. you can get what's posted in this thread and that's it. MeGUI already supports that featureset (not publicly released yet).. if syskin makes any update to the CSV they will be supported.

[bond]

well time for testing then :D

[bond]

if thats the final version it definitely cant keep up with S_O's version. altough this +/- sheme is messy it still offers as good as all options, whereas this 1.1 build definitely does not

[Doom9]

Well, there are in fact multiple major issues I found when giving it more than a 1000 frames to test. I'm in the process of sending a long bugreport to Michael. Some of the issues JoeBG reported are definitely there, but it does get a lot worse :(

Encoding past frame 9999 is impossible.

CBR bitrate control is broken (encodes everything at Q2).
2 pass encoding with a non existing statsfile is possible, and it results in a Q2 stream
2 pass encoding with an existing statsfile results in the majority of all frames being encoded at Q31.. naturally that means the size is off.
The statsfile generated during the first pass is correct, and it can be used to make a second pass via VfW that comes out just as it should.
This behavior seems to happen irrespective of the settings (I tried a bunch of settings but obviously not every permutation).

@JoeBG: that's the kind of analysis I think is reasonable to make.. it gives you a lot more pointers than your "it doesn't work, try it" ;)

[squid_80]

Encoding past frame 9999 is impossible.That's a simple #define in the source code, there's a comment that it's only for testing short sequences.2 pass encoding with a non existing statsfile is possible, and it results in a Q2 streamSame thing happens with the vfw interface if the statsfile is bad.

If people want the features of S_O's build why not just merge the sources with the current CVS code?

[Doom9]

If people want the features of S_O's build why not just merge the sources with the current CVS code?somebody needs to authorize that.. and S_O's build is quite messy, so I'd probably not looking forward to that if I'd be in a position to chose.

P.S. The bitrate has to be given in bits/s but all the rate control issues are still there.

[Doom9]

I have an update: CBR RC is not broken.. but encraw needs the bitrate in bits/s (I suspected but because the results varied all over the place I got confused), and it does work.. it's not as accurate as 2 pass though (2 pass in the VfW of course). I did another 2 pass test with bits/s bitrate for both passes.. it was only a trailer, and it wasn't spot on either, but 200KB off.. doing a full movie now to check.

[squid_80]

If I'm reading the code right, all the extra parameters for 2nd pass like overflow treatment and curve compression are left as 0. Same goes for the CBR settings (Reaction delay, averaging period and smoother). Fixing them to defaults is pretty easy, if anyone's still interested I can post a modified build.

[dimzon]

because with .mp4 output you can edit the output in various tools and dont need mp4box or mp4creator :p
And Yet Another Reason - you can preview right after encoding (without any additional tools)

Seem's like I can spend a little time to add AVI output to this utility (reuse some part of avs2avi code)...

[squid_80]

Seem's like I can spend a little time to add AVI output to this utility (reuse some part of avs2avi code)...
Done it already (didn't mention that in my previous post :)).

[bond]

if you want .avi output why not simply use vfw in virtualdub?

better add support for some real containers, like mkv or mp4 ;)

[squid_80]

if you want .avi output why not simply use vfw in virtualdub?

better add support for some real containers, like mkv or mp4 ;)
..And here in person is the reason why I didn't say anything. ;)
.avi output is a start. Once I figure out what the calls are for mkv (maybe mp4, but look at the trouble gpac causes with x264) I'll probably add that too.

[bond]

..And here in person is the reason why I didn't say anything. ;) you guessed right ;)

edit:
1) shame on you added avi support!
2) if you add mkv support make sure the cli writes the stream in "native mpeg-4" and not in the vfw mode as virtualdubmod, as i really dont see the sense in recreating with the cli whats already possible easily in other ways...

(maybe mp4, but look at the trouble gpac causes with x264) I'll probably add that too. gpac doesnt really cause trouble to x264... the only issue caused by gpac itself i know is that sometimes plain cvs checkouts bork, but then again its no wonder that cvs isnt always stable. after all its also not needed to use latest cvs in most cases
the rest was caused by issues in x264's calling of gpac (one time not setting the track enabled flag, the other time having issues with the 64bit times)
thats basically it

than again you can also use the mp4 lib from mpeg4ip if you dont like gpac...

[Doom9]

@squid_80:
Here's the list of missing features I compiled:

Additional zone options: (start with i-frame, grayscale, cartoon, chroma optimizer, bvop sensitivity),
minimum and maximum quantizer, trellis,
top field first mode for interlaced, PAR/DAR settings, VBV options and chroma motion.

Fixing them to defaults is pretty easy, if anyone's still interested I can post a modified build.It would be nice to be able to control those since they're currently missing (goes for both 2 pass and 1 pass RC settings)
all the RC related options aren't there.


And when it comes to XviD 1.2, a new option like -nbthreads would be nice to control how many threads are being used.

Done it alreadyIs it already in the CVS?

[Zero1]

I guess if you are going to add MKV and MP4 support that's great, so long as we can still output raw (outputting raw and muxing later has saved me a few times when people have been complaining about x264's borked mp4 out).

[squid_80]

@squid_80:
Here's the list of missing features I compiled:

Additional zone options: (start with i-frame, grayscale, cartoon, chroma optimizer, bvop sensitivity),
minimum and maximum quantizer, trellis,
top field first mode for interlaced, PAR/DAR settings, VBV options and chroma motion.
It would be nice to be able to control those since they're currently missing (goes for both 2 pass and 1 pass RC settings)
all the RC related options aren't there. Here's what I've changed the default settings to (most of this is just to match vfw):
- bframes to 2, adjustable using -max_bframes
- Key frame interval to 300, adjustable using -max_key_interval
- Default quality = 6, should match vfw's motion search precision settings
- Unrestricted profile (currently not adjustable)
- Chroma motion on, can be disabled with -nochromamotion
- Trellis on, can be disabled with -notrellis
- Default VHQ mode = 1, should match vfw's settings
- Packed mode and closed gop are on, can be disabled with -nopacked and -noclosed_gop
- PAR can be set using -par <integer> where 1 = square, 2 = 4:3 PAL, 3 = 4:3 NTSC etc... currently working on custom support.
- AVI output possible using -avi <filename.avi> (for verification purpose only, the avi files are produced using the AVIFile API so they're a bit rough, most people would probably remux them with audio anyway.) Note that it's possible to output a raw file and avi at the same time.
- Fixed single, 1pass and 2pass parameters to default vfw values. I'll make cli parameters for these as soon as I get a chance. Also look for the stats file in 2pass and don't proceed if it's not there.
- Force min/max quants to 2/31. Again cli parameters are coming (I'm thinking probably -imin, -imax, -pmin etc.)
And when it comes to XviD 1.2, a new option like -nbthreads would be nice to control how many threads are being used. There's actually a way for xvidcore.dll to provide the number of cpu cores to the calling program, but at the moment it doesn't work (returns 0). So I'll make it use this value by default then when the functionality is added to xvidcore it should select the correct number of threads automatically. I'll add an override switch anyway, since encraw is all about diagnostics.
Is it already in the CVS?
Nope, I don't have access to xvid's CVS. I'm just working on my own here (but I see Isibaar did recently check in a fix for that 9999 frame limit).

[Doom9]

@squid: sounds like it's finally moving forward :) Doesn't VDub use AVIFile as well to write AVIs? Naturally in the end it would be great if you could submit a patch to xvid-devel so that the whole thing can be merged.
Isibaars patch finally fixed encoding for me.. I'm currently encoding the second movie and then check for size discrepancies if there's any.

[Doom9]

Alright, I did some more testing with a build that no longer has the frame number limit and no bugs with regards to that. I encoded two movies in two pass, the filesize matched what I wanted by a few 100 KB.. so the usual XviD accuracy. I'm now redoing one second pass with a non existing stats file to see what that results in. But I think it's safe to say that encraw does what it's supposed two in two pass mode.
With 10% done, it looks like without a stats file everything is being encoded at quantizer 2.. the projected filesize is way too big.

[squid_80]

It'll still meet the filesize but with all the 2nd pass RC options set to 0 doesn't it look a bit...off? Especially if there's sudden jumps from high to low motion or vice-versa.

[sam1974]

Is it possible that it breaks encodig after frame no. 9999. After this -1 follows and it breaks. I've tested it with different sources.

[Doom9]

@sam1974: I think reading up a bit would hurt: http://forum.doom9.org/showpost.php?p=767689&postcount=187

[squid_80]

Is it possible that it breaks encodig after frame no. 9999. After this -1 follows and it breaks. I've tested it with different sources.
I'm guessing you mean this type of output: 9997: key=0, time= 0, len= 6 | type=P, quant= 4, len= 5883
9998: key=0, time= 47, len= 10416 | type=B, quant= 7, len= 2884
9999: key=0, time= 0, len= 6 | type=P, quant= 4, len= 7538
-1: key=0, time= 47, len= 11666 | type=B, quant= 7, len= 3460
-1: key=0, time= 0, len= 6 | type=P, quant= 4, len= 8212
-1: key=0, time= 0, len= -5
Tot: enctime(ms) =9495.00, length(bytes) = 1842441
Avg: enctime(ms) = 31.44, fps = 31.81, length(bytes) = 6100The -1 reference just means it's reached the end of the input frames and is flushing any remaining output frames. It happens at frame 9999 because that's a hardcoded limit that used to exist. It has since been removed.

[handtruck]

I looked up and down the thread.. What happend to full quality first pass.. It's listed on the first page as part of the switches (-full_1p), but doesn't work in usage, and doesn't show up in -help.

[shon3i]

What i get will full quality first pass. Did i get better quality.

[Kopernikus]

I looked up and down the thread.. What happend to full quality first pass.. It's listed on the first page as part of the switches (-full_1p), but doesn't work in usage, and doesn't show up in -help.

Whose build do you use?

[handtruck]

I used the attachment on the very first post of this thread (which I believe has been updated), and I also tried the most recent link on this thread as well.

[woah!]

where do you get your patched versions squid_80?

the one in the first post isnt your newer one is it, or arent you releasing them just yet?

[squid_80]

where do you get your patched versions squid_80?

the one in the first post isnt your newer one is it, or arent you releasing them just yet?
I haven't released any yet, as soon as I implement all the options I mentioned in my post to Doom9 I'll make it available.

[woah!]

ah thats cool i will stop searching for it then heh..

[squid_80]

Ok, here's an unrefined build: ftp://squid80.no-ip.com/xvid_encraw.zip

The usage text should list the new options, unless I've left them off. Note the bitrate is in kbps, not bps. The reason I'm posting it unfinished is because I've just spent two hours figuring out why I was losing/gaining frames with the .avi output - it should be fixed now, but if you end up with the wrong number of frames please let me know and try and copy the final output screen. Also please try out the zone options, the functionality hasn't changed but the code behind them has.
Todo: implement the remaining options (rate control, zone options, custom par/dar, vbv... anything else?)
Stricter argument checking.
Support for other output formats (hoping for DaveEL to dig up his avs2matroska sources).
Sleep..

Bugs: -debug is broken, don't know why (it was like that when I got here!).
It's probably not a good idea to run more than one instance simultaneously.
Parameters can be repeated with different values on the command line if you're feeling silly - don't think I'll bother fixing this.

[buzzqw]

@squid_80
just to reserve you some bandwith i made a link on my site

www.64k.it/andres/xvid_encraw-build-20-01-2006.zip

if is OK i will host it until a new build come up

thanks !

BHH

[buzzqw]

xvid_encraw.exe -i movie.avs -type 2 -pass1 xvid.stats -bitrate 1000 -full1pass -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -framerate 25.000000 -turbo -quality 6 -vhqmode 1 -max_key_interval 250 -imin 2 -bmin 2 -pmin 2 -par 1 -qtype 0 -avi movie.avi

is not fuctional, the bug(?) is in full1pass. If i remove it the string is ok

BHH

[buzzqw]

even -nopacked is broken. It will encode all file, then will continue ... (ultil a ctrl+c ;) )

BHH

[squid_80]

Can you try again with the new download please?

[buzzqw]

OK !!!

both

xvid_encraw.exe -i movie.avs -type 2 -pass1 xvid.stats -bitrate 515 -full1pass -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -framerate 25.000000 -quality 6 -vhqmode 1 -noclosed_gop -max_key_interval 250 -imin 2 -bmin 2 -pmin 2 -par 1 -qtype 0 -avi movie.avi

and nopacked is OK!

i have already uploaded the new build at www.64k.it/andres/xvid_encraw-build-20-01-2006.zip

:thanks: squid_80 !

BHH

[squid_80]

BTW, the only thing -full1pass seems to do (going from the vfw code) is encode the whole movie at quant 2. So -bitrate, -imin -pmin etc. have no effect.

[buzzqw]

xvid_encraw.exe -i "movie.avs" -type 2 -pass1 xvid.stats -bitrate 515 -full1pass -max_bframes 2 -bqu
ant_ratio 150 -bquant_offset 100 -framerate 25.000000 -turbo -quality 6 -vhqmode 1 -noclosed_gop -ma
x_key_interval 250 -imin 2 -bmin 2 -pmin 2 -par 1 -qtype 0 -avi movie.avi"
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Trying to retrieve width and height from input header
0: key=2, time= 0, len= 2145 | type=I, quant= 2, len= 2145
1: key=0, time= 0, len= 0
2: key=0, time= 0, len= 0
3: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
4: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
5: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
6: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
7: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
8: key=0, time= 31, len= 6 | type=P, quant= 2, len= 6
9: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
10: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
11: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
12: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
13: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
14: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
15: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
16: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
17: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
18: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
19: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
20: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
21: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
22: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
23: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
24: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
25: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
26: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
27: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
28: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
29: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
30: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
31: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
32: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
33: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
34: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
35: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
36: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
37: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
38: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
39: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
40: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
41: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
42: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
43: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
44: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
45: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
46: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
47: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
48: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
49: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
50: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
51: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
52: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
53: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
54: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
55: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
56: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
57: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
58: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
59: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
60: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
61: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
62: key=0, time= 32, len= 3463 | type=B, quant= 4, len= 764
63: key=0, time= 15, len= 764 | type=B, quant= 4, len= 764
64: key=0, time= 0, len= 6 | type=P, quant= 2, len= 2705
65: key=2, time= 15, len= 5031 | type=B, quant= 4, len= 1507
66: key=0, time= 0, len= 6 | type=I, quant= 2, len= 3530
67: key=2, time= 0, len= 4877 | type=I, quant= 2, len= 4877
68: key=2, time= 0, len= 4615 | type=I, quant= 2, len= 4615
69: key=2, time= 0, len= 4221 | type=I, quant= 2, len= 4221
70: key=2, time= 0, len= 4866 | type=I, quant= 2, len= 4866
71: key=0, time= 94, len= 5021 | type=P, quant= 2, len= 5021
72: key=0, time= 109, len= 6668 | type=B, quant= 4, len= 1825
73: key=0, time= 0, len= 6 | type=P, quant= 2, len= 4849
74: key=0, time= 109, len= 8748 | type=B, quant= 4, len= 1988
75: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6766
76: key=0, time= 62, len= 10099 | type=B, quant= 4, len= 1913
77: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8192
78: key=0, time= 47, len= 9879 | type=B, quant= 4, len= 1688
79: key=0, time= 16, len= 1531 | type=B, quant= 4, len= 1531
80: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8197
81: key=0, time= 63, len= 9110 | type=B, quant= 4, len= 1515
82: key=0, time= 16, len= 1411 | type=B, quant= 4, len= 1411
83: key=0, time= 0, len= 6 | type=P, quant= 2, len= 7601
84: key=0, time= 62, len= 10160 | type=B, quant= 4, len= 1515
85: key=0, time= 16, len= 1495 | type=B, quant= 4, len= 1495
86: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8651
87: key=0, time= 62, len= 9014 | type=B, quant= 4, len= 1552
88: key=0, time= 0, len= 6 | type=P, quant= 2, len= 7468
89: key=0, time= 63, len= 10907 | type=B, quant= 4, len= 2165
90: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8748
91: key=0, time= 79, len= 8409 | type=P, quant= 2, len= 8409
92: key=2, time= 16, len= 10202 | type=I, quant= 2, len= 10202
93: key=0, time= 63, len= 7777 | type=P, quant= 2, len= 7777
94: key=0, time= 46, len= 8951 | type=P, quant= 2, len= 8951
95: key=0, time= 47, len= 10556 | type=P, quant= 2, len= 10556
96: key=0, time= 47, len= 10345 | type=P, quant= 2, len= 10345
97: key=0, time= 63, len= 14491 | type=B, quant= 4, len= 2349
98: key=0, time= 0, len= 6 | type=P, quant= 2, len= 12148
99: key=0, time= 62, len= 11077 | type=B, quant= 4, len= 2044
100: key=0, time= 16, len= 6 | type=P, quant= 2, len= 9039
101: key=0, time= 47, len= 9762 | type=B, quant= 4, len= 1462
102: key=0, time= 0, len= 1556 | type=B, quant= 4, len= 1556
103: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8306
104: key=0, time= 32, len= 9558 | type=B, quant= 4, len= 1496
105: key=0, time= 16, len= 1327 | type=B, quant= 4, len= 1327
106: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8068
107: key=0, time= 31, len= 8950 | type=B, quant= 4, len= 1248
108: key=0, time= 0, len= 1321 | type=B, quant= 4, len= 1321
109: key=0, time= 0, len= 6 | type=P, quant= 2, len= 7708
110: key=0, time= 47, len= 9213 | type=B, quant= 4, len= 1294
111: key=0, time= 15, len= 1344 | type=B, quant= 4, len= 1344
112: key=0, time= 0, len= 6 | type=P, quant= 2, len= 7925
113: key=0, time= 31, len= 8991 | type=B, quant= 4, len= 1269
114: key=0, time= 16, len= 1398 | type=B, quant= 4, len= 1398
115: key=0, time= 0, len= 6 | type=P, quant= 2, len= 7728
116: key=0, time= 47, len= 9809 | type=B, quant= 4, len= 1318
117: key=0, time= 15, len= 1817 | type=B, quant= 4, len= 1817
118: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8497
119: key=0, time= 62, len= 13535 | type=B, quant= 4, len= 2567
120: key=0, time= 0, len= 6 | type=P, quant= 2, len= 10974
121: key=0, time= 47, len= 9184 | type=P, quant= 2, len= 9184
122: key=0, time= 31, len= 8674 | type=P, quant= 2, len= 8674
123: key=0, time= 32, len= 8736 | type=P, quant= 2, len= 8736
124: key=0, time= 32, len= 8660 | type=P, quant= 2, len= 8660
125: key=0, time= 31, len= 7806 | type=P, quant= 2, len= 7806
126: key=0, time= 32, len= 7735 | type=P, quant= 2, len= 7735
127: key=0, time= 32, len= 8509 | type=P, quant= 2, len= 8509
128: key=0, time= 47, len= 9179 | type=P, quant= 2, len= 9179
129: key=0, time= 31, len= 10274 | type=P, quant= 2, len= 10274
130: key=0, time= 31, len= 10651 | type=P, quant= 2, len= 10651
131: key=0, time= 32, len= 11225 | type=P, quant= 2, len= 11225
132: key=0, time= 47, len= 11357 | type=P, quant= 2, len= 11357
133: key=0, time= 31, len= 9925 | type=P, quant= 2, len= 9925
134: key=2, time= 31, len= 15167 | type=B, quant= 4, len= 2965
135: key=0, time= 0, len= 6 | type=I, quant= 2, len= 12208
136: key=0, time= 78, len= 10860 | type=B, quant= 4, len= 2203
137: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8663
138: key=0, time= 47, len= 9996 | type=P, quant= 2, len= 9996
139: key=0, time= 47, len= 10427 | type=P, quant= 2, len= 10427
140: key=0, time= 47, len= 10991 | type=P, quant= 2, len= 10991
141: key=0, time= 62, len= 10725 | type=P, quant= 2, len= 10725
142: key=0, time= 31, len= 9995 | type=P, quant= 2, len= 9995
143: key=0, time= 47, len= 13505 | type=B, quant= 4, len= 2435
144: key=0, time= 0, len= 6 | type=P, quant= 2, len= 11076
145: key=0, time= 46, len= 10644 | type=B, quant= 4, len= 1762
146: key=0, time= 0, len= 6 | type=P, quant= 2, len= 8888
147: key=0, time= 47, len= 11643 | type=B, quant= 4, len= 1792
148: key=0, time= 16, len= 1619 | type=B, quant= 4, len= 1619
149: key=0, time= 0, len= 6 | type=P, quant= 2, len= 9857


the first frames (black almost) is encoded at quant 2 but other at 2 or 4 (for b frames)

BHH

[squid_80]

the first frames (black almost) is encoded at quant 2 but other at 2 or 4 (for b frames)

BHH
....yeah, that's what I said. Bitrate and quantizer min/max don't do anything with -full1pass active. Quantizer for B-frames:
= avg(prev p quant + next p quant)*bquant_ratio + bquant_offset
= avg(2 + 2) *1.5 + 1
= 2*1.5+1
= 4.

This however worries me: 64: key=0, time= 0, len= 6 | type=P, quant= 2, len= 2705
65: key=2, time= 15, len= 5031 | type=B, quant= 4, len= 1507
66: key=0, time= 0, len= 6 | type=I, quant= 2, len= 3530
67: key=2, time= 0, len= 4877 | type=I, quant= 2, len= 4877
68: key=2, time= 0, len= 4615 | type=I, quant= 2, len= 4615A B-frame reported as a key frame and an I-frame not being reported as a key frame. Looks kinda weird but I think that's what you get with packed bitstream. The .avi file might be a bit b0rked, open it with vdub and skip through using the key buttons and see if any keyframes look messed up.

[buzzqw]

Ok, this time without packed frames

this is the command line

xvid_encraw.exe -i "C:\Programmi\PureBasic\Prove\movie.avs" -type 2 -pass1 xvid.stats -bitrate 515 -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -framerate 25.000000 -quality 6 -vhqmode 1 -nopacked -noclosed_gop -max_key_interval 250 -imin 2 -bmin 2 -pmin 2 -par 4 -qtype 0 -avi "C:\Programmi\PureBasic\Prove\movie.avi"

and this is the first encoded frames


C:\Programmi\PureBasic\Prove>C:\Programmi\PureBasic\Prove\exe\encoder\xvid_encraw.exe -i "C:\Progra
mmi\PureBasic\Prove\movie.avs" -type 2 -pass1 xvid.stats -bitrate 515 -max_bframes 2 -bquant_ratio 1
50 -bquant_offset 100 -framerate 25.000000 -quality 6 -vhqmode 1 -nopacked -noclosed_gop -max_key_in
terval 250 -imin 2 -bmin 2 -pmin 2 -par 4 -qtype 0 -avi "C:\Programmi\PureBasic\Prove\movie.avi"
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Trying to retrieve width and height from input header
0: key=2, time= 0, len= 1677
1: key=0, time= 0, len= 0
2: key=0, time= 0, len= 0
3: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
4: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
5: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
6: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
7: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
8: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
9: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
10: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
11: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
12: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
13: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
14: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
15: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
16: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
17: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
18: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
19: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
20: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
21: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
22: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
23: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
24: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
25: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
26: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
27: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
28: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
29: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
30: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
31: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
32: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
33: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
34: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
35: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
36: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
37: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
38: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
39: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
40: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
41: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
42: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
43: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
44: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
45: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
46: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
47: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
48: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
49: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
50: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
51: key=0, time= 15, len= 6 | type=P, quant= 2, len= 6
52: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
53: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
54: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
55: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
56: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
57: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
58: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
59: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
60: key=0, time= 16, len= 6 | type=P, quant= 2, len= 6
61: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
62: key=0, time= 0, len= 2115 | type=P, quant= 2, len= 6
63: key=0, time= 0, len= 600 | type=B, quant= 4, len= 600
64: key=0, time= 0, len= 600 | type=B, quant= 4, len= 600
65: key=2, time= 0, len= 2999 | type=P, quant= 2, len= 2115
66: key=0, time= 0, len= 1184 | type=B, quant= 4, len= 1184
67: key=2, time= 16, len= 4177 | type=I, quant= 2, len= 2999
68: key=2, time= 16, len= 3557 | type=I, quant= 2, len= 4177
69: key=0, time= 15, len= 3950 | type=I, quant= 2, len= 3557
70: key=0, time= 16, len= 4714 | type=P, quant= 2, len= 3950
71: key=0, time= 16, len= 5261 | type=P, quant= 2, len= 4714
72: key=0, time= 0, len= 1893 | type=B, quant= 4, len= 1893
73: key=0, time= 32, len= 6198 | type=P, quant= 2, len= 5261
74: key=0, time= 15, len= 1482 | type=B, quant= 4, len= 1482
75: key=0, time= 15, len= 8606 | type=P, quant= 2, len= 6198
76: key=0, time= 16, len= 1953 | type=B, quant= 4, len= 1953
77: key=0, time= 16, len= 6563 | type=P, quant= 2, len= 8606
78: key=0, time= 16, len= 1307 | type=B, quant= 4, len= 1307
79: key=0, time= 0, len= 7858 | type=P, quant= 2, len= 6563
80: key=0, time= 0, len= 1414 | type=B, quant= 4, len= 1414
81: key=0, time= 0, len= 1272 | type=B, quant= 4, len= 1272
82: key=0, time= 16, len= 7627 | type=P, quant= 2, len= 7858
83: key=0, time= 0, len= 1216 | type=B, quant= 4, len= 1216
84: key=0, time= 16, len= 1168 | type=B, quant= 4, len= 1168
85: key=0, time= 15, len= 8266 | type=P, quant= 2, len= 7627
86: key=0, time= 15, len= 1301 | type=B, quant= 4, len= 1301
87: key=0, time= 0, len= 1275 | type=B, quant= 4, len= 1275
88: key=0, time= 0, len= 7126 | type=P, quant= 2, len= 8266
89: key=0, time= 16, len= 1272 | type=B, quant= 4, len= 1272
90: key=2, time= 16, len= 11673 | type=P, quant= 2, len= 7126
91: key=0, time= 15, len= 2345 | type=B, quant= 4, len= 2345
92: key=2, time= 0, len= 8483 | type=I, quant= 2, len= 11673
93: key=0, time= 0, len= 6748 | type=I, quant= 2, len= 8483
94: key=0, time= 0, len= 8067 | type=P, quant= 2, len= 6748
95: key=0, time= 15, len= 9605 | type=P, quant= 2, len= 8067
96: key=0, time= 16, len= 11307 | type=P, quant= 2, len= 9605
97: key=0, time= 31, len= 2107 | type=B, quant= 4, len= 2107
98: key=0, time= 16, len= 10798 | type=P, quant= 2, len= 11307
99: key=0, time= 16, len= 1950 | type=B, quant= 4, len= 1950
100: key=0, time= 46, len= 8874 | type=P, quant= 2, len= 10798
101: key=0, time= 16, len= 1219 | type=B, quant= 4, len= 1219
102: key=0, time= 0, len= 1157 | type=B, quant= 4, len= 1157
103: key=0, time= 47, len= 8092 | type=P, quant= 2, len= 8874
104: key=0, time= 0, len= 1167 | type=B, quant= 4, len= 1167
105: key=0, time= 0, len= 1348 | type=B, quant= 4, len= 1348
106: key=0, time= 16, len= 7644 | type=P, quant= 2, len= 8092
107: key=0, time= 15, len= 1140 | type=B, quant= 4, len= 1140
108: key=0, time= 0, len= 1141 | type=B, quant= 4, len= 1141
109: key=0, time= 15, len= 7585 | type=P, quant= 2, len= 7644
110: key=0, time= 0, len= 1152 | type=B, quant= 4, len= 1152
111: key=0, time= 16, len= 1008 | type=B, quant= 4, len= 1008
112: key=0, time= 0, len= 7306 | type=P, quant= 2, len= 7585
113: key=0, time= 16, len= 900 | type=B, quant= 4, len= 900
114: key=0, time= 16, len= 1017 | type=B, quant= 4, len= 1017
115: key=0, time= 15, len= 7645 | type=P, quant= 2, len= 7306
116: key=0, time= 0, len= 988 | type=B, quant= 4, len= 988
117: key=0, time= 16, len= 1008 | type=B, quant= 4, len= 1008
118: key=0, time= 31, len= 8684 | type=P, quant= 2, len= 7645
119: key=0, time= 16, len= 1797 | type=B, quant= 4, len= 1797
120: key=0, time= 15, len= 9793 | type=P, quant= 2, len= 8684
121: key=0, time= 0, len= 2150 | type=B, quant= 4, len= 2150
122: key=0, time= 16, len= 9496 | type=P, quant= 2, len= 9793
123: key=0, time= 15, len= 2105 | type=B, quant= 4, len= 2105
124: key=0, time= 16, len= 8932 | type=P, quant= 2, len= 9496
125: key=0, time= 16, len= 1927 | type=B, quant= 4, len= 1927
126: key=0, time= 15, len= 9062 | type=P, quant= 2, len= 8932
127: key=0, time= 0, len= 1830 | type=B, quant= 4, len= 1830
128: key=0, time= 15, len= 11486 | type=P, quant= 2, len= 9062
129: key=0, time= 16, len= 2487 | type=B, quant= 4, len= 2487
130: key=0, time= 15, len= 13209 | type=P, quant= 2, len= 11486
131: key=0, time= 16, len= 3100 | type=B, quant= 4, len= 3100
132: key=0, time= 0, len= 10700 | type=P, quant= 2, len= 13209
133: key=0, time= 16, len= 10458 | type=P, quant= 2, len= 10700
134: key=0, time= 15, len= 2690 | type=B, quant= 4, len= 2690
135: key=0, time= 16, len= 8613 | type=P, quant= 2, len= 10458
136: key=0, time= 15, len= 1913 | type=B, quant= 4, len= 1913
137: key=2, time= 0, len= 11732 | type=P, quant= 2, len= 8613
138: key=0, time= 32, len= 1976 | type=B, quant= 4, len= 1976
139: key=0, time= 15, len= 9670 | type=I, quant= 2, len= 11732
140: key=0, time= 0, len= 10419 | type=P, quant= 2, len= 9670
141: key=0, time= 32, len= 13053 | type=P, quant= 2, len= 10419
142: key=0, time= 15, len= 2471 | type=B, quant= 4, len= 2471
143: key=0, time= 0, len= 10982 | type=P, quant= 2, len= 13053
144: key=0, time= 0, len= 1906 | type=B, quant= 4, len= 1906
145: key=0, time= 15, len= 10414 | type=P, quant= 2, len= 10982
146: key=0, time= 16, len= 1450 | type=B, quant= 4, len= 1450
147: key=0, time= 15, len= 1623 | type=B, quant= 4, len= 1623
148: key=0, time= 16, len= 9577 | type=P, quant= 2, len= 10414
149: key=0, time= 0, len= 1126 | type=B, quant= 4, len= 1126
150: key=0, time= 0, len= 1229 | type=B, quant= 4, len= 1229


I big note: without packed bitstream the file size is correct, but with is not so correct (aiming at 800kb)

second pass with -nopacked -> size 988KB
-1: key=0, time= 0, len= -5 | type=P, quant= 3, len= 4234
Tot: enctime(ms) =5481.00, length(bytes) = 1002142
Avg: enctime(ms) = 17.29, fps = 57.84, length(bytes) = 3161

second pass without -> size KB 793
-1: key=0, time= 16, len= 3801 | type=P, quant= 3, len= 3801
-1: key=0, time= 0, len= -5
Tot: enctime(ms) =5655.00, length(bytes) = 802655
Avg: enctime(ms) = 17.84, fps = 56.06, length(bytes) = 2532


i know the sample is short ... i would like to know why :stupid:

thanks

BHH

[squid_80]

Ok, this time without packed frames

this is the command line

xvid_encraw.exe -i "C:\Programmi\PureBasic\Prove\movie.avs" -type 2 -pass1 xvid.stats -bitrate 515 -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -framerate 25.000000 -quality 6 -vhqmode 1 -nopacked -noclosed_gop -max_key_interval 250 -imin 2 -bmin 2 -pmin 2 -par 4 -qtype 0 -avi "C:\Programmi\PureBasic\Prove\movie.avi"Aargh.. "-type 2 -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -framerate 25.000000 -quality 6 -vhqmode 1 -qtype 0" are all defaults. No need to clog up the commandline with them. Also bitrate does nothing on 1st pass, it is only useful for -single or -pass2.
and this is the first encoded frames


61: key=0, time= 0, len= 6 | type=P, quant= 2, len= 6
62: key=0, time= 0, len= 2115 | type=P, quant= 2, len= 6
63: key=0, time= 0, len= 600 | type=B, quant= 4, len= 600
64: key=0, time= 0, len= 600 | type=B, quant= 4, len= 600
65: key=2, time= 0, len= 2999 | type=P, quant= 2, len= 2115
66: key=0, time= 0, len= 1184 | type=B, quant= 4, len= 1184
67: key=2, time= 16, len= 4177 | type=I, quant= 2, len= 2999
68: key=2, time= 16, len= 3557 | type=I, quant= 2, len= 4177
69: key=0, time= 15, len= 3950 | type=I, quant= 2, len= 3557
70: key=0, time= 16, len= 4714 | type=P, quant= 2, len= 3950
71: key=0, time= 16, len= 5261 | type=P, quant= 2, len= 4714
72: key=0, time= 0, len= 1893 | type=B, quant= 4, len= 1893
That makes it a bit easier to see. The stats on the left are the true order, the stats on the right are from the stored order. You can tell by matching up the sizes - b-frames are stored after the frames they reference.
I big note: without packed bitstream the file size is correct, but with is not so correct (aiming at 800kb)

second pass with -nopacked -> size 988KB
-1: key=0, time= 0, len= -5 | type=P, quant= 3, len= 4234
Tot: enctime(ms) =5481.00, length(bytes) = 1002142
Avg: enctime(ms) = 17.29, fps = 57.84, length(bytes) = 3161

second pass without -> size KB 793
-1: key=0, time= 16, len= 3801 | type=P, quant= 3, len= 3801
-1: key=0, time= 0, len= -5
Tot: enctime(ms) =5655.00, length(bytes) = 802655
Avg: enctime(ms) = 17.84, fps = 56.06, length(bytes) = 2532


i know the sample is short ... i would like to know why :stupid:

thanks

BHHPacked bitstream is not a parameter that can be changed without redoing the first pass.

[JoeBG]

Works great, no problems anymore.

Next I try a whole film and not only my testclips.

Is there any update from the old xvidcore.dll ?

[Doom9]

Is there any update from the old xvidcore.dll ?Since the API has not been changed afaik, it should be possible to replace xvidcore.dll with the latest one.. even one compiled for 2 cores.

[buzzqw]

two note:

i had redo both first and secon pass with nopacked, and another two round without (but not deleting stats file :o )

i am using latest xvidcore dll for 2 core

a very big :thanks: squid_80 ! for your good work !!

BHH

[JoeBG]

In encodet the same video which I tried before with mencoder xvid. Mencoder xvid never fitted the size for me, but with xvid_encraw it works. Thanks to all

[woah!]

i have a weird problem

my encodes come out at 29.000 frames instead of 29.970 ?

same avs encded with mencoder gives the correct 29.970fps so i dont think its a script error

crop(8,8,-8,-8)
LeakKernelDeint(order=1, sharp=true)
ColorMatrix("Rec.709->Rec.601",mmx=true,hints=false)
LanczosResize(704,400)
trim(20000, 20900)

heres the xvid info:

-type 2 -cq 3 -avi

http://images.dr3vil.com/files/default/xvid_encraw.jpg

heres the mencoder info:

-ovc xvid -xvidencopts fixed_quant=3:max_key_interval=300:packed:vhq=1:qpel:chroma_me:quant_type=mpeg:trellis:lumi_mask:bvhq=1

http://images.dr3vil.com/files/default/mencoder.jpg

also heres the info from MPC:

Video: XVID 704x400 29.00fps 968Kbps [Video 0]


cant seem to get away from 29.000fps even.

[squid_80]

Yeah, I realized today that I hadn't done any tests with anything other than 25fps material so I apologize to all the NTSC people out there. On the upside it should be easy enough to change the framerate if you mux audio in later.

[woah!]

true but i thought i should at least let you know there is an issue :)

otherwise it works great :)

[squid_80]

Well that's what testing is for...

MKV output is very close. It's working when I run it from inside the debugger, but crashes when I try it normally. :mad:
(bond: you'll be happy to hear it's native V_MPEG4/ISO/ASP in mkv.)

[bond]

MKV output is very close. It's working when I run it from inside the debugger, but crashes when I try it normally. :mad:
(bond: you'll be happy to hear it's native V_MPEG4/ISO/ASP in mkv.)great stuff!!!
edit: how are you going to handle packed bitstream with mkv? simply disable it?

tough when will we see real native mpeg-4 (meaning in .mp4 ;) )?

[squid_80]

I could borrow Mosu's bitstream parser from mkvmerge to split the packed frames. Or I could just disable simultaneous .avi and .mkv output, which is probably more sensible.

[bond]

how are you going to remove all the other avi specific fud when outputting native mkv: like placing the vol on every keyframe?

[bond]

heres the xvid info:

-type 2 -cq 3 -avi

http://images.dr3vil.com/files/default/xvid_encraw.jpgjust realised this: where does the "coremp4" come from?

[squid_80]

Whatever codec is grabbing the FourCC code from the avi?

[bond]

sure, but i am wondering cause i dont find this "coremp4" decoder anywhere?

[bond]

squid_80, one error: packed bitstream is enabled by default. this leads to the situation that if someone doesnt disable pb and outputs raw .m4v he will get an incorrect stream full of the dummy placeholder n-vops

a possible solution would be to allow pb only with avi output (and not with raw, mkv and a hopefully to come mp4 output), as after all pb is only a hack for avi, and/or disable pb by default (which imho would be a good thing)

[dimzon]

Well that's what testing is for...

MKV output is very close. It's working when I run it from inside the debugger, but crashes when I try it normally. :mad:
(bond: you'll be happy to hear it's native V_MPEG4/ISO/ASP in mkv.)
Seems like you have invalid field align for structures. Just disable this option in optimizer or use pragma pack directive...

[squid_80]

Actually it seems I was forgetting to set the global timecode for the cues :o Works properly now, just fine tuning.

[squid_80]

how are you going to remove all the other avi specific fud when outputting native mkv: like placing the vol on every keyframe?
squid_80, one error: packed bitstream is enabled by default. this leads to the situation that if someone doesnt disable pb and outputs raw .m4v he will get an incorrect stream full of the dummy placeholder n-vops

a possible solution would be to allow pb only with avi output (and not with raw, mkv and a hopefully to come mp4 output), as after all pb is only a hack for avi, and/or disable pb by default (which imho would be a good thing)
OK, before I finalize my solution I'm going to ask for advice because I'm not an expert.
I've made a quick and dirty function which searches the buffer returned by the encoder for the sequence 00 00 01 b6 (vop start code).
If the frame is the first keyframe of the sequence, store everything before this location (the vol headers) in the codec private element of the mkv and store everything after as a key frame. If it's not the first keyframe just throw the headers away and store the frame.
If it's not a keyframe check for 2 vop start codes to indicate a packed frame. If so write the first vop as a p frame and the second as a b frame.
If the total length of a vop is less than 10 it's probably a n-vop. Check if the size of the buffer returned by the encoder matches the length of the encoded frame and if not throw it away. Otherwise write it as a frame with a reference to the previous one.

I'll try and make it a bit clearer:xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
0: key=2, time= 16, len= 33779 | type=I, quant= 4, len= 33779
1: key=0, time= 0, len= 0
2: key=0, time= 79, len= 15268 | type=B, quant= 7, len= 4985
3: key=0, time= 0, len= 6 | type=P, quant= 4, len= 10289
4: key=0, time= 62, len= 15242 | type=P, quant= 4, len= 15242
5: key=2, time= 16, len= 44086 | type=I, quant= 4, len= 44086
6: key=0, time= 62, len= 15406 | type=P, quant= 4, len= 15406
7: key=2, time= 15, len= 39235 | type=I, quant= 4, len= 39235
8: key=0, time= 63, len= 11424 | type=P, quant= 4, len= 11424
9: key=0, time= 62, len= 13839 | type=P, quant= 4, len= 13839
-1: key=0, time= 63, len= 15438 | type=P, quant= 4, len= 15438
-1: key=0, time= 0, len= -5
Tot: enctime(ms) = 438.00, length(bytes) = 203723
Avg: enctime(ms) = 39.82, fps = 25.11, length(bytes) = 18520
Frame 0 has the headers before the vop start stripped off and they are stored in the codec private element. The vop is stored as a frame with no references.
Frame 1 doesn't return anything from the encoder.
Frame 2 is scanned for vop start codes and 2 are found. The first vop is stored as a frame with a reference to the last i frame, the second vop is stored as a frame with references to the last i frame and p frame.
Frame 3 has a buffer with a length smaller than 10 and different size to the corresponding encoded frame ( 6 != 10289). It's a fake n-vop so throw it away.
Frame 4 has only one start code and is a p frame. Store it with a reference to the previous I frame.
Frame 5 is an I frame. Find the vop start, throw away everything before it and store the frame with no references.

You get the idea (I hope). If anyone can spot any flaws please speak up now before I waste too much time implementing/testing.

[squid_80]

So either I've utterly confused everyone, or I'm gonna go with this :)

[dimzon]

@squid_80
please, take look @ this:
http://forum.doom9.org/showthread.php?p=774869#post774869

[Doom9]

if your goal is to just avoid packed bitstream except for AVI output, why not override whatever the user set? It's the solution I should've adopted in MeGUI long ago (add that to the long list of "should haves").

[squid_80]

The headers still need to be stripped from every I frame (there's global flags to turn this off but they're not implemented in xvidcore).

[squid_80]

@squid_80
please, take look @ this:
http://forum.doom9.org/showthread.php?p=774869#post774869
really, it encoder reques avs with yv12 support it means encoder are working with avs via avisynth.dll (there are no other way to get yv12 from it, AviFile32 API performs RGB24 conversion).This isn't right at all. If it were true how do x264 and xvid_encraw currently get yv12 frames using avifile? Besides, xvid supports lots of different input colorspaces but support for others just hasn't been implemented in encraw yet. It's yet another thing to be done.

Edit: No-one took a scrap of notice when I said I'd enhanced x264.exe to print the error message if opening an .avs script fails (which is pretty useful, imho).

[bond]

simply drop avi output and with it all the avi-centric crap ;)

[dimzon]

This isn't right at all. If it were true how do x264 and xvid_encraw currently get yv12 frames using avifile?
can you post code (i want take look @ it)

[Doom9]

simply drop avi output and with it all the avi-centric crapNot gonna happen any time soon with a millions of XviD capable standalones out there. I'm afraid XviD in AVI still makes a lot of sense.

[squid_80]

can you post code (i want take look @ it)
For the avisynth error handling? Well this is how I changed x264.c:

extern "C" const GUID IID_IAvisynthClipInfo // {E6D6B708-124D-11D4-86F3-DB80AFD98778}
= {0xe6d6b708, 0x124d, 0x11d4, {0x86, 0xf3, 0xdb, 0x80, 0xaf, 0xd9, 0x87, 0x78}};


struct IAvisynthClipInfo : IUnknown {
virtual int __stdcall GetError(const char** ppszMessage) = 0;
virtual bool __stdcall GetParity(int n) = 0;
virtual bool __stdcall IsFieldBased() = 0;
};

static int open_file_avis( char *psz_filename, hnd_t *p_handle, x264_param_t *p_param )
{
AVISTREAMINFO info;
PAVISTREAM p_avi = NULL;
PAVIFILE m_AVIFile;
int i;
IAvisynthClipInfo *pAvisynthClipInfo;

*p_handle = NULL;

AVIFileInit();
if( AVIFileOpen(&m_AVIFile, psz_filename, OF_READ, NULL))
{
AVIFileExit();
return -1;
}

// Check if we're using avisynth and display any script errors (taken from virtualdub)
if (FAILED(m_AVIFile->QueryInterface(IID_IAvisynthClipInfo, (void **)&pAvisynthClipInfo)))
pAvisynthClipInfo = NULL;
else {
const char *s;

if (pAvisynthClipInfo->GetError(&s)) {
printf("Avisynth open failure:\n%s\n", s);
pAvisynthClipInfo->Release();
m_AVIFile->Release();
AVIFileExit();
return -1;
}
}

if (pAvisynthClipInfo!=NULL)
pAvisynthClipInfo->Release();

if( AVIFileGetStream(m_AVIFile, &p_avi, streamtypeVIDEO, 0) )
{
AVIFileRelease(m_AVIFile);
AVIFileExit();
return -1;
}
// Close m_AVIFile now that we have the stream
AVIFileRelease(m_AVIFile);

if( AVIStreamInfo(p_avi, &info, sizeof(AVISTREAMINFO)) )
......