QuEnc 0.51 D2 test version

[dragongodz]

well i decided to start a new thread because of the lack of feedback from the last test version i posted in the QuEnc thread. hopefully i will get some more this time ???

first the disclaimer. :)

before downloading though understand these things.
1. this is my test build and not Nics so do NOT blame him for any problems with it.
2. this is a TEST version so may contain problems that Nics 0.51 didnt.
3. CBR is still no good and has already been said the rate control of libavcodec needs rerwriting to fix that.
4. i am releasing this so people can test out changes and report the good aswell as the bad. if nobody reports anything then why should i bother to release a test ?

change for D1 version include -
.different settings for varied frame size/bitrate.
.change to rate control settings to try and reduce bitrate spikes.
.new custom quant(still called notch for compatability and testing) which should work with trellis. meaning no more of those artifacts.

changes for D2 version include -
.fix for aspect ratio(4:3 and 16:9 should work properly now)
.more work on reducing bitrate spikes.

you can download it from here
http://pcpages.com/dragongodz2/

[Paced]

Hey, thanks for the new version. I gave it a test run overnight, and as far as I can tell, there doesn't seem to be anything broken. In addition, just for fun, I used Nic's last version of .51 on the same video (with the same settings), and when I compared the two (using VirtualDub) side by side, your version was actually a bit better in some spots (less blocks, etc.). Don't ask me why though :) Because as far as I can tell, you didn't change anything too significant (from what you posted) in your test versions; but, I'm happy with it nonetheless.

Here's something I noticed though:

- the maximum bitrate still wasn't 'respected' - I set a vaue of 2450, but BitrateView reported the max. bitrate to be ~3060. But this is nothing new, and I doubt QuEnc itself is the reason for it.

[dragongodz]

Paced - thanks for replying. when i looked at how many have read this i was starting to wonder if any would. :)

part of what i did is to tell avcodec what is a more sensible way for mpeg1/2 and not its defaults. thus bitrate should be distributed better with a possible quality increase in some areas and possible loss in others(reducing the bitrate spikes means less bitrate for those frames so of course may look slightly worse).

no QuEnc itself is not responsible for the bitrate spikes, thats avcodecs rate control. the ffmpeg guys have mentioned doing per MB rate control so if/when thats done that should hopefully be fixed. i will continue to try and fine tune what QuEnc tells it though to give a better output using the current system.

it would be interesting to know what Nics QuEnc 0.51 spiked to for the same footage. also how many times max bitrate wasnt respected would be interesting but that would be a long slow task i know.

[nwg]

I would like to test it out. Unfortunately, I cannot connect to the site.

[dragongodz]

i just checked the page and it came up fine. maybe it was down for a while.

try again and if still no luck then let me know. maybe someone else may even mirror it. :D

[Amenophis]

- the maximum bitrate still wasn't 'respected' - I set a vaue of 2450, but BitrateView reported the max. bitrate to be ~3060. But this is nothing new, and I doubt QuEnc itself is the reason for it. [/B]

had you checked 'scene detection'?. in quenc, this feature is bundled with the dynamic gop pattern. althrough the dynamic gop pattern is a good idea in general, it is still a little bit buggy and does sometimes create a high motion gop where all frames are i-frames. with that i got these bitrate spikes too. so imho it would be worth a try to make the dynamic gop pattern optional, without loosing the 'normal' scene change detection.

btw, don't care about the values of bitrate viewer that much, these values aren't that representative as many people think. Unless two consecutive measure points or their average are above the bitrate limit, everything could be still fine.

@dragongodz: thanks for the new QuEnc build, except of the fact mentioned above everything seems to be ok.

[dragongodz]

Amenophis - i agree all I frames are no good. i will probably change that in the next version. though i will leave it as 1 option for now.

also about bitrate viewer. yes some times what it tells you need not be worried about but not always. it can be helpful aswell to see hoe the streams change.


hmmm over 1000 views of this thread now and so little feedback. :confused:

