QuEnc 0.51 (AVS->M2V/M1V Encoder)

[LigH]

Very interesting: Tried to encode a small clip to a PAL DVD video; it was probably quite soft and unsharp, but has also lots of motion and fades - I don't know if it is hard or easy to encode, usually I thought it is hard. So I gave it a bitrate of 6000 kbps - but it did not even need much more than 4000 kbps. And I'm not sure if it really has maximum quality. I somehow doubt that the bitrate control in general works well in ffmpeg, and so also in QuEnc.

Or on the other hand, the encoder may be so much better than CCE...

[DDogg]

the encoder may be so much better than CCE I don't know about that yet, but the fact that we are seeing a non-proprietary encoding solution is the exciting part for me. Like Nic suggested in some thread, you sure can't beat the price.

Maybe later we can do some accurate, and non subjective tests on quality. I think that is still down the road after more work on the innards of this encoder are done as there is still quite a way to go. Still, the progress and quality are amazing and the prospect of having a non-proprietary MPEG solution for our community is a great thing to look forward to.

[lithoc]

there're a lot of parameters in ffmpeg which Quenc doesn't have. For example sameq, qcomp, qscale, qmax and qmin & maxrate.
I'm not too sure which one is useful but it can be useful to create quality mpeg.

[DDogg]

Nic, I've been puzzled by the bitrate control of MPEG2 VBR HQ 1-pass [and 2-pass] so I did some 1-pass VBR HQ TQ tests with a 1% sample of a 2:18:37 hour d2v source. I do not understand exactly what the data means except there seems to be an artificial bitrate cap - so I thought I would share it with you :)


Bitrate Filesize (bytes)| For reference I put a few CBR sizes
0500.m2v 5,264,042
1000.m2v 10,364,516 (CBR pass - 10,388,076 bytes)
2000.m2v 20,175,489 linear

2500.m2v 21,595,425 (CBR pass - 26,026,262 bytes)
2600.m2v 21,670,441
2700.m2v 21,723,518
2800.m2v 21,764,422
2900.m2v 21,812,769
3000.m2v 21,843,315
3200.m2v 21,899,363
3500.m2v 21,946,655 (CBR pass - 36,394,427 bytes)
3750.m2v 21,978,178

4000.m2v 21,984,102 Same (CBR pass - 41,590,740 bytes)
4500.m2v 21,984,102
5000.m2v 21,984,102 (CBR pass - 52,028,216 bytes)
6000.m2v 21,984,102 (CBR pass - 62,465,632 bytes)
8000.m2v 21,984,102 (CBR pass - 83,359,258 bytes)

[Stef]

Using 0.45 on a Windows 98SE system with avisynth 2.52. QuEnc is really a nice tool!

But i get a program error with crash in Kernel32.dll when QuEnc exits. The error is very nasty and later started programs exit with the same error...

Maybe a system resource is given free twice or in the wrong order?

Bye
Stefan

[Amenophis]

Originally posted by Nic
No I can't add min and max bitrates because they don't work the same way as something like CCE and you'll end up with severely undersized files again.

Mencoder uses the same libav codec and there the files have the right size (tested with avg bitrates between 1000 and 6000 kbit/s.) when using a maxbitrate, so there must a way to set the max. bitrate. When have you tested 'rc_max_rate'? If it was before you added the parameters i suggested some days ago, then this could be the reason for the nevertheless undersized files.

[Nic]

Could you post the parameters you used with mencoder and also the reason? With your last post, some of the options didn't seem to make sense as to why you'd pick them ?
i.e.
mbd:0 // is the lowest quality motion option ??
vrc_override=110200,115248,1000 // means your overriding frames 110200-115248 with a qscale of 1000 ?? Why only frames 110200-115248 ?? why 1000 ??

etc

-Nic

[Jellygoose]

Hi Nic!

Alright. Testet QuEnc .45 today, and here's my result:

