xvid_encraw - Patched with AviSynth input support

[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