[dapipa]

hi!no testing yet - just a small mirror --> QuEnc051-D2.zip (http://www.fi.muni.cz/~xlukac/QuEnc051-D2.zip) <-- :) ...

[Sunesis]

I mainly use CBR, would you still be interested in my results?

[dragongodz]

dapipa - thanks for the mirror.

Sunesis - yes any and all feedback is welcome. the CBR with D2 should be better than Nics 0.51(less variation) but it still will not be true CBR. feedback about such things is needed though to know if people are seeing posative results though.

[Nic]

@dragongodz:
Still monumentally busy and will be for about a fortnight, but then should have some more time (I'm going to update my site then)

Feel free to release QuEnc as GPL now by the way :)
(Although be warned everyone, neither me or dgz can offer much help in compiling it, it's a real b*tch to compile, so good luck, but we can't help everyone who'll ask ;) )

-Nic

[dragongodz]

ok after talking with Nic its been decided that QuEnc 0.52 will be released under the GPL. this will happen in a weeks time or so, so dont ask for it before that.

please keep providing feedback though so that 0.52 has the appropriate changes etc.

[Sunesis]

I mainly use CBR because CBR streams better than VBR. :)

I used 8mbs CBR, and compared a frame from the Gladiator DVD with an encode from TMPGencoder. Using 0.51 If you compared the frame (a B frame) with the original, you couldnt tell the difference. Bringing the frame into Photoshop confirmed this. It was perfect. 0.52 D2 had the wrong colours (too much blue?), so i didnt do a detail comparision. TMPGencoded frame, when compared to the orignal and the Quenc, was not as clear.

The file sizes were the same, but i cant check the bitrate of the file, so its hard to tell if its CBR or VBR ( I did use CBR). Anyway, very impressed with it, considering it beats my other encoder I paid money for.

I will post some screenshots and encoding paramaters tomorrow when i get to work.

[JDay]

The main problem I'm having with the software is on ntsc film sources with DVD-RB. You get "jerkiness" after the pulldown of 23.976fps PROGRESSIVE sources. You would either need to set the prog_seq flag to interlaced or DVD-RB would need to correct this on rebuild. Either way, this makes QuEnc largely unusable with DVD-RB, for me. (I've mentioned this a few times here, and in the RB forum. Its not clear whose "responsibility" it is. If this is definitely something RB need to fix, I'll bring it up over there, again.)

[dragongodz]

I mainly use CBR because CBR streams better than VBR.
i wont touch that. :)

Using 0.51 If you compared the frame (a B frame) with the original, you couldnt tell the difference. Bringing the frame into Photoshop confirmed this.
single frame(especially B frames) comparison is unreliable. watch the videos in motion and compare them.

0.52 D2 had the wrong colours (too much blue?),
i had that once using directshowsource, but just the once. i havent seen any other complaints of this so maybe it was a 1 off ?

i cant check the bitrate of the file, so its hard to tell if its CBR or VBR ( I did use CBR)
download bitrateviewer (should find it easy enough if you search) and check in that. you will see if the stream is flat(meaning CBR) or up and down(VBR).

I've mentioned this a few times here, and in the RB forum. Its not clear whose "responsibility" it is. If this is definitely something RB need to fix, I'll bring it up over there, again.
JDay - yes and if you look at the last post in that thread
http://forum.doom9.org/showthread.php?threadid=75923&perpage=20&pagenumber=2
i ask people to try it with different authoring programs to see how they handle it. 0 responses
also you mention that pulldown.exe can fix it which suggests it can be fixed in authoring. that would be easier because otherwise we have to keep changing avcodec.dll source any time we use a different version.

[Sectie.B]

Am I the only one here getting an error when Quit'ing QuEnc?
It's something like (translation...):
quenc.exe Application Error
The instruction at "0x01a90b1c" referenced memory at "0x01a90b1c". The memory could not be "read".
Click on OK to terminate the program. The encode and result itself are OK.