High Quality checked, 2-Passes checked, Trellis checked, closed GOP, Bitrate 2350kb/sec. 704x576 resolution 25fps...
Output: MPEG-2 w/ KVCD-Notch Matrix

Results look rather bad, I can clearly see big DCT blocks in low detail areas. This actually might be due to the fact that the encoded file is way undersized. According to VDub, it has 1701kb/sec, where should be 2350kb/sec...
Note: This is with 2-pass used
Could it be due to the number of B-Frames I used (standard 2)?

Anyway, the app looks very promising Nic, and I'm just trying to give you some results for you to kill bugs, as they are present.
:D

BtW: If you want to see more talk about your app, including visual tests go here: http://kvcd.net/forum/viewtopic.php?t=9683&postdays=0&postorder=asc&start=0

[insertdisk]

Is there a setting somewhere to enable interlaced output? I am doing some testing on DV footage and it looks pretty nice but it is putting out progressive frames.

[Nic]

@Jellygoose: Because of the problems with the ratecontrol, the quality does vary, when the rate control works out, the files do look really good.

Im compiling Mencoder now to see if the same effects happen. From the parameters ive seen posted using Mencoder at kvcd, people really don't understand the parameters, nevermind those that are used in QuEnc...so it's all a bit confusing at present. It'll get better...early days.

-Nic

[Amenophis]

@Nic:

mbd:0 // i've choosen this one because of the speed. the quality difference between mdb=0 und mbd=2 is hardly noticeable, and (at least for dvd-bitrates) not worth loosing 30-40% of the framerate. mbd=1 wouldn't i suggest at all, same speed like =2, but not so good quality.

vrc_override=110200,115248,1000 // this was a pasted commandline from one of my encodes, there bitween frame 110200 and 115248 were used for the credits, which were compressed by 1000% (10 times stronger than calculated by the ratecontrol). i don't know if it works in libav the same way, because there you can pass 2 values in the corresponding struct. Leaving this away shouldn't affect the filesize-problem.

vqmin=1:mbqmin=1:lmin=1: // these values are needed if you want to use a minimum quantizer =1. without you won't be able to reach avg. bitrates above 3000-4000 kbit/s. all of these values are needed for that, because you can't encode a whole frame with avg. quant 1, if you force the encoder to encode each macroblock with at least quant 2 (default)

:vb_qfactor=1.25:vi_qfactor=0.833333: // b-frames get more compressed (p-frames * 1.25) while i-frames will get better quality (lower compression: p-frames * 0.83)

:vratetol=1835: the tolerance of the rate control algorithm. a low value will 'smooth' the bitrate-curve, while a high value will lead to a lot of ups and downs. this value seems to be ok

:cbp: coded block pattern: seems to improve quality, only useful when using trellis encoding.

:vlelim=-4:vcelim=-7: standard values of mencoder

:vrc_buf_size=1835: buffer size for dvd (=224*8*1.024) for svcd it should be 917.

[Matthaeus]

@Nic & Amenophis:

The option "vrc_override=110200,115248,1000" compresses frames 110200 to 115248 with qscale=10. The documentation of mencoder is incorrect; you must pass quant*100 as the 3rd argument instead of quant! But I've checked ffmpeg, too, and passing the quantizer (not quantizer*100!) as 3rd argument seems to be working correctly.

[Nic]

@Amenophis: Thanks alot...strange you can't see quality differences between the simple ME and rate distortion decision...there should be.
EDIT: Just tried out your settings :) They worked great, I think they limit the encoder a bit, but they keep the size accurate. Just encoded a 78sec file at 5MBit size should be: 48750000
MPEG-1 (VBR): 49,284,319
MPEG-2 (VBR): 49,279,299
(So not too bad at all, but it is pretty much a CBR file because of the low rate tolerance :( )

libavcodec is having it's ratecontrol re-written and the mpeg code has just been patched to be better for CBR. So that's a step in the right direction...

-Nic

[bilu]

Originally posted by Nic
libavcodec is having it's ratecontrol re-written and the mpeg code has just been patched to be better for CBR. So that's a step in the right direction...
Indeed :)

A lot of encoders will get improved when Michael Niedermayer finishes the ratecontrol code.

Then we can start focusing on quality parameters again, so far everybody has been focused on the ratecontrol behaviour on every libavcodec-based encoder: FFVFW, Mencoder, FFMPEG...

@Nic,
How are you feeding AVS to FFMpeg? A modified FFVFW MakeAVIS ?
It would be neat if Sh0dan or anyone else provided a command-line version of this so we could use it with Mencoder too ;)


Bilu

[insertdisk]

Please add support for `-interlace' in commandline format for the output stream if possible. I think this is gonna do a fine job on DV footage.

[Nic]

@bilu:
"How are you feeding AVS to FFMpeg?"
Through the medium of dance... ;)

Seriously though, I just use the AVI API to get the raw frame then feed it into libavcodec. I could modify mencoder to load AVS files, but it would be tedious and I wouldn't learn anything. I only do that kind of coding when im getting paid to do it. ;)

@insertdisk: Will do.

[bilu]

Originally posted by Nic
I only do that kind of coding when im getting paid to do it. ;)

Let's enjoy your last free QuEnc versions then. :D

Bilu

[Mozart]

Hi Nic and Ddogg,

"Somebach" told me there were an interesting thread here... He was right as usual.
Nic, your GUI version of ffmpeg have a high potential. It is just missing those other settings of original ffmpeg. What about an "advanced" GUI with all settings enabled (at least the mpeg specific settings)?

Originally posted by DDogg
Nic, I see you are still a glutton for punishment :)

(...) Also, just being curious (you got enough pressure), does the base of this encoder you are using have a quant based technique? I'm more interested in constant quality (to use that term very loosely) than bitrate/size.

Hope you are doing well, and that the ends of those fingernails can still be seen.

This is possible to be done using ffmpeg commandline. Edit the following code and save as a .bat file and you will have a quantizer based encode "a la" CCE 1passVBR.

PATH:\bbdmux.exe PATH:\SOURCE.vob 0xe0 PATH:\temp_vts.m2v
PATH:\pulldown.exe PATH:\temp_vts.m2v PATH:\temp_vts1_nopull.m2v -nopulldown -norff -prog_seq p -prog_frames p -framerate 23.976
PATH:\ffmpeg.exe -i PATH:\temp_vts1_nopull.m2v -target dvd -r 24000/1001 -bt 2000 -s 720x480 -aspect 16:9 -maxrate 8000 -qmin 4 -vcodec mpeg2video -g 15 -b_qfactor 1.2 -i_qfactor 1 -bf 2 -sc_threshold 400 -an PATH:\temp_ffmpeg.vob
PATH:\bbdmux.exe PATH:\temp_ffmpeg.vob 0xe0 PATH:\TARGET.m2v

[onesoul]

Hi Mozart, you refer somebach, aren't you Bach? Never understood the deleting of all posts!

[jorel]

Originally posted by onesoul
Hi Mozart, you refer somebach, aren't you Bach? Never understood the deleting of all posts!

no ,he isn't Bach !
not kiddin....
they are differents musicians!

Mozart is another cool person and music maker too!
"listen" his posts!

:)

[DDogg]

Mozart, good to see your post. I certainly hope you made it through your PhD dissertation (if I remember correctly)unscathed.

Wow, those 4 lines above certainly contain a lot of information, however, it is important we keep this thread on topic to nic's work so I will PM you about that soon. Maybe we can start another thread. I have a ton of questions :)

Getting back on topic (sorta), the reason I asked nic to consider adding quant based encoding if ffmpeg allowed it was because of the clean way he opens an AVS script. I thought this would make it very familiar and comfortable for us to do the file size prediction sampling in the common way we do for CCE OPV.

However, after playing around with your suggested lines above, I can see that the the difference in file size between quant 4 and quant 2 is a *full doubling* of file size (assuming I did the test right). That makes predicting file size via sampling impossible unless the ffmpeg group were willing to make it a much finer range. That may not even be feasible as I don't know the slightest thing about the way the underlaying encoder functions. If I am mistaken, please PM me directly.

Again, good to hear from you and I hope you are no longer a stranger to our forums. oh, please do be very careful about your associations with those rascal somebachs - hanging around with them could make you completely unstable, bald, and socially unacceptable :cool:

Best, DD

[yaz]

@all
i agree with ddogg. pls, keep this thread as 'clean' as possible. i mean, let's keep it for nic & his cute little tool. it's very promising, imo.
on the other hand, i'd be glad if some other threads'd be opened for the different encoders. i've been playing a lot with mencoder, ffmpeg, ffvfw, ... & i have (many) more quests than answers. but at the moment, i don't know where to address them.
thx
y

[laura_glow]

Hi!

Im trying to convert from MJPEG avi to MPEG2.
for this, im doing the following:

i convert the avi to mpg with ffmpeg like this:

ffmpeg -i REF3048.avi -y -f mpeg -vcodec mpeg2video -ac 2 -b 7963 -aspect 4:3 -croptop 2 -cropbottom 4 -ildct out\TRA3106.mpg

I have the sound in two separate files (wav)
so my avisinth .avs file looks like this:

video = DirectShowSource("c:\program files\ffmpeg\out\TRA3106.mpg")
left_channel = wavSource("c:\program files\ffmpeg\TRA3106.A1.wav")
right_channel = wavSource("c:\program files\ffmpeg\TRA3106.A2.wav")

audio = MixAudio(left_channel, right_channel, 0.5, 0.5)
vid = AudioDub(video, audio)
ComplementParity (vid)
ConvertToYV12(vid)

i open it with QuEnc and the resulting file doesent have any sound... any ideas?

I tried MonoToStereo but one of the wav files doesent have any sound..
When i open the .avs in virtualdubmod i can hear the sound

[LigH]

As far as I know, QuEnc is a video-only encoder.

You may use the AviSynth skript in another MPEG encoder (like TMPGEnc) to encode mp2 audio from your script.

[laura_glow]

I need to do a batch job with a lot of videos to convert in the mentioned format (one post up) any suggestion? :(

[LigH]

Write a batch file (may call it "que.bat") with a content like that:
C:\Program Files\QuEnc\QuEnc -i %1 -(options...) -o %2
This calls the encoder with two parameters: The first one is the name of the source script, the second is the name of the target movie. All scripts must already be prepared and must reside in the same directory. Then call the encoding in a loop from the command line of CMD.EXE:
FOR /F %I IN (*.avs) DO CALL que.bat %I ?:\output-dir\%~nI.m2v

[katjarella]

FOR /F is NOT WORKING !!!!

FOR /R [[drive:]path] %variable IN (set) DO command [command-parameters]

Walks the directory tree rooted at [drive:]path, executing the FOR
statement in each directory of the tree. If no directory
specification is specified after /R then the current directory is
assumed. If set is just a single period (.) character then it
will just enumerate the directory tree.

FOR /R is better :)

[unplugged]

If we want a CCE substitute we should consider the quality part as high priority, but looking into forum it seems there isn't much interest about (why??), at least for libavcodec/mencoder, apart trying 10571289 milions of custom made matrixes :D.
It's not clear which switches are *better* with libavcodec encoding but despite this looking around the web I have found and collected these as quite trusted:

mbd=2:mv0:trell:cbp:subcmp=2:cmp=2:Precmp=2:Predia=2:dia=2
means high quality encoding + ??? + trellis quant + rate distorted optimal coded block pattern + SATD comparison function + diamond size 2
One other important point is that B-frame quality with libavcodec is too skippy relatively to P-frame, don't know if it inflates much bitrate but I use vb_qfactor=1.25 and vb_qoffset=1.0 (default 1.25 too) and the result is acceptable now.

Nic, I hope you will implement some of this (and other) key switches that influence output quality, QuEnc is an useful program but at same time why don't take the best out of libavcodec.
I have made some short clip comparison with CCE, actually QuEnc quality isn't comparable... neither against mencoder (when well set), too blurry (3000kbps tests), especially B-frames has no detail everywhere. :(

P.S.: my current mencoder cmdline:C:\App\Media\Mencoder\mencoder.exe -forceidx -of mpeg -ovc lavc -nosound -lavcopts vcodec=mpeg2video:
mbd=2:mv0:trell:cbp:subcmp=2:cmp=2:Precmp=2:Predia=2:dia=2:vmax_b_frames=2:vb_qfactor=1.25:vb_qoffset=1.0:keyint=15:aspect=16/9:vrc_buf_size=1835:
intra_matrix=8,16,19,22,26,27,29,34,16,16,22,24,27,29,34,37,19,22,26,27,29,34,34,38,22,22,26,27,29,34,37,40,22,26,27,29,32,35,40,48,26,27,29,32,35,40,48,58,26,27,29,34,38,46,56,69,27,29,35,38,46,56,69,83:inter_matrix=16,17,18,19,20,21,22,23,17,18,19,20,21,22,23,24,18,19,20,21,22,23,24,25,19,20,21,22,23,24,26,27,20,21,22,23,25,26,27,28,21,22,23,24,26,27,28,30,22,23,24,26,27,28,30,31,23,24,25,27,28,30,31,33:vratetol=1835:vqcomp=0.5:vpass=%5:vbitrate=%3:vrc_maxrate=%4 %1 -o %2
matrix is CCE "standard MPEG" that is 99.99% identical to XviD MPEG matrix.

[laura_glow]

yes, the batch functionalty of QuEnc is great! but im not getting any sound in the resulting files :(

[LigH]

@ katjarella & others:

Sorry about that misinformation - I didn't try what I wrote, shame on me. From the help text of the "FOR" command, I thought that "/F" is necessary for those "%~" extended variables to work.

On the other side, I did not expect "/R" to be used because I don't expect recursively walking through the directory branch.
__

@ laura_glow:

Good morning: QuEnc seems to be a "video-only" encoder, as I already wrote a few answers above ^.

[tickey]

Originally posted by Mozart
This is possible to be done using ffmpeg commandline. Edit the following code and save as a .bat file and you will have a quantizer based encode "a la" CCE 1passVBR.

PATH:\bbdmux.exe

<snip>

PATH:\TARGET.m2v
Hey thanks 4 posting that, hanving fun testing ffmpeg, now :D
I already had the tool from here
http://www.dvdrhelp.com/tools?toolsearch=ffmpeggui&section=&orderby=Name&convert=&dvdauthorfeatures=
but only transcoding audio.

With your batch file, I jumped right in :cool:

[rayvt]

DDVRebuilder conversion time comparisons.
Italian Job WS 159007 frames, 1:50:24, 6624 seconds
Reduction=81.8
Main movie only, ripped with smartripper, converted to DVD with
IFOEdit.
Rebuilt with DVDRebuilder v0.23 on AMD2400+, 1024MB ram

Times in seconds
CCE2.66.01.07
Prep....157
Encod...6389
Rebld...1218
Total...7764


Rejig 0.5e
Prep....797
Encod...892
Rebld...1191
Total...2880


QuEnc 0.45
Prep....156
Encod...8231
Rebld...905
Total...9292

DVDShrink 3.1.7.6
Total...3420

Comments: After a brief look at the converted movies I didn't see any
noticable difference in the video quality between any of the encoders.

[djan]

Originally posted by rayvt

Comments: After a brief look at the converted movies I didn't see any
noticable difference in the video quality between any of the encoders. With Reduction=81.8, it's something normal. Try a movie of 50%-70% reduction and you'll see the difference.

[Nic]

@unplugged: Nothing is ever simple. People keep suggesting switches and great features of libavcodec, for me to look thru the code (or do a PSNR test and look with my own eyes) and realise that they really don't know what they're talking about. But your settings are good. I've tried them myself before (and they do all make sense ;) which is rare with these suggestions). Ill add them in soon (they do slow down the encoding a great deal (cdp,mv0 and trellis do help psnr lots). However, QuEnc will never have that many options, because I hate the confusion that people have with all ffmepg/mencoder options. Been real busy. Spent Sunday aggravating Fred Durst to the point where he tried to spit on me and my friend. Still, we got our point across ;)

@rayvt: Glad it all worked out well.

@laura_glow: Yup, no sound, sorry. I could add it in if people wanted it. It's not hard to do. Be aware that the MPEG-2 Audio Encoding of libavcodec is very simple. Love your deviantart. ;)

Back to work....

-Nic

[Wimpy]

Hi,

I have been testing QuEnc 0.45 in conjunction with DVD-RB 0.26. What a great combo :-) I am seeing the undersized video output that has been discussed previously, so I won't bore you with the details but wait to test the next QuEnc version.

Here is the little bug. If I use the QuEnc GUI to encode a .AVS to MPEG-1 and then use DVD-RB (using QuEnc) to do a DVD Encode/Rebuild, QuEnc still has the MPEG-1 option checked in the GUI. Therefore my .M2V created by DVD-RB is actually an MPEG-1 stream.

Maybe you can enhance the '-mpeg1' command line usage, so that if it is not defined MPEG-2 output is assumed?

Thanks for a great tool, I look forward to its contnued development :-)

[djan]

Originally posted by Wimpy
Here is the little bug. If I use the QuEnc GUI to encode a .AVS to MPEG-1 and then use DVD-RB (using QuEnc) to do a DVD Encode/Rebuild, QuEnc still has the MPEG-1 option checked in the GUI. Therefore my .M2V created by DVD-RB is actually an MPEG-1 stream.

Maybe you can enhance the '-mpeg1' command line usage, so that if it is not defined MPEG-2 output is assumed? It's maybe to jdobbs to define it when it calls QuEnc ? Anyway, are you sure your output files are MPEG1 ? Maybe it is checked MPEG1 but DVDRB calls it using MPEG2 at the vbr it setted ? Take a look.

[Wimpy]

Hi,

Yes, it is definately an MPEG-1 stream. The only command line option to define what stream type to output from QuEnc is '-mpeg1'. Therefore DVD-RB can't be altered to force MPEG-2 stream creation from the command line unless a '-mpeg2' does exist and is not advertised?

[ffroms]

I have some other question. What program to use to change TFF and Frame type since QuEnc makes m2v with TFF no and Frame Type Progressive and I need TFF-yes and F. Type - Interlaced? Maybe in some future release of QuEnc it would be possible to set that?

FFS

[Nic]

@wimpy: I will add a -mpeg2 flag and recommend to jdobbs to add it in.

@ffroms: Ill try and deal with that best I can. :)

[ffroms]

Thanks for quick replay Nic. That problem is really bothering me 'couse I use PAL DVD and interlace is usual. Hope to see new version soon :))))

FFS

[LigH]

katjarella found the following two bugs:

1) When you once used the GUI (by calling QuEnc without command line parameters) and set up VBR encoding, then the usage of VBR encoding gets written into the registry. From then, she complains that always VBR encoding is used. But I'm not yet sure what she really means - if there is no command line parameter to enforce CBR encoding, or if there is one (although not documented), but not working. I'll ask back about that...

2) Using an AVS Script with VBR audio stream and EnsureVBRMP3Sync(), the error message with ConvertToYV12() always occurs, although the video output is YV12.

[Wimpy]

Thanks Nic :-)

[onesoul]

Nic, what were you doing to Fred Durst? (being curious) :)

[Nic]

LigH:
1) there is no commandline to enforce cbr, that's probably the problem.
2) Got no idea why that would be...hmmm.

onesoul: getting him to play 3dollarbill

[tickey]

Originally posted by djan
It's maybe to jdobbs to define it when it calls QuEnc ? Anyway, are you sure your output files are MPEG1 ? Maybe it is checked MPEG1 but DVDRB calls it using MPEG2 at the vbr it setted ? Take a look.
Tell me how DVDRB can force QuEnc? It asks for mpeg1 or mpeg2.
It called for mpeg2 in the commandline and got mpeg1.
Your response makes no sense.

[Mozart]

Originally posted by yaz
@all
i agree with ddogg. pls, keep this thread as 'clean' as possible. i mean, let's keep it for nic & his cute little tool. it's very promising, imo.
on the other hand, i'd be glad if some other threads'd be opened for the different encoders. i've been playing a lot with mencoder, ffmpeg, ffvfw, ... & i have (many) more quests than answers. but at the moment, i don't know where to address them.
thx
y

??? As far as I can understand, QuEnc is another cover for the same engine used by ffmpeg, mencoder and ffvfw. So, the knowledge about the usage of those other encoders is usefull in QuEnc's development. The higgest advantage of QuEnc over the others is the usage of avs files as source. So, if QuEnc had the other ffmpeg settings enabled, you could use a single command line with just QuEnc instead of that .bat file.

[Mozart]

Originally posted by DDogg
Wow, those 4 lines above certainly contain a lot of information(...). After playing around with your suggested lines above, I can see that the the difference in file size between quant 4 and quant 2 is a *full doubling* of file size (assuming I did the test right). That makes predicting file size via sampling impossible unless the ffmpeg group were willing to make it a much finer range. That may not even be feasible as I don't know the slightest thing about the way the underlaying encoder functions.


I have used bbdmux and pulldown as a workaround for an anoying ffmpeg bug in its internal vob decoder. It should be possible to do vob->mpv conversion on the fly, using ffmpeg. So, the only important line of that .bat file is the ffmpeg comandline.
Have you seen how flat is the quantization? The only problem is that the qmin setting uses integer values only. If it was possible to use decimal values, such as 2.5, 3.3 or whatever, the file size prediction game would be much more interesting...

[djan]

Originally posted by tickey
Tell me how DVDRB can force QuEnc? It asks for mpeg1 or mpeg2.
It called for mpeg2 in the commandline and got mpeg1.
Your response makes no sense. I'm sorry but my English is not so good. I mean, it's possible that QuEnc process MPEG2 even when it is showed MPEG1 on the GUI. Don't forget DVDRB makes the call with a command line. So then, it is possible that the GUI means nothing. I can even change the state of the GUI from MPEG2 to MPEG1 while it is encoding. Anyway, it's possible that all I'm telling is wrong. :)

PS : His problem here is that DVDRB can't force an MPEG2 encoding as there is only the -mpeg1 command line option. And if QuEnc was set to MPEG1 before to close, then it'll encode in MPEG1. So, it needs the -mpeg2 command line option that Nic will add. :)

[DDogg]

Originally posted by Mozart
So, if QuEnc had the other ffmpeg settings enabled, you could use
a single command line with just QuEnc instead of that .bat file.Nic, let me throw out a few thoughts for discussion. First, I completely agree with you about keeping your GUI simple and clean. Trying to shoehorn in every option in a GUI targeted at "easy usage" is poor design, causes confusion, and ends up making nobody happy because it always ends up as a compromise. However, I am wondering if it might be possible to have a QuEnc command line trigger ... maybe something like -ES (extended syntax). QuEnc would then pass everything after that flag onto to ffmpeg in its standard syntax. I don't know if that is doable, but if so, it would keep the gui clean and yet still let more advanced users get the advantage of QuEnc's ability to easily use avs as input (and try any stupid thing they wanted :-)). Make any sense to you, or am I fuzzy thinking yet again? :-)

Also, could you just mention the point about the desire for decimal quants to the ffmpeg guy/s for consideration? I figure you must have a line into them. Of course, no problem if that is not feasible.

[onesoul]

Nic, you are just making me more curious :devil: :( :)