If I just start QuEnc and quit without encoding something there's no problem; the same happens on 2 different machines (both running XP) and with different sources.
I saw someone mentioning something similar on the kvcd-forum (http://kvcd.net/forum/viewtopic.php?t=12163&postdays=0&postorder=asc&start=0).

Just tried Nic's 0.51 version: same happens.

If you need some specific info...

[dragongodz]

i used to get the crashing aswell if i stopped an encode before it finished and then quit.

it doesnt now and i have absolutly no idea why. i am guessing that a system file or such that was not 100% happy has been replaced.

[makoto916]

Originally posted by Sectie.B
If I just start QuEnc and quit without encoding something there's no problem; the same happens on 2 different machines (both running XP) and with different sources.
What is the codec used on those sources? The reason I ask is I had a similiar problem where QuEnc 0.51 would either crash, or sucessfully encode but the thread would hang in memory forever unless the task was killed. It turned out that using AVISource on a Matrox DV file was causing the problem. The second I switched to DirectShowSource it works perfectly. Perhaps other non-Microsoft DV codecs cause a similar problem. Not that this is the problem you are having, but try switching to DirectShowSource for any included AVI content. Also, try adding SetMemoryMax to half of your systems memory.

[Sectie.B]

makoto916

Thanks for the tip: just changing avisource to directshowsource in my avs-scripts seems to do the trick: no more error when exiting Quenc. :D
BTW, the avi-files I'm converting contain a variety of small clips created mainly with Xvid.

[TheMaskAgain]

What about the frame droppings. This was also mentioned in the QuEnc 5.1 thread. Is this already fixed?

The encoding works fine but when I am trying to mux the audio and video together with Mplex or IfoEdit it says that there are to many framedrops, and the muxing stops. If I use CCE there are no framedrops.

Has anyone else encountered the same?

[dragongodz]

when I am trying to mux the audio and video together with Mplex or IfoEdit it says that there are to many framedrops, and the muxing stops.
can you try it with Rejigs authoring and dvdauthorgui (found here http://users.adelphia.net/~liquid64/dvdauthorgui.html ) and let me know what happens ?

[Mug Funky]

just for fun i tried this out on a 2000 frame chunk of Akira (r4, pal).

compared to 0.51 it had a lower average and less visible problems.

one difference i noticed was it took longer to "calm down" after the first couple of frames (it's an ffmpeg problem, isn't it? the q32 first I frame?).

there was a slightly more noticable "swimming walls" effect, but less blocking. i may be imagining that one... (i didn't do anything fancy like a "video ABX test" or anything)

[edit]
peak bitrate was slightly higher here. (2813 vs 2621 with a set max of 2300)

[dragongodz]

it's an ffmpeg problem, isn't it? the q32 first I frame?
yes its the rate control. i can limit that but it limits I frames for the whole film then. i will play with that and may add it in 0.52 anyway.

there was a slightly more noticable "swimming walls" effect, but less blocking. i may be imagining that one..
its quite possible. lowering the bitrate spiking etc means increased quant sizes so some detail may be lost etc. thats the price of trying to stick to a maximum bitrate.

[dragongodz]

hmm ok well played wwith some things and i can get those first frames down more but to get them right down means spikes a plenty later. well i will see if i can reach a compramise before 0.52 release.

oh i should mention that those high quant first frames only happen(t least for me) with 1 pass mode and not 2 pass.

oh and do you mean mine peaked higher ?

[TheMaskAgain]

That makes no difference because DvdAuthorGui uses mplex with the same commands as I do, the problem is Quenc. IfoEdit also stops with muxing due to frame drops.

Mplex and DvdAuthor works flawlessly (don't know if this is the right word) with an CCE encoded video.

[dragongodz]

i asume you are doing NTSC ?

ifoedits authoring of NTSC has problems which has been mentioned in the if section many times.

i tested the D2 version with dvdauthorgui and it worked which is why i suggested trying it anyway. of course mine is PAL though. :)

try Rejigs authoring though because i do vaguely remember drop frames problem with that at 1 point. i thought Nic fixed that so it would be interesting to know if that works ok or not. actually i do know Rejig will keep authoring where dvdauthorgui will stop. using normal 0.51 showed me an example of that. :)

actually it may have to do with what JDay posted. be nice to know for sure.

[PVNC]

Hey. I've tried using the latest version of QuEnc, but it's only done two things for me. Originally, I got the famous:

AVS file is not outputing
(Use ConvertToYV12() at end of script)

Since then, I've tried playing around with AVISynth some more, obviously adding in that line. Now, however, I don't get an error message - QuEnc simply quits right after I press the encode button. No system crash or anything - the program just disappears. I've checked my AVS in Media Player Classic and VirtualDub, and it works fine in those programs.

I'm trying to encode a 720x480 interlaced NTSC DV AVI. In QuEnc, I've left most of the settings (Bitrate, VBR, High Quality, Trellis, 2-pass) at their defaults. No advanced settings have been checked, except that I've selected 4:3 aspect ratio.

My AVS reads as follows:

AVISource("Ope 2003 Short DV.avi")

ConvertToYV12(interlaced=true)

Note: I've tried both AVISource and DirectShowSource in my AVS - same result each time.

I've read and re-read Doom9's QuEnc guide, checked all the QuEnc threads that I could find, and tried some suggestions that I've seen for similar problems (not having found anything quite the same). No success, obviously. Most stuff here just deals with DVD backups (mpeg2dec and all that stuff). I hope that I'm just making some simple mistake that I haven't heard of before.

I have one theory. When I open the AVS in VirtualDub and check File Information, it lists the decompressor as "ATI YUV12 format codec" - could the ATI codec be causing the problem?

[dragongodz]

ok can you try a couple of things for me then ?

first download and use bigfix found here
http://forums.divx.com/viewtopic.php?topic=54711&forum=1

its more aggresive than the vid cleaner that comes with xvid. i remeber that i did use this and i no longer have the crash when quit problems etc.

then see if you still have the problem.

if yes then can you try directshowsource instead of avisource ?

[Paced]

Originally posted by dragongodz
it would be interesting to know what Nics QuEnc 0.51 spiked to for the same footage. also how many times max bitrate wasnt respected would be interesting but that would be a long slow task i know.

Yep, it sure would be a long task :D From memory, I remember Nic's .51, according to BitrateView, didn't spike as high as your modified version; but, it was indeed close (yours = 3060, Nic's was around the 2990 mark).

Originally posted by Amenophis
had you checked 'scene detection'?.

Yep, Scene Detection was on.

[PVNC]

Thanks, dragongodz. BigFix sort of helped. AVISource now sometimes works, and DirectShowSource sometimes works, too - but they only work for single-pass encodings. It's like QuEnc (or whatever) changes its mind as to which source it will accept. I have to guess. All my attempts at 2-pass cause QuEnc to immediately quit upon commencement of the second pass, if the first pass even works at all (again, it depends on whether it will accept AVISource or DirectShowSource at that time). It seems never to accept the same source 2 times in a row, making 2-pass impossible.

It's probable that there's something wrong with my system, and that it's not even a QuEnc problem. Where should I look for help?

[dragongodz]

yes it sounds like you have some conflicting codecs still.

possibly various codecs all trying to decode the same type.

you will have to check through them and see. such as do you have divx set to try and decode other mpeg4 codecs ? do you have ffdshow set to decode divx or xvid ? do you have xvid set to decode divx aswell as xvid ? how about neros mpeg4 decoding etc etc etc ?

if all else fails you may have to remove some and use bigfix again. then put them on 1 at a time and see when the problem occurs.

[PVNC]

Thanks for the advice. Codecs were a bit messed up, but no longer. QuEnc appears to be working consistently - I have to say, what a fantastic program! Thank you kindly.