NuEnc 0.00d & Libavcodec improvements/suggestions

[Peter Cheat]

These are the modifications to the original libavcodec, the heart of FFMPEG, QuEnc, FreeEnc, Mencoder, and now NuEnc.

Updated 20/10/04

- New faster quantiser scaling routine. [100%]
This seems to give more of a constant quality than the original code, and saves a few bits on easy-to-encode frames. Now even better than my first slow routine...

- Buffer underflow problem resolved [96%]
Buffer underflows are prevented by increasing the quantiser slightly when pending overflows are detected. Buffer underflows are checked for each frame, and before a frame is encoded, it has been checked for underflow at least thirty times. Also, no more than 90% of the estimated remaining buffer can be used, reducing the possibility of underflow further.

- Max bitrate adherence removed [0%]
Unnessesary.

- Min bitrate works correctly [100%]
Specifying a minimum bitrate doesn't screw up prediction anymore.

- Multipass encoding [90%]
To help reduce bitrate spikes, minor (negligible) improvement in quality. Optimal encoding occurs after 3 passes on average. (Quality _may_ actually appear to degrade with many passes!).

(% = estimate of how close code is to complete and final)

Try the NuEnc frontend, allows multipass encoding and has a "turbo" first pass for those who can't wait so long for an encode to finish. Heaps of other additions, check the site for more details, including forced I frame insertion for chapters. Noise reduction is currently disabled. Scene detection sensitivity increased and other changes made to improve quality :D.

Source code, and some compiles are available here: Modified Libavcodec Site (http://petercheat.host.sk/libav/)

[JDay]

Would you mind re-uploading "ffmpeg+avcodec.zip"? The zip seems to be corrupt.

[Amnon82]

yeah it is broken. I'm realy intresting in this modded version. Maybe I can use it for my EasySVCD/DVD release.

[Paced]

Originally posted by JDay
Would you mind re-uploading "ffmpeg+avcodec.zip"? The zip seems to be corrupt.

It's not broken; the same thing happened to me a few times. Make sure that your .zip file is 933kb in size - for some reason my Internet Explorer ( :devil: ) "finished" the download prematurely on several occasions. Fortunately, after several tries, I was able to get the entire 933kb :D

[Amnon82]

k, i get it!

@Peter Cheat: I'm using now your avcodec.dll in the new version 0.4 of EasySVCD/DVD. This avcodec.dll is much better. Can you write a guide for editing and compiling ghe avcodec.dll. My last compile was 2.55 MB. I think there was all the mpeg4 stuff in it. What is the easiest way to get rid of it?

[JDay]

Yeah, it seems to be all there. I was able to get it ok , using IE. In Firefox (what I normally use), I had to start the download a few times, since it kept finishing prematurely (no errors given). Got it in the end though. I'll start testing, now.

[JDay]

Well, found a problem with this version. I encoded a small clip with DVD-RB and QuEnc 0.51 D2 test. With the avcodec.dll that came with QuEnc, I got good quality, and ended up with a file about 68.2mb (68.1mb with CCE; 02m,27s @ 4177kbps). I tried this version on that clip (and a few neigboring cells from the disc) and ended up with a rather ugly 12.3mb file.

Here are some bitrate viewer screenshots of that clip:

CCE:
http://img13.exs.cx/img13/8995/CCE-BV.png
QuEnc (Old):
http://img20.exs.cx/img20/5426/QuEnc-Old.png
QuEnc (Peter Cheats's):
http://img20.exs.cx/img20/3213/QuEnc-New.png

Hope this helps! I'll do some testing on some other source and target material later tonight.

Oh, by the way, the tested disc was Hellboy (R1). That particular clip was progressive, 23.976fps, 720x480, 16:9.

Edit: Fixed image links.

[dragongodz]

did some quick tests with QuEnc 0.53. i even changed the b offset to 1.0 (b factor is already 1.50 for 2 pass). yep not good. all high quants (ranged 26-30). so no good for QuEnc anyway.

peter cheat - is there any other settings you can think of that need to be changed in QuEnc ?

[dragongodz]

just tried using ffmpeg and near the end of the first pass a heap of underflows were reported. no problem since it is just the first pass.
second pass though crashed at about the point those underflows were reported. so somethings not right there.

[Peter Cheat]

I didn't actually do any tests with FFMPEG :o

I use Mencoder for all my testing. Mencoder is good, you just have colour problems when using the internal resizing & with XviD sources.

My DLL does NOT work with QuEnc 0.53. I tested it, and the output was far too small, and blocky. Obviously QuEnc should be compiled with new avcodec.lib for it to work.

@Amnon82 A 2.55MB file is about the right size. I use UPX (Ultimate Packer for eXecutables) to make it smaller. It is widely used.

I have written code for a third pass, and it works. Initial testing shows that max bitrate is not exceeded anymore, but this is with a very short 1500 frame clip. Also, the spikes in second pass have been reduced by fixing up scene detection code (it was enabled in second pass meaning that some p-frames were changing to I-frames, making prediction very hard indeed).

The 3-pass code will be uploaded at some stage soon, but more files needed modification. Since I did the changes for Mencoder, I'll need to change FFMPEG first. I'll also test FFMPEG before uploading it this time.

[Amnon82]

I wrote also a gui for mencoder. So I have only to replace the three modded files with ther orginals in the source of MPEnc.

Lets see how it works ...

[Peter Cheat]

Originally posted by dragongodz
just tried using ffmpeg and near the end of the first pass a heap of underflows were reported. no problem since it is just the first pass.
second pass though crashed at about the point those underflows were reported. so somethings not right there.

The version of FFMPEG I have been using seems broken. Crashes when writing the last line of the log file. Not sure whether I did that, or not (I dont think so :D ).

Anyway, 3-pass code has been done, and is updated on my site. It works well.

Comparing the number of times the max bitrate was exceeded using same 4min clip (music video)-
TMPEGEnc 2.59 2-pass: 30 times
Mencoder (modified libavcodec) 2-Pass: 40 times
Mencoder (modified libavcodec) 3-Pass: 0 times

The maximum bitrate is now adhered to very well in 3-pass. Not perfect when doing low res, low bitrate encodes, but flawless so far with DVD specs.

The modified avcodec.dll works with QuEnc 0.54 (QuEnc is now compiled with latest libavcodec sources). Three pass is not available with it though...

[dragongodz]

The modified avcodec.dll works with QuEnc 0.54
cool. will have to test it some time during the week. hopefully others will aswell and report back. :)

QuEnc is now compiled with latest libavcodec sources
well actually QuEnc 0.52 and 0.53 used CVS checkout from early august while for 0.54 i went back to the 12th july version. thought that would be easier for people to get since it can be directly downloaded from FFMpegs page.

[JDay]

I encoded my test clip with this latest version (using QuEnc). Results were much better than last time (see my post above) but I still noticed something odd. With all other encoders (and other avcodec builds), the q. level roughly follows the same pattern as the bitrate. Here, it seemed that it stayed mostly constant except when the bitrate dropped below the q. level, in which case it increased slightly. I'm no expert in this area, so I'm not exactly sure what this means, its just something that caught my eye. Bitrat-viewer screenshot is below, which can be compared with the previous shots in my post above.

http://img53.exs.cx/img53/2818/QuEnc-8-30-04.png

[dragongodz]

JDay - what settings did you use, such as max bitrate etc ?

[JDay]

Originally posted by dragongodz
JDay - what settings did you use, such as max bitrate etc ?

I think I kept all the default setttings. Mpeg2, high quality, vbr, 2 pass, 12 - gop size, 2 - max b frames, 8 - dc precision, 9800 - max bitrate, all advanced settings unticked, @4177kbps.

Edit: And could someone please give me some info on the q. level and how that relates, or should relate, to the bitrate? Thanks.

Edit 2: Also, I see that the QuEnc encodes have a linear quantscale, while cce and tmpg encodes are listed as nonlinear. What does this mean, exacly? Is this significant?

[Peter1234]

Peter Cheat,
Your new compiles of avcodec.dll seem to have the SSE2 problem discovered by VMesquita in FreeEnc (see http://forum.doom9.org/showthread.php?threadid=80544&highlight=SSE2). On my P4 system your avcodec.dll seems to crash about half of the time. He solved this by disabling SSE2 with a patch. I do not know details.

[dragongodz]

ok did a quick test on a very short (just over 1 minute) clip at dvd size.
average bitrate 3000, max bitrate 4300.

my compile and tmpgenc never exceeded max bitrate, slightly undersized. peters exceeded max 3 times and average bitrate exceeded slightly. i even tested by changing the b quant factor to what peter says on his page and no difference.
also i notice his compile has the pulsing with playback while mine doesnt.

so its getting there but not quite ready yet. :D

JDay - i did not get the flat quant level you did but then again i set much lower average and max bitrates. the q level is quantisation level. that is how much each frame is quantisised. the higher the quant the smaller the frame size(ignoring motion vector info etc) and also the less detail retained. think of it like blurring, the more blurring the less fine info needs to be kept, result smaller size.
ok before anyone jumps on that let me say i am just trying to explain it in the simplest terms that anyone can understand, ok ?



seem to have the SSE2 problem
He solved this by disabling SSE2 with a patch
or you could simply compile it with cygwin or even try the mem-align-hack as i suggested to vmesquita(which i dont think he did try).

[JDay]

Thanks dragongodz, that's what I thought. But if a higher q. level means a smaller frame size, you'd expect it to fluctuate in inverse of the bitrate, correct? However, as you can see on my previous BV screenshots of CCE and the standard avcodec, it seems the bitrate and q. level follow the same path. Am I missing something?

Anyway, I did some more tests, using the same clip and settings as before, but trying some different bitrates (2000, and 8000). I found that on my encode at 2000kbps, the q. value was an inverse of the bitrate. At 8000kbps, the q. level and bitrate followed roughly the same path. Given these results, and my encode earlier with a nearly flat q level, it would appear that there is some sort of bitrate threshold, near which the q. level flattens, and beyond which, it inverts.

Here's some more BV screenshots of those encodes:
http://img53.exs.cx/img53/3571/QuEnc-2000.png
http://img53.exs.cx/img53/5571/QuEnc-8000.png

[Peter Cheat]

Originally posted by Peter1234
Peter Cheat,
Your new compiles of avcodec.dll seem to have the SSE2 problem discovered by VMesquita in FreeEnc (see http://forum.doom9.org/showthread.php?threadid=80544&highlight=SSE2). On my P4 system your avcodec.dll seems to crash about half of the time. He solved this by disabling SSE2 with a patch. I do not know details.

Oops, I know about this problem, will be fixed next compile (have to disable SSE2)

@JDay
The rate control has been modified to give a more of a constant quality. A parameter will be available (soon) to adjust the modulation. The constant Q level in this case is caused by the Max bitrate adherence in this particular case it seems. CCE and TMPEnc use logarithmic scale quantisation, supposed to be better, but turning a linear scale to pseudo-logarithmic wouldn't be hard, and although it is said that logarithmic is better, its all subjective

I would like to get something clarified (as the SVCD, and DVD specs are unclear).

Is max bitrate:
- the average bitrate over each second (like in bitrate viewer)
- the average bitrate over a gop (mention before somewhere?)
- or the maximum a frame can be

I have used the latter, but it makes for crap encodes as I Frames are slaughtered with high quants.

[dragongodz]

JDay - i was trying to make it simple so didnt mention other factors. things that effect size aswell is actual frame content. simple example - frame 1 is completely black, frame 2 is bright with lots of colours and lines etc. do both frames at the exact same quant. can you guess the sizes of the frames ? the black frame will be tiny while the colourful one will be much larger. so yes it can be inverse some frames and then not others or even completely one or the other but that depends upon what the footage is. the bitrate line is more important so dont worry to much about the quant line for now. :)

have to disable SSE2
why not just compile with cygwin or at least try the mem-align-hack ?

Is max bitrate:
- the average bitrate over each second (like in bitrate viewer)
- the average bitrate over a gop (mention before somewhere?)
- or the maximum a frame can be
well since the actual dvd specs cost a lot of money and then you have to sign a non-disclosure agreement......who can say ? :)
all we can go by is actual experience. heres a little arguement over it
http://club.cdfreaks.com/lite/t-76710.html
now lets assume thats right and its per second. the problem also arrises from the fact that people have reported problems when you have frames spike above the max aswell which suggests the 9.8Mb is also the max per frame.

oh and about I frames. they contain no motion vectors etc so they should actually be able to be a lower quant for the same size as P and B frames. :)

[Inc]

Nice, cant wait to test the new mod of libavcodec. :)

A very nice test sequence is the beginning of KillBillVol1.

Right at the beginning you see the Miramax Inro where the camera moves from the ocean up to the city-skyline where then the Miramax Logotype appears.

This movement over the water(ocean) means a very complex luma changing pixel contend which does let jump up at other encoders the bitrate or the quantizer if max bitrate ist set to low.

This sequence is directly followed by a totally black screen sequence. Here the encoder can show how he reacts on such changes ;-)

I used that sequence and other sliced parts of that movie to test FreeEnc, Qenc, mencoder and CCE.

Greets
Inc.

PS: Also for high peaking tests you can use "Poltergeist" at the scene where you can see the full of snow television screen.

[Peter Cheat]

Originally posted by dragongodz
oh and about I frames. they contain no motion vectors etc so they should actually be able to be a lower quant for the same size as P and B frames. :) [/B]

Hmm. Then why not encode with only I frames? Because I frames are much larger than P,B frames. Why? Because I frame contain the information about the whole frame (basically JPEG compressed). P frames are the differece between previous I and P frames. B frames are the differences between the P frames on either side (before and after) of the frame.

Hence, I frames almost always biggest, and get considerably bigger with lower quants...

Apparently, there are NO software encoders that strictly comply with the DVD standard. What is the chance of making libavcodec able to make strictly compliant to play with 100% of DVD players? I don't know but all odds are against it...

[dragongodz]

Then why not encode with only I frames? Because I frames are much larger than P,B frames
yes i know that. look at other encoders though and see what quant they are using for I frames comparitivly and you will see what i am talking about.

P frames are the differece between previous I and P frames. B frames are the differences between the P frames on either side (before and after) of the frame.
again not telling me anything i dont already know. the motion vectors do happen to add to the size of the frame though so generally(especially low bitrate encoding) you will see them use the same or higher quants than the I frame preceding them. notice no pulsing with other encoders ?

Apparently, there are NO software encoders that strictly comply with the DVD standard. What is the chance of making libavcodec able to make strictly compliant to play with 100% of DVD players? I don't know but all odds are against it...
hmm well the problems with CCE as i have said before seem to be when using 1 or 2 pass, its possible more doesnt have a problem. also CCE using a lower max bitrate(using a max of 9000 and up seem to be the problem) does create compliant streams, well it fixed the problems some people had. i dont know how many people make dvds with Tmpgenc or Procoder so there is no real way to say how much problem they have. 100% is the target even if it is unreachable. if you can get avcodec to hit bitrates consistantly the same as Tmpgenc and CCE then that should be damn good. :)

[Peter Cheat]

libavcodec has better potential than both TMPGEnc and CCE. The motion search is more sophisticated I believe (looking at the motion vectors chosen by all three).

I noticed that the pulsing seems to be caused by the lack of I frames compared with TMPEnc and CCE. By reducing the scene change threshold (and increasing the number of I frames), the first pass size (at const quant) actually is REDUCED!. This even surprised me. I have updated avcodec.dll with a good scene threshold value hard-coded in for first-pass (2nd pass uses first pass frame choices).

Looking at CCE and TMPEnc, both encoders use the same or lower quants for I frames. Using TMPEnc 2.59, you can see the frame sizes when you have enabled the writing of the log file. This clearly shows that I frames are the largest frame in the GOP 99% of the time. Sometimes a P-Frame is even larger in high motion.

How can I get libavcodec to hit bitrates consistently the same as CCE and TMPEnc? CCE and TMPEnc both use different bitrates for the same scene (view with bitrate viewer). The point is not to copy/imitate other encoders. Libavcodec is very different in many ways. The rate control is just going to be another of those things that makes it different. I beleive that with some effort, libavcodec can become better than commercially available encoders. It already performs better at lower bitrates than both CCE and TMPEnc (TMPEnc creates blocky material, CCE makes it so noisy and ugly its unbearable).

Everyone seems to use "Bitrate Viewer" to look for bitrate spikes/max bitrate. "Bitrate Viewer" looks at every second of video (24,25,29.97 etc frames, depending on frame rate), AVERAGES the bitrate over this second, and then reports this as the bitrate at this second. It doesn't report the "real" max bitrate, meaning it doesn't report when an individual frame exceeds the max bitrate. The DVD (and SVCD) specs seem are simply not specific. SOME ORIGINAL MOVIES DO NOT EVEN WORK IN DVD PLAYERS. SOME MOVIES DO NOT PLAY ON WINDOWS 2000/XP (without a fix) This is because hardware manufacturers interpret the standard one way, companies that author original DVDs interpret the standard another way and hence we have a problem!!! Some manufacturers knowingly create their hardware out of spec. 100% compatibility is at the moment an impossibility.

Visit http://www.dvddemystified.com/dvdfaq.htm and take a look for yourself. The standard should be clearly rewritten to combat this issue. Also, the official specs should be distributed for FREE everywhere, not that you have to pay large amounts of money to see a document (that is vague and poorly written).

Btw, I updated my modified avcodec.dll using the "Bitrate Viewer" max bitrate model. Maybe this will work better. Picture pulsing seems to be resolved now, but I haven't done much testing with this.

Im out,
Peter Cheat

[Nic]

Hi Peter,

Good work :) Could you update the source code on your website? I'm finally finding a little time to be playing around with it myself :)

Thanks,
-Nic

[Peter Cheat]

FFMPEG sources are now updated. Its best to do a clean compile to use with QuEnc, as just using the DLL is really dodgy. avcodec.h needed to be modified for implementation of 3-pass.

FFMPEG may crash at the end of 1st and 2nd pass, seems to be a log file writing problem. This means the last line os the log is cut off, the output stream is fine.

[dragongodz]

Peter i will continue to discuss this by PM. that way i can be more to the point. :)

[RobertR]

@Peter Cheat:
Can you please post your full source of ffmpeg/mplayer ? I'd like to make a diff out of it and apply it over what i get from ffmpeg/mplayer cvs (i'm trying to use libavcodec for dvd backup under Linux).

Last week Paul Curtis on ffmpeg-devel mailing list posted a patch that

This patch inserts the correct information into the MPEG2 stream for the creation of DVDs. I am using 'dvdauthor' as the benchmark for reating DVD VOB files.

This patch creates PCI/DSI (NAV) packets after each GOP start. This means that forwarding and rewinding should stop on a complete frame of video, and should eliminate the "blocking". In addition, this also
removed the problem of audio being out of sync after a rewind or
fast-forward.

The command line to create a DVD complaint MPEG is:
ffmpeg -i your_inputfile -target dvd outputfile


From what i've read on ffmpeg-devel ML this patch was not put into cvs. It should be in ML archives (see ffmpeg.org for details). If You can't find it i can post it on my webpage.

Could You consider cooperating with ffmpeg team to incorporate your patches back to main source tree? (i know i've already asked this but this was w/o any echo :)

[dragongodz]

i see this is being discussed in the FFMpeg mail list so i thought i better make some comments to clear some things up.

forced scene detection is not the solution to the pulsing. try QuEnc 0.54 with its normal avcodec.dll and you will see no pulsing even when scene detection is disabled. how ? i changed I frame factor to force I frames to a lower quant. originally you would get things like I(3),B(1),B(1),P(1), where the numbers are the quant for that frame. the higher quant I frame is what causes the pulse. look at any other encoder and that will only happen on extremely rare occasions. instead you are more likly to see I(1),B(2),B(2),P(1) etc. you will notice it also doesnt suddenly flood with underflows because of the change.
why nobody has noticed that before i have no idea. :D

also about max bitrate. i have PM'd Peter 2 different links which suggest the max bitrate is 9800kbit per second AND a max spike/burst(for VBR obviously) of 9800Kbit per frame for dvd.

i believe mpeg2enc had reasonably good rate control(though i never really used it, just what i have read) so maybe it would be worth looking at that and maybe xvid 1.1 branch to see what they are doing aswell. it may help to give ideas etc on how to improve avcodecs rate control.

[RobertR]

I've mailed ffmpeg mailing list about this. Note however that i don't plan to be a forum2mailinglist gateway ;)
Michael Niedermayer wasn't too enthusiastic about Peter Cheat changes.
I've done some simple tests with Peter Cheat's patches under linux and results were visually bad. I'll rerun this testversion again with exact same settings as dargongodz is using in his latest QuEnc.
For now dragongodz your settings give the best results for me (just need to get rid of macroblocks all over gradients).

[Peter Cheat]

Originally posted by RobertR
I've mailed ffmpeg mailing list about this. Note however that i don't plan to be a forum2mailinglist gateway ;)
Michael Niedermayer wasn't too enthusiastic about Peter Cheat changes.

I'm glad he is. My changes are just experiments to improve the codec in the future, not to use now. It completely sux at the moment. I fixed some code yesterday that improved the picture significantly. My changes are for testing to see what happens. You need to sometimes make one step back before making two steps forward.

My aim is to change quantiser distribution so that lower quants are given to spatially complex frames, and higher quants given to temporally complex frames (you can see detail well during motion). At the moment, libavcodec doesn't do this. There are also many other issues that need resolving.

@Dragongodz
I have a clip that pulses when encoded with the original QuEnc 0.54 dll. The pulsing is strange as the pulse is cause by noise from the P,B frames before an I frame, which suddenly disappears when the I frame comes up (its a slow-moving scene). Hmmm.

[RobertR]

Originally posted by Peter Cheat
I'm glad he is. My changes are just experiments to improve the codec in the future, not to use now. It completely sux at the moment. I fixed some code yesterday that improved the picture significantly. My changes are for testing to see what happens. You need to sometimes make one step back before making two steps forward.

My aim is to change quantiser distribution so that lower quants are given to spatially complex frames, and higher quants given to temporally complex frames (you can see detail well during motion). At the moment, libavcodec doesn't do this. There are also many other issues that need resolving.

Please please please do us all a favor and subscribe to FFmpeg mailing list. It's rather low volume. All the developers are there so you can present your point of view.
I'd also like to ask you to either post a diff to sources or full sources of libavcodec/mplayer/ffmpeg/whatever-u-are-changing. I've spent most of evening butchering my mplayer sources so they will compile (i;m using cvs almost daily updated). If you lack web space i can provide you with some :)

[Nic]

Keep up the good work Peter, I'm sure you'll get to your goals. I'll wait till your next source code release with your new bugfix and then release a new QuEnc for people to test your changes :)

@RobertR: Please stop repeating your request to Peter, I'm sure Peter will feel more happy about his code being picked apart by those on the ffmpeg list when he's finished with it. Rather than people criticising what is unfinished code.

Cheers,
-Nic

[RobertR]

@Nic
Point taken.

@Peter Cheat
I'm very very sorry for pushing.
I just thought that cooperating even at early stages can just get Your code better not to mention the chances to fold it into main stream sources (as i understand Michael Niedermayer is the one who governs which patches are accepted and which are not). All i really want is free MPEG2 encoder that can beat CCE and can run on diff operating systems. FFmpeg is very promising in both areas.
For now i'll just shut up and keep testing :)

[dragongodz]

I have a clip that pulses when encoded with the original QuEnc 0.54 dll. The pulsing is strange as the pulse is cause by noise from the P,B frames before an I frame, which suddenly disappears when the I frame comes up (its a slow-moving scene). Hmmm.
thats a different type of pulsing. thats more like rate control running out of bits for the later frames in the GOP. so bit distribution would need to be refined to fix that properlly i would think. some more tweaking to settings may help reduce it aswell but i dont have time to at the moment.
the normal pulsing is bad I frames ,which can be seen using the normal FFMpeg settings, with any type of footage. the change to settings i used fixes that only, atleast in the tests i did. :)

[Peter Cheat]

@RobertR
All my modifications of sources is basically butchering the current CVS. The reason for not becoming a member of the mailing list is too not stir up a huge fuss and flame wars. To them, I'll be some try hard n00b wrecking all of their hard work (in their eyes), which is not what want. Copying my sources over the latest CVS should work without problems (but no guarantees there).

What I am trying to do is address issues that have been ignored for some time. But before I started modifying code, I knew little about video compression, very little C (but I know Java pretty well) and very little about rate control. I had to read dozens of documents before i could get started on the code, and I had to read the current code line by line to work out how it worked exactly. This all took time. Now I am just testing out different algorithms for rate control etc. They are unfortunately, tuned to specific video scenes that I test with right now. A generalised rate control algorithm is the aim. Atm, it isn't far from this, it just needs refinement.

The idea is that I listen to input and feedback, and make changes/improvements that the general encoding public want done (this mean you). The more input/feedback I get, the better the code will be.

Currently, I can't update with anything new as I am halfway through a rewrite of the bit allocation for 2nd & 3rd pass (note that the third pass atm is a bit of a hack). This will improve the quality of some low-motion scenes that are currently attacked with too high quants. This will be finished by Wednesday (I hope). I don't actually have any free time right now, I code during breaks and late at night.

My final aim is to have decent code by Christmas that I can submit to the CVS. At the moment, it isn't even close...

The only part 100% done is the 'compressibility' parameter used to predict the future frame size/3rd pass frame size. This is a good approximation based on the fact the the relationship between texture bits and quantisation level is linear (linear quantisation). This IS better than how it is originally done, BUT cannot be implemented without a complete rewrite of rate control.

I'm out,
Peter Cheat

[mean]

For the crash, it may be due to a win32 quirk
When you switch from reading to writing on a file open in rw mode
you MUST do a fseek(0,SEEK_CUR)
in between

Don't know if that's the problem here, but it took me some time to figure it out on another stuff i'm working on.

HTH

[dankescheen]

Hello L&G,
a short test ( 4:3 PAL-clip, 2616Frames, 720x576 - Encoder-Settings: AVG3100 / max8000 / GOPsize 15) gives me strange results :

V0.54 / avcodec Peter Cheat (2pass)

AVG 8658 Max 18684 Filesize 136 MB !!!

Very bad quality - pulsing & blocky i-frames


V0.54 / avcodec Peter Cheat (1pass)

AVG 2401 Max 3797 Filesize 38 MB

quality is OK


V0.54 / avcodec memaligned (2pass)

AVG 2483 Max 5101 Filesize 38,7 MB

quality is OK


V0.54 / avcodec original (0.54package) (2pass)

AVG 2447 Max 4499 Filesize 38,7 MB

quality is OK


V0.51 / avcodec original (0.51package) SinglePass !!

AVG 2439 Max 4534 Filesize 38,4 MB

quality is OK


Sorry boys, I can't see any positive effect in the enhancements ....
I never had any problems with Nic's last version. I always set the max. Bitrate at 8000 and the AVG between 3000 - 5000. (Yep, my Excel-Sheet works great). SinglePass is OK for me, because more passes only take more time without a real quality difference.

Cheers & keep up your work :)

[Amnon82]

I wait for christmas ... santa :D

[Peter Cheat]

Originally posted by dankescheen
Hello L&G,
a short test ( 4:3 PAL-clip, 2616Frames, 720x576 - Encoder-Settings: AVG3100 / max8000 / GOPsize 15) gives me strange results :

V0.54 / avcodec Peter Cheat (2pass)

AVG 8658 Max 18684 Filesize 136 MB !!!

Very bad quality - pulsing & blocky i-frames

Yes this does happen. My last update does not work correctly with QuEnc. The changes I have made the DLL significantly different. This is why QuEnc needs to be compiled with the updated library to work correctly. But this is not important for now. My changes seem to suck for DVD resolutions, and are better for SVCD resolutions, where the content is relatively low motion with few high to very high motion sequences.

Rate control will be changed completely by Wednesday, it is half done, bits are now distributed to the GOP as a whole, and bits are then prioritised with I being highest, P frames next, and B frames last. The code is better structured, and now that I am looking at mpeg2enc, will be similar to that.

[Nic]

So how's it all going Peter? Still working on it?

-Nic

[Peter Cheat]

Assigning bits to frames did not work properly. You end up with poor quality overall. I'm going back to a more traditional approach, and will upload asap maybe with an example encode.

[dragongodz]

though assigning bits to frames is possibly good for CBR. something for the future when VBR is working better. :)

[Peter Cheat]

The problem was that the prediction seemed to be off. So it wouldn't work for CBR either. But I found an error in my code which would have been a cause to the problem. I'll try it out again if when I get some time (tomorrow) because, as you said it could be good for CBR. Kill two birds with one stone, so to speak.

[RobertR]

I've tested your ffmpeg version under Windows (could You please post your sources too? my ability to test anything under windows is somewhat limited). This time i was impressed with quality of encode (I aim at DVD backup so am using bitrates around 4000 kbit/s). I have to admit that last time i used command line that was posted on Your website and results were umm.. erm.. baaad. Anyway this time encode was just perfect. I also compared encodes made by 'normal' libavcodec (made with mencoder under linux) and 'your' encode using Bitrate Viewer.
Average bitrate was set to 4000kbit/s and max bitrate to 8000 kbit/s. With normal libavcodec bitrate never reached 5500 kbit/s, modified libavcodec it went up to 6000kbit/s (might be even more i'm writing it from memory). Bitrate curve in 'your' encode was more like bitrate curve in the original cell, while 'normal' libavcodec created more flat bitrate curve.
For me it's awsome :) (at least on the sample i could test under windows ;)

[Peter Cheat]

It is slowly improving. The sources will be uploaded soon. I won't upload it yet, I am still trying to change the rate control to a bit assigning algorithm rather than quantiser assigning algorithm. The only advantage of the bit assigning algorithm will be speed, but this is probably necessary if you try to encode a long sequence as the rescaling routine will take a long time, and they may happen quite frequently, especially during high motion scenes. Assigning bits will mean that quantisers will not have to be rescaled, bits will just have to be added/subtracted proportionaly during the encode as the predictor is not 100% accurate. I have other things to do at the moment so this work has been put to the side momentarily, but I will update very soon.

[dragongodz]

good to hear from you Peter.

turning in to major task isnt it ? you can probably see why not alot has been done with it for some time. :D

[Peter Cheat]

I think that the reason that nothing was done to it was because it required almost a complete rewrite to stop the max bitrate from being exceeded and to prevent underflow. Many people who spent a large amount of time creating quantiser blurs that follow differentiable functions will probably pissed off to see this code absolutely destroyed and replaced with less mathematically elegant code that just does the job. If I didn't have to try to work out how the code work originally, it would have saved me a lot of time! There is only a few hours of coding to have it finished, I just have assignments and other things to do, which have higher priority.
*Goes back to writing 40+ page report*

[dragongodz]

I think that the reason that nothing was done to it was because it required almost a complete rewrite to stop the max bitrate from being exceeded and to prevent underflow
actually i did read that Michael(of FFMpeg) has partially written a different rate control from scratch aswell. his plan is/was to have it selectable(so you could choose old rate control or the new one). i think your version will be ready before his is though as he seems to be working on other parts of FFMpeg ,such as the snow codec, most of the time. :)

less mathematically elegant code that just does the job.
ye no doubt some will complain its not elegant or neat etc etc etc but who cares. its the end result that matters first. once its working people can clean it up or whatever they like.

[tie82]

Hi,

i have big probs with your avcodec.
Using it with FreeEnc, the encoder always crashed after the 1. pass (just closed itself). Then i used 1pass-coding to see the result and he gave me a corrupt m2v with a picture like this:
http://home.arcor.de/ossionline/Zwischenablage01.jpg

With the original FreeEnc-avcodec there are no problems except the bitrate (much too small)
With the avcodec from quenc i have no probs anyway, but i want to test yours :).
Using Win XP Pro on an Athlon XP 2400+.

Perhaps you know wath the prob is or it can help you in the development ;)

Greets
tie82

[Amnon82]

The version compiled 09.09.04 chrashed my newest ESD 0.5. I add now the 01.09.04 dll to this release.

[Asmodeus]

Originally posted by tie82
Hi,

i have big probs with your avcodec.
Using it with FreeEnc, the encoder always crashed after the 1. pass (just closed itself). Then i used 1pass-coding to see the result and he gave me a corrupt m2v with a picture like this:
http://home.arcor.de/ossionline/Zwischenablage01.jpg

With the original FreeEnc-avcodec there are no problems except the bitrate (much too small)
With the avcodec from quenc i have no probs anyway, but i want to test yours :).
Using Win XP Pro on an Athlon XP 2400+.

Perhaps you know wath the prob is or it can help you in the development ;)

Greets
tie82

Last build of FreeEnc isn't set for newest Peter's avcodec build, so this might hapen, and also in my computer hapens.
For sugestion about FreeEnc beter go here (http://www.kvcd.net/forum/viewforum.php?f=85&sid=28e07ce7753bb9c61a74bba1953fca57).

[Peter Cheat]

Current Development Status (for those who care)
-----------------------------------------------

1. Two algorithms are being developed simultaneously. One which allocates quantisers to frames, and one that allocates bits to frames.

Allocating quantisers is the best for constant quality it seems. Bit allocation introduces so many uncertainties, I frames either get too many bits or too few bits, B frames sometimes get a quantiser lower than the P frames on either side. This is a problem. Using >3 passes solves the problem with bit allocation, and it turns out to be better than a quantiser distribution with the same number of passes.

2. Max bitrate is adhered too properly.

3. Bit allocation algorithm broke the buffer underflow protection code. Should still work properly with quantiser distribution.

4. X-pass encoding. If CCE has 10 passes, why not have infinite? (ok, its pointless, but why not have it if you can)

------------------------------------------------

Expect an update on Wednesday. It will come with a clean compile of QuEnc (obvioulsy renamed to not cause confusion) which will work 100% and take advantage of X pass encoding. I will probably move the site elsewhere, because host.sk is slow and people are having trouble getting files from it.

[dragongodz]

(for those who care)
many of us do. :)

If CCE has 10 passes, why not have infinite? (ok, its pointless, but why not have it if you can)
well you already answer yourself, its pointless. with CCE doing more than 3 or 4 passes is pointless, i dont know why they bothered to go all the way to 10 passes.

[lithoc]

IMHO,I would say if there's features that allow turbo mode in the 1st pass like Xvid would be nice.
I don't mind doing more than 2 passes if it's faster.

[Bogalvator]

I'd just like to say that I also follow your developments with great interest and I eagerly await your updated QuEnc.

Keep up the good work!

[Peter Cheat]

Originally posted by lithoc
IMHO,I would say if there's features that allow turbo mode in the 1st pass like Xvid would be nice.
I don't mind doing more than 2 passes if it's faster.

Ok, this will be a feature. Turbo mode will disable trellis and any other features that slow down the encoding process, but have negligible affect on the statistics obtained, just like XviD.

@dragongodz
Allowing infinite passes actually meant I delete/simplify some code. Also allowed me to check how good the algorithm for quantiser distribution was. By 6-7 passes, the output was spot on in the filesize department without the use of the bit pool, ie the frame sizes were almost exactly what was predicted. This means that by this stage the encode is optimal. I tested with short clips, I don't know if longer clips will need more, less or the same number of passes to be optimal. I'll see if PSNR improves with more passes.

[dragongodz]

Allowing infinite passes actually meant I delete/simplify some code.
thats fine, passes can always be limited outside the rate control, such as gui/commandline.suchj as
if(maxpass > x) maxpass = x; // where x is max allowed passes

I'll see if PSNR improves with more passes.
you may want to check out SSIM aswell, meant to be better(not perfect of course) than PSNR which has been shown before to not be 100% reliable. there is a plugin for avisynth which you can use to compare 2 clips.

[dragongodz]

oh ye, is min bitrate working with your changes aswell ? that would be very good to have fixed too. :)

[Peter Cheat]

Min bitrate was always working correctly. Libavcodec adds padding when a frame is below the min bitrate. Deliberatly lowering the quant to stay above the min bitrate is not really an option - the quality difference becomes very noticeable.

[dragongodz]

Min bitrate was always working correctly
actually no it wasnt. it used to be when min rate was set to anything other than 0 the bitrate calculation would be buggered. so you wouldnt end anywhere near your target.

Libavcodec adds padding when a frame is below the min bitrate
this was added with 0.49pre1. i dont know when it was actually commited to cvs.

though with your rewriting the allocation etc anyway i guess it shouldnt be a problem. :)

[lithoc]

Originally posted by Peter Cheat
Ok, this will be a feature. Turbo mode will disable trellis and any other features that slow down the encoding process, but have negligible affect on the statistics obtained, just like XviD.



Thanks a lot.

I'm very happy with the developement of this project and looking forward to do some testing. And when the bitrate management is done, hopefully Michael can update it to the main cvs.

[Peter Cheat]

I've had problems getting my modifications to work with QuEnc. I recompiled QuEnc with my DLL, and it encodes, but not correctly. The second pass stats mess up, for some reason. The compressibility seems to be calculated incorrectly. I'm wondering if QuEnc interferes with the texture information, which will wreck my results. Maybe the log() function becomes broken when using with C++ compiled executable. Does anyone know what the problem could be? Also, after doing an X pass encode, I get an error when closing QuEnc saying that "memory could not be read". Do you know the problem Nic?

[dragongodz]

try changing the line

c->rc_initial_cplx = 500;

to

c->rc_initial_cplx = 0;

in AVSEnc.cpp.

also make sure when you compile you use the --enable-memalign-hack option.

[Peter Cheat]

Originally posted by dragongodz
try changing the line

c->rc_initial_cplx = 500;

to

c->rc_initial_cplx = 0;

in AVSEnc.cpp.

also make sure when you compile you use the --enable-memalign-hack option.

c->rc_initial_cplx won't change anything as I don't even use complexity for x pass. Enabling the memalign hack doesn't help, because thats enabled in my compile already. I tested without memalign hack, and it was still wrong. I'll compile it in Cygwin and see if it helps.

[dragongodz]

ok. if you still have problems you can always send me the source and i can try compiling it and see if i can spot whats wrong.

[zilog jones]

I had some weird problems with the GUI - if I pressed the "show desktop" button (in Win2k) while encoding, i couldn't restore the QuEnc window again. It was still working (according to task manager) and made what seemed to be an OK video, but I couldn't see what was happening. I dunno if someone's reported this already. I've got a GF2 and DirectX 9.0b if that's of any help.

Also, if there's two things missing from this great encoder (which I've found sooo much better than TMPGEnc for interlaced video!), it's batch encoding and an auto-shutdown option.

[dragongodz]

bug reports or ideas should go in the normal QuEnc thread really.

I dunno if someone's reported this already.
no i havent seen anyone else report it. anyone else have that problem ?

batch encoding and an auto-shutdown option
auto-shutdown is very easy actually. batch is a bit harder and i dont know if Nic was interested in adding that or not. you could do it now by doing a BAT which calls and encodes several files 1 after the other.

[Peter Cheat]

Originally posted by zilog jones
I had some weird problems with the GUI - if I pressed the "show desktop" button (in Win2k) while encoding, i couldn't restore the QuEnc window again. It was still working (according to task manager) and made what seemed to be an OK video, but I couldn't see what was happening. I dunno if someone's reported this already. I've got a GF2 and DirectX 9.0b if that's of any help.

Also, if there's two things missing from this great encoder (which I've found sooo much better than TMPGEnc for interlaced video!), it's batch encoding and an auto-shutdown option.

Thats not a bug. The GUI has lower priority than the encoder. Lower the priority of the encoder, and this will not happen...

BTW, notice the update. Try it out. Should be better. The problem I had was actually an error in a formula in the rate control. For some reason, the problem only showed itself when used with QuEnc (NuEnc).

[Amnon82]

Only thing I can say is: WHOW!

This multipass is amazing! I tested now 2, 3, and 4 Pass. It's realy great. I think You rebuilding CCE for free :)

Go on with Your great work. I'm waiting for the next REAL release.

I do a test with chapter 29 of Matrix. I'll post my result soon on my page and link it here.

to the test: http://forum.doom9.org/showthread.php?s=&threadid=82931

[spase]

If I am off topic (or posting in the wrong place) please let me know.

Will NuEnc work with DVD-Rebuilder?

[Amnon82]

@spase: NO! It doesn't support DVDRB yet. Maybe in the future.

[Bogalvator]

I tested NuEnc on a 41 minute clip I'm trying to make an SVCD of.

Set it at 5 passes, 2474 average bitrate, 2589 max bitrate, buffer size of 112, GOP of 15, max B frames of 2, turbo, trellis & "High Quality" settings were ticked, and DC precision was 8.

Bitrate Viewer reports the clip has a peak of 4305, and an average of 1915.

Something I missed?

[zilog jones]

Originally posted by dragongodz
bug reports or ideas should go in the normal QuEnc thread really. Sorry! Only noticed the other thread after posting this one...


no i havent seen anyone else report it. anyone else have that problem ?
It doesn't seem to be happening any more, actually. Maybe Windows was just being pissy. It does take a while for the window to re-appear, but then again I'm running it on a P3 ^_^

auto-shutdown is very easy actually. batch is a bit harder and i dont know if Nic was interested in adding that or not. you could do it now by doing a BAT which calls and encodes several files 1 after the other.

Oh yeah, I forgot QuEnc can do command line switches. Sounds like a plan...

[johnnyquid]

@petercheat

Nuenc version 0.00a does not appear to use the -2 switch. I was using DVD Rebuilder to test Nuenc and Nuenc does 1 pass even when asked to do 2 pass. I also started Nuenc from the command line with the -2 option and got the same result (i.e. the number of passes in the pulldown in the GUI does not change).

Also what is the turbo option and is there a command line switch for it?

Are there command line switches for more than 2 passes?

[Peter Cheat]

Originally posted by Bogalvator
I tested NuEnc on a 41 minute clip I'm trying to make an SVCD of.

Set it at 5 passes, 2474 average bitrate, 2589 max bitrate, buffer size of 112, GOP of 15, max B frames of 2, turbo, trellis & "High Quality" settings were ticked, and DC precision was 8.

Bitrate Viewer reports the clip has a peak of 4305, and an average of 1915.

Something I missed?

Ok, there does seem to be some sort of problem here. It seems the more passes you do, the more the max bitrate is increased by. It should be the other way around, but I've seen the same problem. When muxing, were any buffer underflows reported?

@johnnyquid
I didn't do anything with the commandline switches. I didn't check to see if they work. Does NuEnc report that it is doing a 2nd pass in the status area?

Turbo mode disables optimisations for first pass that slow down the encoding process. Trellis is disabled, the mbd is set to 1, and a the cmp functions are set to 0. These settings don't change the first pass stats much, so disabling doesn't really effect quality, but makes encoding much faster. There is no commandline switch for it yet.

@spase
I don't know if it will ever work with DVDRB. I wouldn't use NuEnc for backups yet anyway. You are better off using QuEnc until NuEnc is stable. When it is, source will probably be committed to CVS and QuEnc may see the changes. NuEnc will probably disappear, as it is at the moment only for testing.

What will change for next update:
-Ratecontrol equation will be able to be changed (and hence change the bitrate distribution)
-Ability to chose how aggressive to be with max bitrate
-Extra options for NuEnc (noise reduction, keep intermediate passes)

[johnnyquid]

@Peter Cheat

When using the -2 command line option Nuenc does a one pass encode while showing 1 pass picked on the pulldown list. The display also shows Pass 1/1 as it is encoding. If the -auto option is not used then the pulldown can be changed manually to do two passes. Nuenc will then do the correct number of passes. Oddly, it does not show the pass progress in x/y format but just gives the current pass number. Also note that in the -? display the description for -mpeg2 is obviously wrong.

[dragongodz]

I didn't do anything with the commandline switches.
no but you did change the 2 pass gui control. you can change it to whatever, quit, run NuEnc again and its back to 1. so the new control is not setting/using the information. :)

Turbo mode disables optimisations for first pass that slow down the encoding process
and also produces a slightly larger max bitrate, at least with just 2 passes.

cmp functions are set to 0
i had a quick look at the source and couldnt see that. not that i would reccomend setting them to 0 anyway, 1 maybe but not 0. that will effect size/frame.

[Peter Cheat]

Originally posted by dragongodz
no but you did change the 2 pass gui control. you can change it to whatever, quit, run NuEnc again and its back to 1. so the new control is not setting/using the information. :)

I see now, this will be fixed :D

Originally posted by johnnyquid
Oddly, it does not show the pass progress in x/y format but just gives the current pass number

This had to be changed for X pass. Its better to show the pass number than saying 1/2 for first pass, 2/2 for second pass, and 2/2 for any additional pass...I will change it, I just couldn't be bothered :D

I now have in my possesion the drafts for mpeg2 standards. I will write a summary of the standard, showing that my initial interpretation of what max bitrate mean is correct, and also outlining reasons for jerky playback on hardware players. I also have a book with a more simpler explanation of the standard (the final standard) stating exactly what I have been saying (MPEG-2 by John Watkinson). Buffer underflows are the problem with some streams created with libav based encoders, not the max bitrate...
The other problem is related to the muxing software, libavcodec currently writes the _WRONG_ VBV size to use (look in bitrate viewer or ReStream). Tools that use the value specified in the stream create incorrectly muxed streams. MPLEX allows you to specify the VBV to use, getting around this problem. The VBV size will be written correctly in the next version of NuEnc.

A copy of the MPEG-2 draft ishere (http://www.ee.columbia.edu/~eleft/e6880-Spring98/docs/is138182.pdf). Only minor corrections were made to the final version. This document applies to SVCD/DVD.

[dragongodz]

you may want to try setting min rate to other than 0 aswell and comparing how your rate control reacts compared to set at 0. it would be good to know that does work properly with yours. :)

[Peter Cheat]

Well, I can't test right now, but looking at the code...

static inline double qp2bits(RateControlEntry *rce, double qp, double compressibility){
...
...
...
if (new_bits < min_rate) new_bits = min_rate;
return new_bits;
}


...it should work. The ratecontrol compensates for the minimum rate internally, so there shouldn't be a problem...I will test it later.

BTW, is a CQ mode worth coding. Do people use CQ over two-pass?

[Mug Funky]

no reason not to have a CQ mode... i use them quite often, and they are good for testing various noise filters and whatnot - check the filesize after a CQ encode at quant 2 for example...

currently most of the compressibility stats on noise filters are based on mpeg-4 encodes, and though related, mpeg-2 stats would be nice to play with as well.

bottom line, it couldn't hurt.

[edit]

also, with a slow system like mine, 2 pass encodes are somewhat a luxury . a max-bitrate limited CQ encode is my preferred mode in TMPGenc and CCE (though they work with different numbers, which is a pain).

[Peter1234]

I also think a CQ mode would be a valuable addition.

[dragongodz]

i assume you mean constant quality ?

rate control equation tex is meant to be for constant quality, at least according to the documentation.

i would rather see 1 and 2 pass(or 3 pass) working fully before worrying about CQ aswell.

[Mug Funky]

actually, more specifically i meant constant quantizer (which i suppose amounts to the same thing).

this is more useful for testing filters, and is quite usable for 1-pass encoding if you make a good guess at the output bitrate (doing several encodes of a short-but-representative sample and picking a quantizer based on that gives pretty good results).

of course, this isn't a priority, but it seems like it'd be trivial to implement (there are also things i'd like to see first, such as alternate scan and a field-order setting - QuEnc is extremely good at interlaced content, and alternate scan would deliver even better quality/bitrate. with this i would never need to deinterlace again for my SVCD encodes, even on field-blended video).

[dragongodz]

yes constant quant can be done very easily. avcodec has settings for min and max quant to use. simply set them to the same and you have constant quant. :)

[RobertR]

Originally posted by Peter Cheat

The other problem is related to the muxing software, libavcodec currently writes the _WRONG_ VBV size to use (look in bitrate viewer or ReStream). Tools that use the value specified in the stream create incorrectly muxed streams. MPLEX allows you to specify the VBV to use, getting around this problem. The VBV size will be written correctly in the next version of NuEnc.

Are You refering to value of 1835? Although it may look wrong it is correct value. I don't recall now if i got the explanation from ffmpeg mailing list or kvcd.net forums but above is in kbits and is the same as 224KB ( 224*1024*8=1835008 ).

I've just checked how bitrateviewer reports vbv buffer size and in case of vob taken from dvd it's 112. Feeding bitrateviewer with ffmpeg(1) produced m2v shows the same figure. (I know i've read somewhere an explanation why it shows 112 instead of 224 but can't find it atm)

(1) Since i can't realy test it under windows i've created a patch from your files and applied it to saturday's cvs (i had just 2 easily solved rejects). I've run 2 pass encode this way and resulting m2v is visualy very good (original vob has avg bitrate at 4500, peak at 8000 ; reencoding was set to 300 min, 3500 avg, 8000 peak). I've checked output in bitrateviewer and there were parts where q was almost constant and bitrate was jumping from 2000 to 4000. I've also noticed that in some parts there is huge peak of q (goes up to 5-6) and at same very moment huge drop of bitrate (from around 3000 down to just above 1000). On original vob there is no sign of things like that.
Apart from that encoded file was well within limits (3524 avg bitrate, 7856 peak).

[hank315]

AFAIK the maximum VBV buffer for Main profile@Main level is 1835008.
So you have to put for vbv_buffer_size 112 because the VBV buffer is calculated as:

VBV buffer = 16 * 1024 * vbv_buffer_size

[RobertR]

Originally posted by hank315
AFAIK the maximum VBV buffer for Main profile@Main level is 1835008.
So you have to put for vbv_buffer_size 112 because the VBV buffer is calculated as:

VBV buffer = 16 * 1024 * vbv_buffer_size
Isn't this formula a bit recursive ? ;)
Most of other (than ffmpeg/mplayer) software uses 224 as vbv buffer size. Maybe BitrateViewer shows vbv buffer size in sectors and not in kilobytes ?

[hank315]

Maybe my ISO spec is a little bit outdated (ISO/IEC 138818-2:1995) but according to this spec this is the way to calculate the size of the Video Buffer Verifier (VBV buffer).
I always wondered why some programs would use 224 as vbv_buffer_size so maybe it is better to throw my (outdated ???) specs in the fireplace. :confused:

[Bogalvator]

Originally posted by Peter Cheat
When muxing, were any buffer underflows reported?

Apologies for the delay in responding.

TMPGEnc reported "359 s packets cause buffer underflow" - a lot less than normal.

[Peter Cheat]

Originally posted by Bogalvator
Apologies for the delay in responding.

TMPGEnc reported "359 s packets cause buffer underflow" - a lot less than normal.

It may be a lot less, but still not good enough. I question TMPGEnc's muxing capabilities. I've had problems with it, it sometimes does strange things when muxing, and reports buffer underflows when really there shouldn't be any. Would it be too much to ask to see if you could try muxing with MPLEX or BBMPEG and see if the results are consistent?

Its been a while since I've encoded in TMPEnc, but I think that when you specify a VBV of 112KB, BV reports it as 112KB. I am not sure, though.

I think that this is the correct formula:
VBV buffer = 16 * 1024 * vbv_buffer_size

but I have the feeling that FFMPEG uses:
1 byte = 8 bits
1024 = 1k
224KB * 8 * 1024 = 1835008bits

Also CQ is not exactly the same as constant quant. It is more like an average quant. Say CQ100 = Quant 1, CQ0 = Quant 31. CQ75 = Quant 7.75. But you can't have fractional quantisers. The 7.75 represents the average quant (usually the average for P Frames). It allows for an exact filesize to be achieved, provided you know what value to use. The value wanted can be established using some form of prediction.

[dragongodz]

Also CQ is not exactly the same as constant quant. It is more like an average quant. Say CQ100 = Quant 1, CQ0 = Quant 31. CQ75 = Quant 7.75. But you can't have fractional quantisers. The 7.75 represents the average quant (usually the average for P Frames).
thats why i was asking about constant quality, which is generally considered what you describe, or constant quant. lets call them by their full names so there is no confusion. :)

It allows for an exact filesize to be achieved, provided you know what value to use. The value wanted can be established using some form of prediction.
true for both dependant on the prediction method.

[Peter Cheat]

Well, not really. If you use constant quant you can have only have whole values. The filesize at quant 2 is A and the filesize at quant 3 is B. Say you want file size X. But B < X < A. You can either take the higher quality but larger file or the lower quality smaller file. If you use constant quality (not constant quant), you can use an average quant (say 2.5) to get a more accurate filesize.

[dragongodz]

sorry i should have explained that better.

what i meant was using constant quant you can get within/under your desired size(or maximum size). prediction would give you an idea how much etc so you could decide if that was desirable/adequate.

[Bogalvator]

Tried

mplex -f 4 -V ....

and it returned "**ERROR: [???] MUX STATUS: Frame data under-runs detected!"

Oddly it also said the peak was 5403, whereas BV said 4305.

Could it be because the average, 2474, and the max, 2589, are so close together?

[Peter Cheat]

Bitrate Viewer lies about what the max bitrate is. It takes the average bitrate over each second of video. Maximum bitrate is really quite irrelevant, it is buffer underflows that are problematic.

[dragongodz]

It takes the average bitrate over each second of video. Maximum bitrate is really quite irrelevant, it is buffer underflows that are problematic.
max bitrate is not irrelevant if we take the 1 simple thing that the majority of places/people/etc all state as true and part of the specs.
dvd specs at the least say a max video bitrate of 9800Kb per second. svcd specs has its max bitrate aswell and from a link you gave yourself its been stated exceeding that can cause hardware players to have problems playing the video smoothly. it is all tied in together.

[Peter Cheat]

Originally posted by dragongodz
dvd specs at the least say a max video bitrate of 9800Kb per second. svcd specs has its max bitrate aswell and from a link you gave yourself its been stated exceeding that can cause hardware players to have problems playing the video smoothly. it is all tied in together.

Do you understand what maximum bitrate means? I think not. You can either read the section in the MPEG-2 specs about the VBV buffer, or save yourself some time and read this (http://petercheat.host.sk/libav/maxbitrate-truth.html). I just summarised the meaning of maximum bitrate so it can be easily understood. It is commonly misunderstood, and then incorrect information is passed on. What bitrate viwer about the bitrate is 100% irrelevant in terms of a compliant stream. Maximum bitrate refers to the maximum bitrate the buffer is written to, not the maximum bitrate of the decoded stream.

[dragongodz]

Do you understand what maximum bitrate means? I think not
do you know what a smart arse who thinks he knows more than everyone else is ?
you can keep your opinions of what you think i do or do not know to yourself because i am quite sick of being nice when reading such rubbish. :angry:

a couple of quotes for you
Now some bright spark is going to point out that for a DVD player to be compliant it "must be able to sustain a bitrate of 9800kbits/s for an indefinite amount of time". This is the maximum bitrate at which the video is read from a DVD. This is really only relevant for CBR encoding at 9800kbits/s
wrong, it is relevant for VBR aswell. go to the DVD-Rebuilder section and tell those people who had bitrates exceed 9800Kb/s VBR(using CCE i may add) that their playback problems are irrelevant and see what they say to you.

a buffer underflow can also be interpreted as a maximum bitrate exceedtion
really ? but isnt that irrelevant ? :devil:

let me end by saying that yes i already knew what an underflow was. i also know from my own and others on this forum real life experience of what works and what doesnt. you provided information yourself that said the svcd over 2500Kb/s VBR caused stuttering in hardware players. i point to the DVD-RB forum to show you the same with dvd. now if you want to ignore that well thats up to you.

am i mad this morning ? yes actually i am not in a happy mood and so to any that read this and are insulted/shocked/whatever well sorry but a person patience lasts only so long. i will not bother to post about this again since even with my years of experience i seem to know f*ck all.

[Peter Cheat]

As I said, you have misinterpreted maximum bitrate. Thats the whole confusion dammit. When I said a buffer underflow CAN be interpreted as a maximum bitrate exceedtion, I meant that the DVD/CD needs to go faster than it is capable of to keep the flow of data going. CBR encoding is a special case of VBR. What I have written is not opinionative. It is complete fact straight from the MPEG-2 draft, a subset of DVD and SVCD. See pages 170-175 in the draft specification. I recommend you spend the time to actually read it before replying and making a total fool of yourself. This (http://www.ee.columbia.edu/~eleft/e6880-Spring98/docs/is138182.pdf) document is not opinionative it is the standard. I spent 6 hours reading the ENTIRE document. I've looked at the code for mpeg2enc. I'm 100% sure I understand the standard. Maximum bitrate 9800kbits/s or 2520kbits/s is the maximum datarate at which the medium can be read. It is not the maxiumim data rate of the decoded stream. Thats a fact. I can bet that those streams with playback problems suffered buffer underflows.

I wrote in the document:

Now some bright spark is going to point out that for a DVD player to be compliant it "must be able to sustain a bitrate of 9800kbits/s for an indefinite amount of time". This is the maximum bitrate at which the video is read from a DVD. This is really only relevant for CBR encoding at 9800kbits/s


Sustaining a bitrate of 9800kbit/s per second for an indefinite period MEANS CBR. It means that the minimum bitrate = maximum bitrate. This statement from mpeg.org is relevant ONLY for CBR, where VBR minimum bitrate < maximum bitrate.

Originally posted by dragongodz
wrong, it is relevant for VBR aswell. go to the DVD-Rebuilder section and tell those people who had bitrates exceed 9800Kb/s VBR(using CCE i may add) that their playback problems are irrelevant and see what they say to you.


You will find that I am right on this. CBR is a special case of VBR where minimum rate = maximum bitrate. They reason why a DVD Player (drive) must be able to sustain a bitrate of 9800kbits/s so it is able to play material encoded at 9800kbits/s CBR. In CBR, if the buffer somehow starts becoming empty (wandering laser?) there is no chance in hell of playing a 9800kbits/s CBR encoded DVD without underflow. And underflows DO NOT make a stream non-compliant. Part of the specs states that a decoder must repeat the last decoded frame in the case of buffer underflow until the next frame is available. I could quote 100 pages from the specifications, but that would be a waste of time.

How A DVD Player Works
-----------------------
[DATA READ FROM DISC AT MAX OF 10.08MBPS(9800kbits/s for video)]
This data goes to the buffer, as it is IMPOSSIBLE to decode an MPEG-2 stream on the fly because of B frames (you need the next frame before you can decode the current one), and decoder lag.
[DATA IS LOADED ONTO VBV BUFFER (224KB MAX for DVD)]
Only complete frames/fields can be stored on the buffer
[DATA IS TRANSFERRED FROM BUFFER TO DECODER]
The maximum datarate to the decoder is 15MBits/s as specified by the MP@ML profile. This is the ABSOLUTE MAXIMUM BITRATE for MPEG-2 to be MP@ML compliant and hence DVD compliant. I've not been able to get any encoder to encode at that data rate using MP@ML profile.
[DATA IS DECODED AND FRAMES ARRANGED IN CORRECT ORDER]
[DATA GOES TO OUTPUTS (ANALOGUE/DIGITAL)]

Originally posted by dragongodz
am i mad this morning ? yes actually i am not in a happy mood and so to any that read this and are insulted/shocked/whatever well sorry but a person patience lasts only so long. i will not bother to post about this again since even with my years of experience i seem to know f*ck all.


Don't take it out on me. I've asked you and others to tell me how to implement rate control. NO one gave me any specifics about the standard. So I went fishing for information and found drafts for many standards including MPEG1, MPEG2, MPEG4, MP2, MP3 etc. Since MPEG-2 is a subset of DVD (the video part) and DVD is specifically MP@ML profile, I was able to figure out the video standard required exactly. As it turns out, LIBAVCODEC was always producing compliant streams, it just created a lot of buffer underflows which results to jerky playback. I am a computer systems engineering student. MPEG-2 encoding and decoding is part of my future profession. I know I am right, whether you think so or not is quite irrelevant. Anyone who reads the MPEG-2 specifications and understands them will agree with me. Whether you reply to this or not is irrelevant really. (An apology for your arrogance would however be accepted.)

Problems with CCE aren't really surprising. What buffer size does it use? You do not specify it. CCE probably just makes a guess depending on the maximum bitrate you specify, just like TMPEnc does when you specify a buffer size of 0 (automatic). You can't change it in CCE, and it is not documented, but it is very important for encoding MPEG-2 for DVD.

[Nic]

Lets try and keep things friendly guys :) No need to get upset over interpretations of a specification...

The way I interpret things is as follows;

1) The MPEG-2 Spec is really the superset of the DVD spec, the DVD spec is a restricted subset of the MPEG-2 spec. Therefore an MP@ML stream != a compliant DVD Stream (although of course the two have a lot of similarities)

2) As far as I can see, a DVD Player only needs to be able to read a maximum of 9800kbps. If the bitrate for a seconds worth of video exceeds 9800kbps, will not the buffer underflow as the DVD drive will not be able to read the data fast enough?

3) Buffer underflows may be spec compliant (Although I'm not sure of this, that makes no sense to me why they'd allow such things (?)), but they must be highly undesirable if it causes the decoder to repeat the current frame instead of showing the correct frame. So surely it is better to keep the bitrate under 9800kbps ?

I may, of course, be completely wrong, but that is the way I've interpreted things. But please correct me if I'm wrong, especially if you can back it up with documents/proof (although I know that will be hard as the DVD specs aren't widely available)

Cheers and keep the tone as civilised as possible please, I'd hate to have to close this thread,

-Nic

[dragongodz]

since you ask Nic then i provide this
http://www.mpeg.org/MPEG/DVD/Book_B/Video.html

the relevant parts from that are...
DVD adds many additional restrictions to the popular compliance parameter sets of MPEG. One good example is the restriction on the coded size of a picture: MPEG-2 Main Profile @ Main Level allows any coded frame size between 16 and 720 pixels horizontally and 16 and 576 pixels vertically. DVD, however, restricts the coded frame sizes to a very limited but practical subset.
MPEG is a generic representation meant for a wide variety of applications. DVD has taken a practical subset to promote interoperability by simplifying implementations and insuring features (such as random accessibility).
dvd is a restricted subset of MP@ML, they are not the same.

The maximum bitrate of 9.8 Mbit/sec is more restrictive than MP@ML's 15 Mbit/sec limit.
ALL DVD PLAYERS MUST SUSTAIN A 9.8 MBIT/SEC VIDEO DECODE RATE!!!!!!! Hardwired (Application Specific Integrated Circuits---ASICs) implementations of MPEG-2 MP@ML decoders are generally capable of handling 15 mbit/sec sustained rates.
the max bitrate for dvd(decoding aswell as reading) is 9800Kb/s. so if thats what you set the max bitrate in a program that is what it should be restricted to(MaxKb/s).

when asked i HAVE said that many times. people should read back through this thread and the QuEnc thread if they doubt i have said these things about implamenting rate control. i try to help people all the time, but i do not appreciate people asserting that i am a fool or arrogant and have not tried to help them when i have. i have been very patient about them questioning what i do or do not know. especially when they then claim only they know the truth and then expect me to apologise.

sorry but my patience has run out with this. believe me and that page from mpeg.org or not, people can make their own minds up. i dont intend to keep banging my head against a brick wall and be insulted for it.

[hank315]

Still have a question about the max. DVD bitrate of 9.8 Mbit/s.
Is it so that the sum of the last 25 or 29.97 frames must be less than 9.8 Mbit or is another time frame used to calculate the max. bitrate.
Or, simply put, how many frames do you need to correctly calculate the bitrate of a stream?

[mean]

You can compute an average bitrate using 1/2 sec before & after the current point but you'll only get a approximation of the real thing,
i.e. the vbv buffer fullness.

I tried that some months ago, but it does not it prevent underflow completly.

@Peter :

Did you improve the frame eviction method from vbv_buffer ?
Especially for interlaced encoding ?

My wish list would be a 2 pass engine for lavcodec separated from lavcodec itself.
It is not too hard to do (did it, reusing some ideas of you like the compressibility stuff, but it is very basic) .

The main advantage would be that it can co-exist with lavcodec and be used by most applications that are lavcodec based (mplayer, transcode and al) while keeping the existing lavcodec ratecontrol that works well for mpeg4 with almost no constraint.

As a bonus, you'd be relatively immune to lavcodec internal change.


You code as of today is *very* interesting, but using it in most general purpose application would more or less mean dropping 2 pass for mpeg4
(and merging with lavcodec changes can be tiedous)


I believe you mainly need Qp, frame type and frame size as information for both passes and that can be get/set externally from lavcodec.

Correct me if i'm wrong.

[Peter Cheat]

Originally posted by Nic
Lets try and keep things friendly guys :) No need to get upset over interpretations of a specification...

The way I interpret things is as follows;

1) The MPEG-2 Spec is really the superset of the DVD spec, the DVD spec is a restricted subset of the MPEG-2 spec. Therefore an MP@ML stream != a compliant DVD Stream (although of course the two have a lot of similarities)

2) As far as I can see, a DVD Player only needs to be able to read a maximum of 9800kbps. If the bitrate for a seconds worth of video exceeds 9800kbps, will not the buffer underflow as the DVD drive will not be able to read the data fast enough?

3) Buffer underflows may be spec compliant (Although I'm not sure of this, that makes no sense to me why they'd allow such things (?)), but they must be highly undesirable if it causes the decoder to repeat the current frame instead of showing the correct frame. So surely it is better to keep the bitrate under 9800kbps ?

Lets say 1 second (25 frames) of video in VBR goes up to 11Mbits/s.
Assume the buffer starts full at 224KB=1792kbits.
(just say each frame is 440kbits for simplicity)
Frame 1=440kbits Buffer goes down to 1352kbits, but the data is read at 9800kbit/s=392kbits so the buffer holds 1744kbits. No underflow.
Frame 2=...buffer has 1696kbits
Frame 3=...buffer has 1648kbits
...
Frame 25=...buffer has 592bits (but may have gone down to 152kbits)
but no underflow occured, therefore will playback fine. That assumes a progressive film, and that the next frame will not cause underflow (if it is >592kbits it will). Thats the maths taken care of. (From the MPEG-2 draft, or any open source mpeg-2 encoder.)

The buffer allows for frames to exceed that maximum bitrate, thats what its for. It says so in the draft (its for big frames). Without a buffer, DVD decoder would continuosly stutter because frames are not in the right order in a bitstream. They have to be put onto the buffer, put in the right order and decoded. P frames rely on I frames, B frames rely in P frames (and I frames?).

9800kbit/s refers to the bitrate the DVD is read at. A DVD is read at 10.8Mbits (from memory). In the case of DVD video, 9.8Mbit/s was assigned for video and 1 Mbit/s for audio.

The restriction added to MP@ML is:
9800kbit/s maximum bitrate <- check it the draft as what this means. It was reduced from 15Mbits/s cause 1x DVD is only 9800kbits/s.

The VBV buffer size is the same 112 buffer size or 224KB.

I have put the link for the draft, and the pages that are relevant to maximum bitrate and VBV buffer (page 170 i think). I do recommend reading it, as it explains the context of maximum bitrate. Please read it.

I've read heaps of material, and I've pointed to the most important information. Just read what maximum bitrate means. It says exactly what it is in the MPEG-2 specs. The proof is here (http://www.ee.columbia.edu/~eleft/e6880-Spring98/docs/is138182.pdf). Pages 170-175. Thats the proof.

MPEG-2 is a SUB-SET of DVD. Audio is another sub-set the format is another sub-set. These sub-sets make a full set accepted as DVD video. The fact that a sub-set has some restrictions doesn't change it from being a sub-set.

@mean
I am working on a better VBV model (to consider interlacing/telecined content). MPEG-4 works very well with the last update (try it yourself, but you'll have to compile from source). My method looks at the future 10 frames and their predicted size and removes them from the buffer while adding the required datarate. If the mock buffer underflows, the quant increases by one, it is then checked again. This is why the encode is a little slower. This reduces buffer underflows completely, (for the model I am using) provided the prediction is good. Hence why I improved the prediction. The alternative is to pretend you have say half a buffer, then if it goes over, no problem, the real buffer is twice as big. My code checks for underflows twice. It should stop them 99% of the time.

Originally posted by dragongodz
the max bitrate for dvd(decoding aswell as reading) is 9800Kb/s. so if thats what you set the max bitrate in a program that is what it should be restricted to(MaxKb/s).
It is not a decoding limit. It is a reading limit. See the aforementioned document. It is in there. If they wanted to restrict the decoding limit, why do you need a buffer (well for decoder lag) but why do you need such a big buffer. From the document "for a big frame" where big frame = I frame.

and again "ALL DVD PLAYERS MUST SUSTAIN A 9.8 MBIT/SEC VIDEO DECODE RATE!!!!!!!" = CBR, I've explained this one before.

From Page 49 of the MPEG-2 Stardard draft
(refferring to the bitrate written in the stream)
bit_rate - This is a 30-bit integer. The lower 18 bits of the integer are in bit_rate_value and the upper 12 bits are in bit_rate_extension. bit_rate is measured in units of 400 bits/second, rounded upwards. The value zero is forbidden. The bitrate specified bounds the maximum rate of operation of the VBV as defined in C.3 of annex C. The VBV operates in one of two modes depending on the coded values in vbv_delay. In all cases (both constant and variable bitrate operation) <b>the bitrate specified shall be the upper bound of the rate at which the coded data is supplied to the input of the VBV<b>.
NOTE - Since constant bitrate operation is simply a special case of variable bitrate operation there is
no requirement that the value of bit_rate is the actual bitrate at which the data is supplied. However it is recommended in the case of constant bitrate operation that bit_rate should represent the actual bitrate.

The maximum bitrate refers to the maximum bitrate going into the VBV buffer, NOT THE DECODED STREAM, not the maximum bitrate of the decoded stream! The bitrate specified in the stream is not necessarily the average bitrate, it is the maximum bitrate. In the case of CBR min=average=max. In the case of VBR, the maximum bitrate is the bitrate required to decode the stream without underflow. Not the maximum bitrate of the decoded stream. This applies to all MPEG-2 applications. Its just what maximum bitrate means in MPEG-2. MPEG-1 is the same, but VCDs are CBR, so bitrate in and out is roughly the same but it still applies.

I'm not trying to have a go at anyone, I didn't know this either. I wanted to know, found the right answer and I am telling all of you. Saying that this is all rubbish (@dragongodz:rolleyes: ) is simply not true. It seems no matter what information I provide, I am wrong. Why? Because I have only been encoding for hardware players for two years? I assure you the information I am providing is 100% correct. I spent 6 hours reading the whole document. It is boring. But I did it.

[dragongodz]

your biggest mistake is thinking that draft is dvd specs. it is not. mpeg2 specs encompass much more than dvd. dvd uses 1 subset of mpeg2 and adds its own tighter restrictions.

and again "ALL DVD PLAYERS MUST SUSTAIN A 9.8 MBIT/SEC VIDEO DECODE RATE!!!!!!!" = CBR, I've explained this one before.
and i disagree as i did before. a VBR stream can have a 9.8 Mb/sec section for more than 1 second. that does not make it suddenly a CBR stream. however if it exceeds the 9.8Mb/sec for over a second it will underflow and cause playback issues and be out of spec.

It is not a decoding limit. It is a reading limit. See the aforementioned document. It is in there. If they wanted to restrict the decoding limit, why do you need a buffer (well for decoder lag) but why do you need such a big buffer. From the document "for a big frame" where big frame = I frame.
note i said max bitrate per second and not per frame. so your arguement about a "big frame" in no way makes the per second limit different.

I wanted to know, found the right answer and I am telling all of you. Saying that this is all rubbish (@dragongodz ) is simply not true
and i say you did not get it right. you mistook MP@ML as being dvd specs when they are not exactly the same. in your last post you finally even show 1 of the restrictions added to MP@ML for dvd specs even though in earlier posts you quite happily say
This is the ABSOLUTE MAXIMUM BITRATE for MPEG-2 to be MP@ML compliant and hence DVD compliant.
you say reading only while i say both reading and decoding. infact tell me why you would have a max bitrate setting in an encoder if it is not to be adhered to.
and lets get it staight, when i said rubbish i was refering to you constantly questioning whether i know even the basics of video encoding/decoding. i even quoted it right before it so everyone could tell what i was refering to. do not try and make it seem like i was talking about anything else. your posts on what you think is max bitrate etc i have simply disagreed with.

It seems no matter what information I provide, I am wrong. Why? Because I have only been encoding for hardware players for two years? I assure you the information I am providing is 100% correct.
so someone disagrees with you and even provides proof of their own(including experiences people are actually having and 1 of your own quotes(the svcd one)) but that doesnt mean you could be wrong ?
as for saying how long you have been encoding, thats irrelevant. there are people on this forum who have been encoding for years who do not even know what VBV stands for let alone what its used for. do you really think i would be posting back and forth to you like this if i thought you were an idiot ? its YOU that has several times questioned my knowledge on basics. now whys that ?

since you were willing to spend all that time reading that document you should not mind reading this 1 little page aswell.
http://www.mpeg.org/MPEG/DVD/Book_B/Video.html
i would think mpeg.org would have some idea what they are talking about.

[johnnyquid]

Just my two cents worth. Be gentle ;)

From a practical standpoint it would seem to me that arguing over this is pointless. Since output stream bitrates over 9.8 MB/sec (or even lower) do not improve the final picture quality much it would seem to me that a good VBR rate control would not waste bits creating them. Doing so would also get rid of users always asking why bitrate viewer (or other tool) is showing something that they think (rightly or wrongly, I do not want to take a side here) is not DVD compliant. Other programs/hardware may also assume the output bitrate will not exceed 9.8 MB/sec so not doing so may improve compatability.

[Peter Cheat]

Originally posted by johnnyquid
Just my two cents worth. Be gentle ;)

From a practical standpoint it would seem to me that arguing over this is pointless. Since output stream bitrates over 9.8 MB/sec (or even lower) do not improve the final picture quality much it would seem to me that a good VBR rate control would not waste bits creating them. Doing so would also get rid of users always asking why bitrate viewer (or other tool) is showing something that they think (rightly or wrongly, I do not want to take a side here) is not DVD compliant. Other programs/hardware may also assume the output bitrate will not exceed 9.8 MB/sec so not doing so may improve compatability.

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant. A restriction on the input bitrate was decreased for DVD to 9800kbit/s. If a buffer underflow occurs, the previous frame is repeated. If MPEG-2 standards expect this to occur, and there is no mention of the change in the DVD specs, then it will be the same as MPEG-2.

[dragongodz]

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant.
can you show any documents that say that ?

A restriction on the input bitrate was decreased for DVD to 9800kbit/s
it is also the only limit mentioned for decoding as also already said ad-infinitum. nowhere does specific to dvd docs(meaning not general mpeg) say max 9800 for CBR but can be higher for VBR. again, show me a document that does.

If a buffer underflow occurs, the previous frame is repeated. If MPEG-2 standards expect this to occur, and there is no mention of the change in the DVD specs, then it will be the same as MPEG-2.
which will cause non-smooth playback. so even if it is handled it is not desirable in any way.

[hank315]

Some more remarks about 9800 kbit/s, DVD read speed and VBV buffer underflow....


posted by Peter Cheat:
Lets say 1 second (25 frames) of video in VBR goes up to 11Mbits/s.
Assume the buffer starts full at 224KB=1792kbits.
(just say each frame is 440kbits for simplicity)
Frame 1=440kbits Buffer goes down to 1352kbits, but the data is read at 9800kbit/s=392kbits so the buffer holds 1744kbits. No underflow.
Frame 2=...buffer has 1696kbits
Frame 3=...buffer has 1648kbits
...
Frame 25=...buffer has 592bits (but may have gone down to 152kbits)
but no underflow occured, therefore will playback fine. That assumes a progressive film, and that the next frame will not cause underflow (if it is >592kbits it will). Thats the maths taken care of. (From the MPEG-2 draft, or any open source mpeg-2 encoder.)

But suppose we have a constant bitstream with frames of 200 kbits, 12 frames of 592 kbits and again a constant bitstream of 200 kbit frames.
The maths of this show a constant bitstream of 5000 kbit/s and 9704 kbit/s during the time of the 12 592 kbits frames if the average bitrate value is calculated every second.
This is below the "magic" 9800 kbit/s so it seems ok.

Assume we have a full VBV buffer at the start of the 12 'large' 592 kbits frames, from this point the buffer will be emptied with 592 kbits per frame and will be filled with the maximum read speed of 392 kbits per frame so after approx. 9 frames the VBV buffer will be empty, underflow will occur and previous frames will be repeated.

This shows a bitstream which would show "DVD compliant" (regarding bitstream) in programs like BitRate Viewer could cause serious buffer underflow, these programs are only applicable for bitstreams which are CBR or "mild" VBR.
For VBR where V is really *very* variable the only way to prevent buffer underflow is to simulate the behaviour of the VBV and correct the bitstream for underflow.

[Peter Cheat]

Originally posted by hank315
Some more remarks about 9800 kbit/s, DVD read speed and VBV buffer underflow....


But suppose we have a constant bitstream with frames of 200 kbits, 12 frames of 592 kbits and again a constant bitstream of 200 kbit frames.
The maths of this show a constant bitstream of 5000 kbit/s and 9704 kbit/s during the time of the 12 592 kbits frames if the average bitrate value is calculated every second.
This is below the "magic" 9800 kbit/s so it seems ok.

Assume we have a full VBV buffer at the start of the 12 'large' 592 kbits frames, from this point the buffer will be emptied with 592 kbits per frame and will be filled with the maximum read speed of 392 kbits per frame so after approx. 9 frames the VBV buffer will be empty, underflow will occur and previous frames will be repeated.

This shows a bitstream which would show "DVD compliant" (regarding bitstream) in programs like BitRate Viewer could cause serious buffer underflow, these programs are only applicable for bitstreams which are CBR or "mild" VBR.
For VBR where V is really *very* variable the only way to prevent buffer underflow is to simulate the behaviour of the VBV and correct the bitstream for underflow.

Your example is spot on. Bitrate Viewer cant tell you if your stream will have problems the way it is implemented.

Simulating a VBV and looking for potential buffer underflows is really the only way to stop underflows correctly. This is what I've tried to implement. As long as the predictor is accurate, no underflows will occur, provided the model used is accurate. However, currently it is not. It is accurate for MPEG-1, but not MPEG-2 interlaced/3:2 Pulldown. I am working on a better model.

[Peter Cheat]

Originally posted by dragongodz
can you show any documents that say that ?


it is also the only limit mentioned for decoding as also already said ad-infinitum. nowhere does specific to dvd docs(meaning not general mpeg) say max 9800 for CBR but can be higher for VBR. again, show me a document that does.


which will cause non-smooth playback. so even if it is handled it is not desirable in any way.

Looking at it in pseudo code:

MP@ML Standard {
max_bitrate = 15000000 bits
VBV_buffer_size = 1835008 bits
max_gop_size = INFINITE
low_delay = can be 0 or 1, 1 (indicates no buffer delay, ie no B's)
aspect_ratio = one of (1:1, 4:3, 16:9, 2.21:1 and some reserved?)
frame_rate = one of (23.976, 24, 25, 29.97, 30, 50, 59.94, 60 and reserved?))

//probably other relevant restrictions I've missed (resolutions)
}

DVD Standard {
import MP@ML Standard
import DVD Audio Standard
import Disc Format Standard

MP@M->max_bitrate = 9800000 bits
MP@ML->max_gop_size = if PAL 15 otherwise 18
MP@ML->low.delay = 0 //must be zero by DVD specs
MP@ML->aspect_ratio = 4:3 or 16:9 only!
MP@ML->frame_rate = 29.97 or 25 only!

//any other differences not mentioned
//any changes from other standards
}

The maximum bitrate still has the same definition as the MPEG-2 standard. The bitrate of the decoded stream is not limited to 9800kbit/s, it is limited by 9800kbit/s. These both mean something completely different (isn't english a funny language). If you have a 9,800,001bit/s CBR stream, it will play correctly in EVERY COMPLIANT DVD PLAYER for 1835008 frames, or 73400.32 seconds (@25fps), which is over 20 hours. A DVD player must be able to play 9800kbit/s NON-STOP FOREVER (for an indefinite amount of time).

When you consider VBR, the bitrate is no longer 9800kbit/s constantly, but changing. When the bitrate is below 9800kbit/s (say 4000kbit/s), the buffer can be filled up (at 5800kbit/s until full). When the bitrate exceeds 9800kbit/s (say 11,000kbit/s) the buffer is drained (at 1,200kbit/s). This is ok, as long as the buffer isn't drained until it is empty. If it is emptied, the decoder cannot get the next frame, as it is not on the buffer, and the last frame is displayed until the next frame is available.

For VBR, you can't possibly have an average bitrate over 9800kbit/s and have it play indefinitely. But you can easily have an average bitrate of 9800kbit/s. Thats the limitation. It's actually the average bitrate of the stream that is limited by 9800kbit/s, not really the maximum bitrate. However, the maximum instantaneous bitrate of the stream can be up to 1835008bits without underflow (the size of the buffer, assuming no b-frame lag).

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant. The MP@ML standard requires the last frame to be repeated until the next frame is ready on the buffer. Because it must be able to handle such an undesirable situation, DVD players are able to handle a stream greater than 9.8Mbit/s on input without crashing or freezing. The DVD standard does not mention anything about changing the way it is handled, thefore it is safe to assume it is handled the same way. If the MPEG-2 standard say something, and the DVD standard uses this same standard with some minor changes you can (correctly) assume that what applies in MPEG-2 applies for DVD unless otherwise specified.

The changes/differences are nicely said here (http://www.mpeg.org/MPEG/DVD/Book_B/Video.html).

I am not asking you to change your religion or tell you that aliens exist. I'm just showing you documents with facts. I was reffered to the MPEG-2 draft when looking for the DVD standard. It has all the information required.


Still have a question about the max. DVD bitrate of 9.8 Mbit/s.
Is it so that the sum of the last 25 or 29.97 frames must be less than 9.8 Mbit or is another time frame used to calculate the max. bitrate.
Or, simply put, how many frames do you need to correctly calculate the bitrate of a stream?

It is the average over the whole stream. Not over a second or GOP.

@dragongodz
If you still aren't convinced that the maximum bitrate is a limitation of data rate to the VBV buffer only and not the decoded stream, send an email to mpeg.org stating you are a student doing an assignment and you aren't sure. They will probably tell you.

[dragongodz]

hank315 - the point trying to be made(atleast by me) is that neither max bitrate or VBV alone should be considered. all factors must work together and to ignore any one can cause problems later.

The maximum bitrate still has the same definition as the MPEG-2 standard.
no it does not. you even show right above where it is changed to 9800Kb/s for dvd. MP@ML's limit is 15Mb/s.

The bitrate of the decoded stream is not limited to 9800kbit/s, it is limited by 9800kbit/s. These both mean something completely different (isn't english a funny language).
or to put it another way, it is limited to 9800Kb/s because the max delivery speed(meaning dvd read speed) is 9800Kb/s. so it is limited to A by B. no english is not really that funny its just sometimes people try to be.

For VBR, you can't possibly have an average bitrate over 9800kbit/s and have it play indefinitely
Thats the limitation. It's actually the average bitrate of the stream that is limited by 9800kbit/s, not really the maximum bitrate
so lets say we have 30 seconds of no motion footage and then 15 seconds of high motion. the average bitrate can easily be under the 9800Kb/s but i wonder how that last 15 seconds will play if it that part is allowed to exceed that.

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant. The MP@ML standard requires the last frame to be repeated until the next frame is ready on the buffer. Because it must be able to handle such an undesirable situation, DVD players are able to handle a stream greater than 9.8Mbit/s on input without crashing or freezing.
even if you were right it is totally undesirable so why not avoid it to start with. i also never said crash or freeze, i said unsmooth playback.

the maximum instantaneous bitrate of the stream can be up to 1835008bits without underflow
well
By allowing for bursts of up to 10 megabits per second, the DVD specification takes into account the need for short bursts in the data rate to accommodate complex scenes
is from http://www.creativevideo.co.uk/reframe.php?url=http://www.creativevideo.co.uk/pages/cvp_info_mpeg2_dvd.htm
and
If DVD compliant is selected, instantaneous bitrate in GOP units is controlled to be a maximum of 9.8 Mbps
from http://www.cinemacraft.com/files/doc/ccl_264e.pdf

I'm just showing you documents with facts. I was reffered to the MPEG-2 draft when looking for the DVD standard. It has all the information required.
hmm and what i have i been doing then ????
also the mpeg-2 draft does NOT have all the information required. proof ?
The changes/differences are nicely said here.
hmm wasnt it me that posted that link for you to read.....twice ?

well i have provided plenty of documentation and quotes etc. its up to you what you do with it and what you want to believe. do as you will because if all i have already given you isnt enough then nothing will be.

oh and i would still like to know what you think the max bitrate setting in encoders is for if not to limit the max bitrate per second explicitly.

[Peter Cheat]

The maximum bitrate definition is the same for DVD as MPEG-2. (Do you know what definition means?). The value may have changed, but it still means the same thing as in MPEG-2. They didn't suddenly change it from meaning the input data rate to the output datarate.


so lets say we have 30 seconds of no motion footage and then 15 seconds of high motion. the average bitrate can easily be under the 9800Kb/s but i wonder how that last 15 seconds will play if it that part is allowed to exceed that.


It will play fine provided no buffer underflow. A huge spike for the full 15 seconds would cause underflow, but the last 15 seconds can average around 9804kbits without to much concern.

CCE documents are not fact, they just explain how CCE works/what it does. It doesn't make it right. I did reuse your link, as it just backed up everything I said 100% (BOOK B DVD Video Specs overview).


oh and i would still like to know what you think the max bitrate setting in encoders is for if not to limit the max bitrate per second explicitly.

You can't model the VBV without specifying a maximum bitrate. You need to know the maximum bitrate at which the buffer can be filled. Funnily, you can't change the VBV buffer size in CCE. But you need to have a VBV buffer size if you specify a maximum bitrate, and you need a maximum bitrate if you specify a vbv buffer size. I can show you the code for FFMPEG and mpeg2enc, both of which only make reference to maximum bitrate with the VBV buffer.

[dragongodz]

They didn't suddenly change it from meaning the input data rate
have you been reading what i have typed at all ? i have constantly said the input max bitrate per second is the max bitrate. you have stated it doesnt matter if it goes above.

A huge spike for the full 15 seconds would cause underflow, but the last 15 seconds can average around 9804kbits without to much concern.
yes it would cause underflow. however if the max bitrate limited by the max media speed aswell as VBV is handled by the rate control then it shouldnt.

CCE documents are not fact, they just explain how CCE works/what it does. It doesn't make it right.
no but i suspect a big commercial company that has been making a quality encoder for years does have the dvd specs and may just have some idea what its talking about. at least better than you or i. :D

I did reuse your link, as it just backed up everything I said 100% (BOOK B DVD Video Specs overview).
well you asked for documentation to show that the mpeg draft wasnt dvd specs and i provided it. none of that information on limitations for dvd is in the draft, period. as for backing up what you said, well thats your interpretation while i disagree. i doubt either of us is going to change our minds so i wont bother to try anymore.

You can't model the VBV without specifying a maximum bitrate. You need to know the maximum bitrate at which the buffer can be filled.
again i have said many many times they need to be handled together and you have constantly said VBV is all that really matters.
ignore the debate over dvd for a moment. when someone enters a max bitrate in an encoder they expect it to be the max bitrate used. whether you say it is really important or not doesnt matter, that is what is expected ,and i dont mean just by newbies, and should be used.

Do you know what definition means?
hmm do you know what "ask me a question like that as if i am stupid again and i will tell you exactly what kind of person i think you are" means ? if you dont know how to talk to someone who has a different opinion than you without insulting them repeatidly then its a good idea to say as little as possible.

[Nic]

Thanks for your reply Peter.

I think it's best to say now that the argument side of things is closed, because I think it's getting a tad heated and I think everyone has made their points.

But one last question from me (if that's ok):


Lets say 1 second (25 frames) of video in VBR goes up to 11Mbits/s.
Assume the buffer starts full at 224KB=1792kbits.
(just say each frame is 440kbits for simplicity)
Frame 1=440kbits Buffer goes down to 1352kbits, but the data is read at 9800kbit/s=392kbits so the buffer holds 1744kbits. No underflow.
Frame 2=...buffer has 1696kbits
Frame 3=...buffer has 1648kbits
...
Frame 25=...buffer has 592bits (but may have gone down to 152kbits)
but no underflow occured, therefore will playback fine. That assumes a progressive film, and that the next frame will not cause underflow (if it is >592kbits it will). Thats the maths taken care of. (From the MPEG-2 draft, or any open source mpeg-2 encoder.)


What if the buffer started at, say, quarter full? (around 448kbits) then it would soon underflow. Does the VBV model (or at least the code you use) stop that from ever happening?

I will re-read the pages (i've read the doc before from start to finish (a while ago now) but wasn't focusing on bitrate), and maybe the answer is there. (For people following this discussion it's annex C of ISO 13818-2 (pg 182 in the PDF Peter linked to)

Cheers and Thanks,
-Nic

ps
Do you also agree, that underflow, although accounted for in the spec, is highly undesirable for those doing DVD backups?

pps
It actually appears that underflow is definitely not part of the spec if low_delay = 0 (which it is in the DVD spec). So we can't have underflow it appears (from reading C.8)...do you concur?

[Peter Cheat]

Originally posted by Nic
Thanks for your reply Peter.

I think it's best to say now that the argument side of things is closed, because I think it's getting a tad heated and I think everyone has made their points.

But one last question from me (if that's ok):

What if the buffer started at, say, quarter full? (around 448kbits) then it would soon underflow. Does the VBV model (or at least the code you use) stop that from ever happening?

I will re-read the pages (i've read the doc before from start to finish (a while ago now) but wasn't focusing on bitrate), and maybe the answer is there. (For people following this discussion it's annex C of ISO 13818-2 (pg 182 in the PDF Peter linked to)

Cheers and Thanks,
-Nic



RateControlContext *rcc= &s->rc_context;
const int buffer_size = s->avctx->rc_buffer_size;
const int qmin = s->avctx >lmin;
int unused_buffer;
int look_ahead = 10; // number of frames to look ahead

/* Look for buffer underflow in future second and prevent it */
if (buffer_size && frame_number < (rcc->num_entries - look_ahead)) {
int predicted_buffer = rcc->buffer_index; // Set the predicted buffer to the same value as data in the buffer
int frame_bits;
int i=0;

do {
RateControlEntry *rce = &rcc->entry[frame_number + i]; // Get statistics for this frame
frame_bits = qp2bits(rce, rce->new_qscale, compressibility[rce->pict_type]);
frame_bits = FFMAX(frame_bits, min_rate);

if ((predicted_buffer < frame_bits)&&(rce->new_qscale < qmax)) {
/* Pending underflow detected, so increase quant */
for (i=i; i>-1; i--) { // nasty loop
RateControlEntry *rcp = &rcc->entry[frame_number + i];
rcp->new_qscale += FF_QP2LAMBDA; // increase quant
predicted_buffer = rcc->buffer_index; // reset predicted buffer
}
} else {
predicted_buffer -= frame_bits;
unused_buffer = buffer_size - predicted_buffer - 1;
predicted_buffer += clip(unused_buffer, min_rate, max_rate); // refill buffer
}
i++;
} while (i < look_ahead);
}


This code is executed BEFORE encoding every single frame. It takes the value currently in the buffer, and checks if the next frames cause underflow. If they do, the quant is increased by one until it no longer does. Looking ahead 10 frames slows down encoding a bit, but it pretty much guarantees no underflow. To get this to work properly, I had to change the way rescaling of quants was done to keep the filesize. To answer your quenstion, yes.

Originally posted by Nic

ps
Do you also agree, that underflow, although accounted for in the spec, is highly undesirable for those doing DVD backups?


If it wasn't, I wouldn't have spent so much time writing code to stop it.

Originally posted by Nic

pps
It actually appears that underflow is definitely not part of the spec if low_delay = 0 (which it is in the DVD spec). So we can't have underflow it appears (from reading C.8)...do you concur?

Oops, I mixed up low_delay 0 and 1. You're right, DVD players are not required to handle underflows at all. But I have made every effort to try and stop them.

[Nic]

Hi Peter,

Looking at your code, is it not perhaps a bad idea to use 'i' twice in that loop ?
(to show what I mean i'll cut the code i'm referring to below:)


do {

if ((predicted_buffer < frame_bits)&&(rce->new_qscale < qmax))
{
for (i=i; i>-1; i--) { // nasty loop
..etc..
}
}

i++;
} while (i < look_ahead);


Won't that make it so if the 'if' statement is true 'i' will be set to 0 (from the 'for' loop) and the 'do...while' loop will have to repeat all over again? (well until 'i' reaches look_ahead anyway). Or is that the intended way it should work?

EDIT: Although it may be intended (as I think it is). It may be not working as you hope, because 'i' will be set to 1 on a reiteration of the loop (because of the 'i++') instead of 0 if the 'if' statement is true. Hope that makes sense and/or helps.

-Nic

[Peter Cheat]

I believe that i=-1 after completing the for loop (do while >-1), adding 1 will make it zero as required. No problem there. I know this is horrible code, thats why I don't want to submit it to cvs yet.

[Nic]

Oh, yes, very true. :)

Well, keep it up. What's the current status and how do you feel the quality is compared to the original libavcodec code?

-Nic

[Peter Cheat]

Doing a quick comparison, the quality appears to be the same (well, this is expected when using the same rate control equation). I'll post results of a comparison. The advantage is that I can't make NuEnc underflow yet on passes >=2 (in 1st pass of X pass buffer is ignored to increase encode speed). 1 pass encoding is unchanged. The code seems stable, and still can be tweaked using 3 parameters (not available to be tweaked externally yet). They include improvement/degradation factor which is set to 10%, rescale period which is set to 300 frames (every 300 frames the next 300 frames are scaled) and if the filesize becomes 5% off target at any time, the next 300 frames are rescaled also to compensate. These seem to be good figures for now. If anyone notices quality problems, these can be adjusted accordingly.

I have a sneaking suspicion that while loops are faster than for loops (when I had the external while loop as a for loop, it was running at half the speed). Do you know if this is true Nic?

[dragongodz]

I have a sneaking suspicion that while loops are faster than for loops (when I had the external while loop as a for loop, it was running at half the speed).

http://www.codeguru.com/forum/showthread.php?t=310721

thats Visual C++ but the comparison of disassembled code could be done for GCC aswell. that should give you some idea.

[Peter Cheat]

It should be the same, but I had the impression that the when I changed a for loop to a while loop that it was faster. I'll look at the disassembled code and see if gcc does treat while and for loops differently.

[freelock7]

It would be interesting to add in advanced options some new matrix as the excellent CYDVD.

[Trahald]

Ok.. i reencoded the file with nuenc (this is a file that scenarist would not take when encoded with quenc because bitrate was too high that i mentioned in the quenc thread) .. i used full bitrate max (meaning the video*max* + audio, etc == 9800) and worked like a charm. picture looks great as well.. good work peter (and Nic)

[dragongodz]

freelock7 - you may be interested in reading the QuEnc thread, especially the last page.

Trahald - actually the 9800Kbits/s is video limit, not the total limit. that is 10.08Mbits/s. so you actually set slightly undersize max. :)

good to see someone testing and posting results though.

[Trahald]

@dg - yeah.. sorry... we use the 9800 as a target to leave a buffer.. sometimes even cce spikes.

[Peter Cheat]

Originally posted by Trahald
Ok.. i reencoded the file with nuenc (this is a file that scenarist would not take when encoded with quenc because bitrate was too high that i mentioned in the quenc thread) .. i used full bitrate max (meaning the video*max* + audio, etc == 9800) and worked like a charm. picture looks great as well.. good work peter (and Nic)

Great, its good to see that NuEnc created a stream that scenarist accepted. Perhaps buffer underflows were the problem in this case, because I have not included code to stop the decoded stream from exceeding maximum bitrate.

@freelock7
When/if QuEnc has this feature, I will include it into NuEnc. Currently, I have no time to make any big changes (exam time!), but I will get back onto it after exams. I have got a small update coming up, which improves quality a little for encodes at all bitrates.

At the moment, my tests show that my modifications have notreduced the quality at all, and using the right settings, you can get better results than with original libavcodec (not much though).

[dragongodz]

we use the 9800 as a target to leave a buffer.. sometimes even cce spikes.
yes we have "discussed" that very fact around here before. :)

Perhaps buffer underflows were the problem in this case, because I have not included code to stop the decoded stream from exceeding maximum bitrate.
though the prevention of undeflows does also reduce frames sizes reducing the amount of spiking maybe ?

[Peter Cheat]

Sort of true, it does reduce frame sizes where an underflow would occur, but spikes occur more frequently then in the original libavcodec code. The reason is that libavcodec originally *tried* to make frames no bigger than 1/3 of the buffer to prevent underflow. This would have worked if the prediction was more accurate. I changed it so a frame can consume as much as the buffer as it wanted (so I frames could have a lower quant in high action scenes), as long as there was enough bits for the next frames to remain at a relatively constant quant. Hence, high action scenes look better, you shouldn't get underflows, but spikes can be huge, usually caused by I frames that are close together.

TMPEnc causes underflow on occasion. Older versions of TMPGEnc used to stop encoding if too many underflows occured. It may still, I haven't really tried the latest version.

I agree, it would be interesting to see what happens if the full bandwidth was used. It should also be ok, but no guarantees :)

[Trahald]

Next project rcvd an underflow with nuenc.

Error Video or Audio Buffer underflow: (Dts: 156781857, SCR 156781886)
Error Total bitrate is too HIGH. Please reduce the stream bitrate or the number of stream.

i removed some of the audio streams and it went through ok. I'll report how the next project goes

<edit>
Next project smooth as silk.. scenarist happy with input

[Peter Cheat]

So underflows still can occur on occasion. Its hard to completely prevent. I'm still amazed:confused: how a DVD originally encoded as CBR at 4000kbit/s can spike way over 4000kbit/s when re-encoded. Odd.

[Trahald]

I did another project and compiled fine as well.. i wonder is there something that will check bitrate and vbv compliance and give detailed output...

[hank315]

So underflows still can occur on occasion. Its hard to completely prevent. I'm still amazed how a DVD originally encoded as CBR at 4000kbit/s can spike way over 4000kbit/s when re-encoded. Odd.
Maybe this isn't so odd. With CBR the quantizer can have very low and high spikes to keep the bitrate constant.
When this CBR stuff is re-encoded using VBR an encoder should try to keep the quantizer as low and constant as possible to get the best possible quality so the bitrate can spike (ofcourse within certain limits such as VBV underflow:) )

[dragongodz]

I'm still amazed how a DVD originally encoded as CBR at 4000kbit/s can spike way over 4000kbit/s when re-encoded. Odd.
not really. you have to remember you are dealing with lossy compression. every time you recompress you are losing more detail. so to maintain all the detail from the CBR stream may require a higher bitrate than the original bitrate, effectivly trying to do as little loss as possible. this is very dependant on the original CBR encode and how much detail it has reatined of course.

I changed it so a frame can consume as much as the buffer as it wanted (so I frames could have a lower quant in high action scenes), as long as there was enough bits for the next frames to remain at a relatively constant quant. Hence, high action scenes look better, you shouldn't get underflows, but spikes can be huge, usually caused by I frames that are close together.
when i was looking at this some time ago with the orioginal rate control it was not actually the I frames that were spiking but P frames. I frames were never given enough bits to start with which caused the pulsing people know about. that why i changed that setting in my release and pumped up I frames and reduced B frames. less underflows and spikes but no true fix of course.

[Peter Cheat]

Originally posted by Trahald
I did another project and compiled fine as well.. i wonder is there something that will check bitrate and vbv compliance and give detailed output...

NuEnc reports underflows internally (well, it does roughly). I can implement log file writing if you want that gives detail about bitrate etc.

@hank315 & dragongodz
It does seem strange to spike so high. If originally material was encoded at 4000kbit/s CBR, I wouldn't expect the bitrate to increase over 8000kbit/s. The reason is that detail has been removed during the original encode. The only way the bitrate can go above the original bitrate is due to increased noise, such as block noise or ringing. If you encode material at Q=2, then reencode it again at Q=2, the second time round, the file will be smaller (and lower quality)...I guess it really depends on the encoder, and the decisions it makes.

@dragongodz
The pulsing in original rate control was (probably mostly) caused by the default algorithm tex^0.5 (SQRT(original texture bits) * factor). Large frames get punished, small frames get a bonus. To get around this, negative i_factor and b_factor could be specified, so that the quantiser of I/B frames depends on P frames...(You could also use a very small i_factor and a very large b_factor as you've done). The reason why the tex^0.5 algorithm was used was to try to help prevent underflows by limiting the size of an I frame. I frames, in general are larger than P frames. But it is better to reduce the quality of P frames than I frames, for obvious reasons. Using 'tex' as the rate control algorithm fixes the pulsing issue (or tex^1) giving 'constant quality'. You might want to try giving negative factors instead in QuEnc.

I think another small contributor to pulsing is lack of closed gop with scene detection on. I am working on that now. B frames referencing an I frame after a scene change is pointless and wasteful.

[dragongodz]

If you encode material at Q=2, then reencode it again at Q=2, the second time round, the file will be smaller (and lower quality)
yes but to get the same quality(no detail loss at all) would require a lower quant which would increase size, possibly sometimes past the original size.

I guess it really depends on the encoder, and the decisions it makes.
yes and also the decoder for noise,ringing etc as you mention.

I frames, in general are larger than P frames. But it is better to reduce the quality of P frames than I frames, for obvious reasons.
of course which is what my settings force to happen. result- no more pulsing and less underflows than the default settings. :)

You might want to try giving negative factors instead in QuEnc
yes i did try negatives aswell. didnt really improve anything which is why i used the settings i did. as has been said by many people many times, avcodec rate control just is not that good. which is why so many people are interested in you working on it aswell. :D

I think another small contributor to pulsing is lack of closed gop with scene detection on
not really no. ok that may for that particular case but the general problem of a fixed GOP size having pulsing is seperate.

[Peter Cheat]

Closed GOP will fix pulsing (well its not really pulsing but smeared noise that suddenly disappears) in some cases. Pulsing in general doesn't seem to occur with QuEnc or NuEnc anymore.

Note the new update. It is not a huge update feature-wise, but I have focused on quality improvements. Scene change detection sensitivity was increased to overcome an obscurity in scene detection algorithm (scene detection depends on quantiser!). Other changes as well.

[dragongodz]

cool. hopefully some people will do some testing and report back. i will try to squeeze some in aswell but it wont be extensive.

i do question the point of replacement of QLB by notch matrix but hey whatever. :D

[Peter Cheat]

I liked the QLB matrix but ppl on the KVCD forum obviously needed the precious notch matrix. As long as its tested and any bugs stomped out, I don't think it really matters. Custom matrices will be implemented eventually anyway.

[hank315]

@Peter & dragongodz
Did some testing encoding a video again and again.
Took a 20 sec. clip from a movie and encoded it using a constant quantizer of 2, then encoded the result again using a quantizer of 2 and so on.
The result of this:
run 1: file length: 33259 KB
run 2: file length: 33340 KB
run 3: file length: 33437 KB
run 4: file length: 33550 KB
run 5: file length: 33651 KB

During the tests all conditions are exactly the same.
It shows that after each encode the file is about 0.3% larger, probably due to the introduction of noise at each encode.

[Peter Cheat]

Small increases in size aren't surprising. It's the huge bitrate increases that I find odd (over double).

IMPORTANT NOTE
If you downloaded NuEnc 0.00c before this message was posted, please redownload it. There was a problem with Q=1 and the 'Notch' matrix that I just fixed.

[Trahald]

I have a 112k file that nuenc is choking on.. it seems to do ok with 1 pass mode, but in 2-pass nuencs process bloats up really big (to the point it brings windows to its knees) and refuses to do the next pass. quenc and cce have no problem with the file.

[bergi]

in 2-pass nuencs process bloats up really big (to the point it brings windows to its knees) and refuses to do the next pass

I have the same problem.

NuEnc also refuse to work if i start it with command line parameters. I think it's a P4 problem:

65645915 pmaddwd mm3,mm2
65645919 pmaddwd mm7,mm1
6564591D pmaddwd mm2,mm5
65645921 pmaddwd mm1,mm4
65645925 paddd mm3,mm7
65645929 paddd mm1,mm2
6564592D paddd mm3,mm6
65645931 paddd mm1,mm6
65645935 psrad mm3,11h
6564593A psrad mm1,11h
6564593F packssdw mm1,mm3
65645943 movq mmword ptr [edx],mm1

At position 65645943 an error occured in avcodec.dll.

[dragongodz]

Peter needs to compile the avcodec.dll with --enable-memalign-hack for P4's if he hasnt.

[freelock7]

I encoded the same video with QuEnc0.54(custom matrix) & NuEnc0.0a(QLB matrix).
1) at VBR:4600_1Pass.
2) at VBR:2600_2Pass.
Results:
QuEnc seems to encode with a better bitrate average than NuEnc designed to work in low bitrate settings.
Pixels appears in high motion picture with NuEnc (1Pass) not with QuEnc0.54 .
But in 2Pass setting, NuEnc works better than QuEnc.

[RobertR]

My tests of Peter's patches to ffmpeg/libavcodec have slowed down a lot last few days :(
For some unknown to me reasons when I apply Peter's changes over 0.4.9-pre1 it always segfaults during 2nd pass. When changes are applied over recent CVS there is no such problem (i did 6 passes)
Bitrate distribution seems to be better (at least in ffmpeg-source.zip that was released together with NuEnc 0.00b).

Peter could You please do me a favor and put some 'versioning' on ffmpeg-source.zip ?

Would releasing commandline only version of NuEnc be a big problem? My programming skills are quite rusty and trying to make my way throu windows gui bloat (no offense) is getting on my nerves a lot. :D

Peter thanks a lot for what you've done so far :)

[dragongodz]

Pixels appears in high motion picture with NuEnc (1Pass) not with QuEnc0.54 .
from memory NuEnc is using old rate control for 1 pass encoding so it would be the internal settings used that are the difference.

throu windows gui bloat (no offense) is getting on my nerves a lot.
please dont be a richard felker. :eek: :D

[RobertR]

Originally posted by dragongodz
please dont be a richard felker. :eek: :D

quite nice flame-thread on ffmpeg ml :D
I don't quite understand Richard Felker point of view. I don't like windows but that's my opinion and only my opinion. I'm biased tho cause i've been using linux/unix much much longer than i'm using windows. I just have real trouble following windows source code... I'm sysadm not a programmer :) I have 2 apps that were written for Windows and i'd like to port them to Linux environment (call me crazy ;) ) so that i can make dvd backup w/o windows at all.

[bergi]

@Peter

Can you make a build with --enable-memalign-hack, please? Or upload your complete source code, so i can try myself to make a working p4 build. The latest CVS doesn't compile with your patch and with 0.4.9-pre1 the 2pass doesn't work.

Peter thanks a lot for what you've done so far!

[dragongodz]

quite nice flame-thread on ffmpeg ml
elitist B.S. you mean. :)

I don't quite understand Richard Felker point of view. I don't like windows but that's my opinion and only my opinion.
even quite a few of us that use windows dont like things about it, theres nothing wrong with that.
however richards view is windows is bloated crap, visual studio is bloated crap, infact using an ide for programming is for dummies, c++ is crap (C is god apparently), gui's are bloated crap(even for linux, command line rules), you should be able to write huge amounts of code error free minus a few typo's.....else your crap, any closed source program is crap, and on and on and on. so whats so hard to understand ? elitist wank. :D
he even now has a couple of followers who claim gui's are for people too lazy to learn and slow down using a program. people like that who want to live in the dark ages(even linux has guis for gods sake) should go live in a cave in my opinion and let the rest of us move forward. :mad:

I have 2 apps that were written for Windows and i'd like to port them to Linux environment (call me crazy ;) )
your crazy. :D
just kidding. why not, windows programmers have been using linux source for ages so why not the other way aswell ? i wish you luck.

[Peter Cheat]

Ok, firstly I have to say that I AM WORKING OFF THE LATEST CVS
I have said this before. The latest CVS has changed since the pre1 and the files affected includes the files I have changed. Use latest CVS.


I have a 112k file that nuenc is choking on.. it seems to do ok with 1 pass mode, but in 2-pass nuencs process bloats up really big (to the point it brings windows to its knees) and refuses to do the next pass. quenc and cce have no problem with the file.


Seems like the rate control is getting caught up in an infinite loop. How many frames are in file? I have a feeling that less than 10 frames might be a problem.


Pixels appears in high motion picture with NuEnc (1Pass) not with QuEnc0.54 .


As dragongodz has stated, I haven't altered any 1pass code directly. I actually haven't tested 1pass, I may have even broken it indirectly. It should be ok though. I may have different, inferior 1pass settings than in QuEnc.


Would releasing commandline only version of NuEnc be a big problem?


NuEnc can operate via the commandline. Type in "NuEnc /h" to get the options.


My programming skills are quite rusty and trying to make my way throu windows gui bloat (no offense) is getting on my nerves a lot.


I'm not going to get into this one :D


Can you make a build with --enable-memalign-hack, please? Or upload your complete source code, so i can try myself to make a working p4 build. The latest CVS doesn't compile with your patch and with 0.4.9-pre1 the 2pass doesn't work.


I seem to always somehow forget the --enable-memalign-hack option. I'll recompile for P4 very soon (in an hour or 2) and check to see I am using latest CVS (I am using ffmpeg-cvs-2004-09-26). Need to update those sources too.

[Peter Cheat]

NuEnc 0.00d is out now. It seems to be slower than 0.00c, but I didn't change anything that could possibly slow it down. Maybe its the mem-align-hack. First pass is also slower, so its not the rate control...

Anyway, a few important changes were made. Download it here (http://petercheat.host.sk/libav/files/nuenc0.00d.zip).

[dragongodz]

It seems to be slower than 0.00c, but I didn't change anything that could possibly slow it down. Maybe its the mem-align-hack
hmm possibly. i would have thought it would only be a cycle or 2 though(for the alignment). i assume you did a complete clean compile ?

just wondering if you ever got the chance to investigate the for and while loops GCC compiling aswell. actually what version of GCC are you using if you dont mind me asking ?

[Peter Cheat]

I am using gcc 3.2.3. The while loop and for loop uses the same number of cycles, but when you (illegally?) use a for loop within a for loop that are accessing the same variable, thats when something odd happens...Oh, I did a clean compile.

[dragongodz]

when you (illegally?) use a for loop within a for loop that are accessing the same variable
do you mean something like

for(int a=0){
;
for(a++){
;
}
}

if you follow what i mean. :)

[bergi]

With NuEnc 0.00d some problemes have gone. But it has still some problems with some clips in 2 pass mode. On clip with 750 frames didn't work, an other one with 500 frames works, so it can't be the clip length. The 750 frame clip, which didn't work was an movie intro with fast moving objects, perhaps the high bitrate/quant was a problem?

[Trahald]

Hmm.. i did some tests.. the clip i first had was about 89 frames and failed. I used a full length clip and used the trim() command on it in the script and it would only work at >= 117 frames. anything smaller and the progress bar would stay at ~95% of 1st pass and process would get bigger.

I tried a different clip and it worked fine trimmed at 100 frames.. its has something to do with the frame count but only not a specific count and not to a specific video clip.

i noticed my first failing clip was all black. (89 frames of nothing) .. the second clip was black until about frame 100.. then it fades into light and is fairly lit by 120 (this failed at 116 and lower) .. the third one worked at any length i tested.. it has full brightness video from frame 0..

[jolopo]

I just wanted to say you're the man Peter Cheat. I've done some parts of lord of the rings 3 with nuenc. It definitely beats quenc .54 with this movie in 2 pass mode. To my eyes it looks as good as the copy i made with cce. Only thing left to do is to make it compatible with dvdrb for the masses to use. I'm sure a lot of people will agree with me once they try it out. Keep it up Peter Cheat!

[Peter Cheat]

Originally posted by Trahald
Hmm.. i did some tests.. the clip i first had was about 89 frames and failed. I used a full length clip and used the trim() command on it in the script and it would only work at >= 117 frames. anything smaller and the progress bar would stay at ~95% of 1st pass and process would get bigger.

I tried a different clip and it worked fine trimmed at 100 frames.. its has something to do with the frame count but only not a specific count and not to a specific video clip.

i noticed my first failing clip was all black. (89 frames of nothing) .. the second clip was black until about frame 100.. then it fades into light and is fairly lit by 120 (this failed at 116 and lower) .. the third one worked at any length i tested.. it has full brightness video from frame 0..

This is really odd becuase it happens in first pass. Can you find the log file (QuEncLog-Pass1.txt in the temp dir) and post the last few lines? Does the same file work in QuEnc?

[RobertR]

Originally posted by dragongodz
elitist B.S. you mean. :)
elitist?? LOL
B.S. yes yes yes :D


even quite a few of us that use windows dont like things about it, theres nothing wrong with that.
however richards view is windows is bloated crap, visual studio is bloated crap, infact using an ide for programming is for dummies, c++ is crap (C is god apparently), gui's are bloated crap(even for linux, command line rules), you should be able to write huge amounts of code error free minus a few typo's.....else your crap, any closed source program is crap, and on and on and on. so whats so hard to understand ? elitist wank. :D
His attitude. I can't understand his attitude. I'm all into OpenSoftware but i rather opt on peaceful coexistance of various kinds of licensing. I infected few peoples with Linux virus ;) but only throu example. And in my opinion Linux is just not yet ready to hit all the desktops and take over M$ place. Richards sounds like a convert that was using windows just few months ago and is now trying to convince everyone that he doesn't miss all the whistles and bells. Oh, well... let's forget him (and those like him)

he even now has a couple of followers who claim gui's are for people too lazy to learn and slow down using a program. people like that who want to live in the dark ages(even linux has guis for gods sake) should go live in a cave in my opinion and let the rest of us move forward. :mad:
yep! What i love about linux (or unix in general) is that it's like lego, you can take pieces and build what you want and how you want. What i don't like about linux is that it's like lego, you have lots of pieces, a picture on the box and have no idea how to put all those pieces together so you'll get what's shown on picture.
Linux has GUIs, linux has good GUIs but sometime i look at windows with envy...
I've never used any of Visual* products, but i rembmer IDE from Turbo C or Turbo Pascal (DOS mode) and it was very helpfull in quickly writing and debugging code. Ideally i'd like to find something like this for linux (tho i had no time to look for this; for now vim, make and gdb will do the trick) As i said i'm crappy programmer (cause i need to debug every few added lines ;))


your crazy. :D
just kidding. why not, windows programmers have been using linux source for ages so why not the other way aswell ? i wish you luck.
Thanks :D Luck will be needed.. lots of luck and lots of time and helpfull people

Originally posted by Peter Cheat
Ok, firstly I have to say that I AM WORKING OFF THE LATEST CVS
I have said this before. The latest CVS has changed since the pre1 and the files affected includes the files I have changed. Use latest CVS.
...
check to see I am using latest CVS (I am using ffmpeg-cvs-2004-09-26)
OK. I think there is some misunderstanding. When I write about CVS i mean CVS (as in cvs -d.... checkout ) and You, most probably, mean latest CVS tarball taken from webpage. With this kind of developement i think you should either clearly state the date of the original sources (so others can check them out of cvs and apply your changes) or post full sources not only files you've changed or learn to use diff :) If this is problem for you than ok :) I can live with that :) Sometimes it's a bit tricky to recompile ffmpeg/avcodec with your changes.
NuEnc can operate via the commandline. Type in "NuEnc /h" to get the options.
My fault. I know that NuEnc can operate in commandline mode. What i'd like to have are NuEnc sources stripped from all windows, buttons, progess meters and stuff generally called GUI (it's not i don't like it, it would simplify porting NuEnc to linux/unix -- yes i know there is no AVS for linux but avcodec can be used to decode also). I do realize that i'm minority here tho.
(wow! never wrote such long post!! :D )

[dragongodz]

in my opinion Linux is just not yet ready to hit all the desktops and take over M$ place
no but it has improved the last few years in giant steps. i used to have mandrake linux installed(dual boot). unfortunatly i only use linux on rare occasions and couldnt justify the room it was taking on my limited hd space. so now i use knoppix livecd when i need to. it works pretty good and takes no hd room. :)

Linux has GUIs, linux has good GUIs but sometime i look at windows with envy...
this was 1 problem i did find annoying with linux. i would find the occasional program that would not work 100% right with kde but was fine with gnome. then i would find another that was not happy with gnome but great with kde. while with windows its now use windows 2000 or xp only for quite a few programs (commercial ones especially).

As i said i'm crappy programmer (cause i need to debug every few added lines )
welcome to the club. :D

What i'd like to have are NuEnc sources stripped from all windows, buttons, progess meters and stuff generally called GUI
you can find command line parsing in QuEncDlg.cpp along with the gui stuff. command line is commented though and easy to pick.
the main encoder handling is done in AVSEnc.cpp. thats where all the avcodec settings are set etc.
so those are the 2 files you should start with.

[RobertR]

Originally posted by dragongodz
this was 1 problem i did find annoying with linux. i would find the occasional program that would not work 100% right with kde but was fine with gnome. then i would find another that was not happy with gnome but great with kde. while with windows its now use windows 2000 or xp only for quite a few programs (commercial ones especially).
GNOME vs KDE war... heh.. it seems this settled down a bit (or i don't care that much to follow it). Those giant steps you mentioned would be even bigger if not cause that war.
you can find command line parsing in QuEncDlg.cpp along with the gui stuff. command line is commented though and easy to pick.
the main encoder handling is done in AVSEnc.cpp. thats where all the avcodec settings are set etc.
so those are the 2 files you should start with.
I've explored AVSEnc.cpp from both QuEnc (great work btw) and NuEnc also great work) hunting for parameters i could use with ffmpeg or mencoder.
QuEncDlg.cpp seemed so GUI that i've skipped it almost completely. Thanks for hint. This should get me going when i finish that little app i;m working on atm.

(see? i told you i'd need more than luck.. helpful people like you are precious!)

[SILICON]

I make a short test of the NuEnc 0.00D
The default options and 3 pass.

I see:
- Never use IBBPBBPBBP (2 B-Frames)
- Ever use Quantscale "Linear". For Mpeg 2, Quanscale "Progresive" is better (If CCE documentation is true)
- Detect a lot of scene changes (GOP = IB). I look the video and have not a scene change (The Universal trailer)
- The Quality are ever 0, 1 or 2. Never a decimal value.

The max bitrate and average bitrate are ok. The quality and speed are good.

Greats.

[Trahald]

Originally posted by Peter Cheat
This is really odd becuase it happens in first pass. Can you find the log file (QuEncLog-Pass1.txt in the temp dir) and post the last few lines?
Ok!.. sure.. uhm... where is it? and at what point is the file made.. i searched for that filename and came up with no hits.

Does the same file work in QuEnc?

yep.

[Peter Cheat]

Originally posted by Trahald
Ok!.. sure.. uhm... where is it? and at what point is the file made.. i searched for that filename and came up with no hits.
yep.

In Windows 2000/XP it should be:
C:\Documents and Settings\%USERNAME%\Local Settings\Temp\QuEncLog-Pass1.txt

On Windows 98/ME it should be:
C:\Windows\Temp\QuEncLog-Pass1.txt

I have a feeling its to do with the scene change detection. If you disable it, does it still fail?

Originally posted by RobertR
OK. I think there is some misunderstanding. When I write about CVS i mean CVS (as in cvs -d.... checkout ) and You, most probably, mean latest CVS tarball taken from webpage. With this kind of developement i think you should either clearly state the date of the original sources (so others can check them out of cvs and apply your changes) or post full sources not only files you've changed or learn to use diff If this is problem for you than ok I can live with that Sometimes it's a bit tricky to recompile ffmpeg/avcodec with your changes.


Using the tarball off the web page is best, that way everyone can just download that, copy my changed files over and it will compile (in theory). Using diff would be more convenient for me, but you are probably one of the minority that is comfortable with using it.

If you want to use my changes in Linux, compile FFMPEG under linux with my changed files and there you go. No GUI.

Originally posted by RobertR
I make a short test of the NuEnc 0.00D
The default options and 3 pass.

I see:
- Never use IBBPBBPBBP (2 B-Frames)
- Ever use Quantscale "Linear". For Mpeg 2, Quanscale "Progresive" is better (If CCE documentation is true)
- Detect a lot of scene changes (GOP = IB). I look the video and have not a scene change (The Universal trailer)
- The Quality are ever 0, 1 or 2. Never a decimal value.


There is nothing wrong with using 2 consecutive B-frames. It lowers quality, but is much better for low-bitrate encodes.

Linear quantisation is built-in to avcodec. Of course it is not optimal, but it is good enough. There are more important things to be done.

Scene change detection sensitivity has been increased in NuEnc. To chose a good value I used a set of 10 sequences and (batch) encoded each one with different sensitivities (from 0 to -2000 with steps of 50). After that had finally finished, I saw that -1000 gave the smallest filesize for each clip, so thats what it is. An I frame is inserted when there has been enough motion to justify its use. This also reduces smearing. Nothing wrong with a IB gop, but IP would be better...Thats why I'm working on closed gop with scene change detection.

Quality (quantiser) must be a whole value. Decimals come from the fact that the mb's in a frame can be quantised at different levels, hence a decimal average over the frame. Turning on masking of some sort will do this (spatial/temporal/lumi/dark).

[Inc]

I've explored AVSEnc.cpp from both QuEnc (great work btw) and NuEnc also great work) hunting for parameters i could use with ffmpeg or mencoder.

I got on my HD at home the sources for a "patch" by milan for mencoder.exe so that its capable to interprete AVS inputs.
Is it that what youre looking for?

But anyway, when creating a bat file including your mencoder.exe calls, you also can choose the other way by adding at the beginning a "makeavis.exe" commandline to generate the fakeavi out of your incoming avs which could be used by Mencoder.
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=makeAVIS

But in case of makeavis (commandline version out of recent ffdshow releases) you have to ...

1. Enter the ".../mplayer/codecs.conf" and add the FourCC "AVIS" description incl. a pointer to "ffvfw.dll"!!
videocodec makeavis
info "FFvfw makeavis"
status untested
fourcc AVIS
driver vfw
dll ffvfw
out YV12

2. The "ffvfw.dll" and the "mplayerlib.dll" have to be in the same folder where mencoder.exe is present. (get them from the latest ffvfw installer)

[RobertR]

Originally posted by Peter Cheat
Using the tarball off the web page is best, that way everyone can just download that, copy my changed files over and it will compile (in theory). Using diff would be more convenient for me, but you are probably one of the minority that is comfortable with using it.
Yes, you are right (in both cases) :D Obviously i missinterpreted your statement about CVS now it's all clear and easy for me.
Thanks for adding clear information on your webpage :D

If you want to use my changes in Linux, compile FFMPEG under linux with my changed files and there you go. No GUI.

I actually do exactly that (but use actual cvs checkout as basis -- btw i think there were some patches to dts/pts calculation within last two weeks that affected mpegvideo.h, don't know how relevant it is for your work)
I think that QuEnc/NuEnc are not strightforward ports of ffmpeg to win32 ( + capability of reading AVS). Or am i wrong?

Originally posted by incredible
I got on my HD at home the sources for a "patch" by milan for mencoder.exe so that its capable to interprete AVS inputs.
Is it that what youre looking for?
Don't know :) I suspect it won't solve problems as there is no Avisynth for linux (and i don't want to use wine). I believe both patch you mentioned and makeavis do relay on ability to 'use' avisynth.dll.
(yeah.. i know.. me and my stupid idea ;) :p )

[evade]

Thank you Peter Cheat, This is very cool!


I am getting ready to test this modified version of ffmpeg.

I don't have a windows box available to me and I usually do my processing in mencoder so I have compiled ffmpeg with the modified files and have come up with this methodology which seems to work:


rm -f stream.yuv; mkfifo stream.yuv
mencoder \
dance.avi \
-mc 0 \
-noskip \
-skiplimit 0 \
-ofps 30000/1001 \
-nosound \
-ovc raw \
-of rawvideo \
-vf crop=720:472:0:0,il=d:d,scale,format=i420,hqdn3d,il=i:i,expand=720:480 \
-sws 9 \
-ss 1000 \
-endpos 10 \
-o stream.yuv \
& \
\
ffmpeg \
-s 720x480 \
-r 29.97003 \
-i stream.yuv \
-ildct \
-ilme \
-mbd 2 \
-y \
-f rawvideo \
-vcodec mpeg2video \
-ps 1000 \
-strict 1 \
-g 18 \
-pass 1 \
-b 4500 \
-bufsize 1835 \
-maxrate 9000 \
-minrate 1000 \
-s 720x480 \
-r 29.97003 \
-aspect 4:3 \
-hq \
-trell \
out.m2v


and repeat for 2nd and 3rd passes.

I've never used ffmpeg before so I would appreciate someone critiquing my options. Will this produce a compliant stream? mplex accepts it with no complaints and It hits my target bitrate.

[Trahald]

Originally posted by Peter Cheat
In Windows 2000/XP it should be:
C:\Documents and Settings\%USERNAME%\Local Settings\Temp\QuEncLog-Pass1.txt

I have a feeling its to do with the scene change detection. If you disable it, does it still fail?

unfortunately, Didnt help. i tried both settings for just about everything .. the only thing that worked was disabling VBR which isnt surprising... however i need vbr ;)
well... i see the location of the file.. thanx. here are the last few lines...in:84 out:82 type:1 q:236 itex:47198 ptex:0 mv:0 misc:5243 fcode:1 bcode:1 mc-var:0 var:9783 icount:1350 comp:1.000000;
in:82 out:83 type:3 q:236 itex:0 ptex:4730 mv:1671 misc:3073 fcode:1 bcode:1 mc-var:95 var:0 icount:0 comp:1.000000;
in:83 out:84 type:3 q:236 itex:0 ptex:3014 mv:1044 misc:2888 fcode:1 bcode:1 mc-var:50 var:0 icount:0 comp:1.000000;
in:87 out:85 type:2 q:236 itex:10494 ptex:2969 mv:782 misc:3317 fcode:2 bcode:1 mc-var:10496 var:13207 icount:108 comp:1.000000;
in:85 out:86 type:3 q:236 itex:0 ptex:9744 mv:2627 misc:3639 fcode:1 bcode:1 mc-var:145 var:0 icount:0 comp:1.000000;
in:86 out:87 type:3 q:236 itex:0 ptex:5127 mv:2371 misc:3488 fcode:1 bcode:2 mc-var:162 var:0 icount:0 comp:1.000000;
in:90 out:88 type:2 q:236 itex:32699 ptex:16217 mv:2182 misc:8398 fcode:3 bcode:2 mc-var:12621 var:22616 icount:850 comp:1.000000;
in:88 out:89 type:3 q:236 itex:0 ptex:8304 mv:3341 misc:4503 fcode:2 bcode:1 mc-var:238 var:0 icount:0 comp:1.000000;
in:89 out:90 type:3 q:236 itex:0 ptex:32485 mv:10294 misc:7988 fcode:1 bcode:1 mc-var:423 var:0 icount:0 comp:1.000000;
in:93 out:91 type:2 q:236 itex:9409 ptex:15670 mv:3764 misc:4637 fcode:3 bcode:1 mc-var:19156 var:22999 icount:169 comp:1.000000;
in:91 out:92 type:3 q:236 itex:0 ptex:8252 mv:3479 misc:5247 fcode:1 bcode:1 mc-var:191 var:0 icount:0 comp:1.000000;
in:92 out:93 type:3 q:236 itex:0 ptex:10813 mv:5444 misc:5179 fcode:2 bcode:2 mc-var:409 var:0 icount:0 comp:1.000000;
in:96 out:94 type:1 q:236 itex:62633 ptex:0 mv:0 misc:5240 fcode:2 bcode:2 mc-var:0 var:27751 icount:1350 comp:1.000000;
in:94 out:95 type:3 q:236 itex:0 ptex:17572 mv:4968 misc:5852 fcode:1 bcode:1 mc-var:351 var:0 icount:0 comp:1.000000;
in:95 out:96 type:3 q:236 itex:0 ptex:20818 mv:4924 misc:5862 fcode:1 bcode:1 mc-var:303 var:0 icount:0 comp:1.000000;
in:99 out:97 type:2 q:236 itex:22168 ptex:70162 mv:12855 misc:5985 fcode:6 bcode:1 mc-var:86900 var:90095 icount:208 comp:1.000000;
in:97 out:98 type:3 q:236 itex:0 ptex:26058 mv:8709 misc:6870 fcode:3 bcode:6 mc-var:1611 var:0 icount:0 comp:1.000000;
in:98 out:99 type:3 q:236 itex:0 ptex:24456 mv:7883 misc:6556 fcode:2 bcode:1 mc-var:574 var:0 icount:0 comp:1.000000;
in:102 out:100 type:2 q:236 itex:4005 ptex:57083 mv:13523 misc:5739 fcode:5 bcode:1 mc-var:44706 var:93509 icount:72 comp:1.000000;


pass2 txt file is there but 0 bytes. the gui never switches to 2/2

thanx for the help, peter

[Peter Cheat]

Originally posted by evade
Thank you Peter Cheat, This is very cool!


I am getting ready to test this modified version of ffmpeg.

I don't have a windows box available to me and I usually do my processing in mencoder so I have compiled ffmpeg with the modified files and have come up with this methodology which seems to work:

and repeat for 2nd and 3rd passes.

I've never used ffmpeg before so I would appreciate someone critiquing my options. Will this produce a compliant stream? mplex accepts it with no complaints and It hits my target bitrate.

3rd pass is probably not necessary, especially since you are aiming for 4,500kbit/s. Use -bufsize 224 not 1835 in FFMPEG. You don't need to specify packet size (-ps) either. AFAIK, the stream will be mpeg-2 compliant. Buffer underflows won't be a problem in your case because you've set the maximum bitrate to 9000, so everything should be fine. I'm guessing you are encoding material for DVD.

[Trahald]

i saw in a earlier thread the question asked .. but is there support for setting field dominance .. it seems to default at bff ?

[dragongodz]

there is a flag for setting TFF or BFF but QuEnc and i assume NuEnc do not use it yet.

Peter - heres another little tool which gives some information about mpeg streams you may want to have a look at.
http://www.elecard.com/products/mpeg%20stream%20explorer.shtml

[Peter Cheat]

Field order selection hasn't been implemented yet. It will come out with NuEnc 0.01 which I'll release in a week or two (probablt two). I'll change the GUI, add more options, add way more stats about the stream etc.

Also working on a tool called "MPEG-2 Doctor". This tool will fix all underflow issues in material you have already encoded without re-encoding the whole stream! Based on ReQuant (like ReJig). Still in development stages. Reads header information and makes sure the stream complies with the information in the header as specified by MPEG-2 specifications.

@dragongodz
That Elecard tool tells you nothing about compliance (how ironic;)). The maximum bitrate in the stream they are showing is twice! the (maximum) bitrate specified in the header. But it still could be compliant. Since its going by the MPEG-2 specs, this tool is total bollocks! The VBV buffer size is not even mentioned. And people wonder why there is confusion about the specs? (This is refering to MPEG-1 and MPEG-2 specs, I'm certain I know what a stream requires to be compliant for this case :D Maybe I should point them to the relevant pages :D .

[dragongodz]

That Elecard tool tells you nothing about compliance
i never said it did. i said it gave some information about streams.

The maximum bitrate in the stream they are showing is twice! the (maximum) bitrate specified in the header. But it still could be compliant.
I'm certain I know what a stream requires to be compliant for this case
i wont go in to that again.

[Peter Cheat]

Doesn't give any extra (useful) information than BV.

They refer to these standard documents:
ISO/IEC 11172-2 for MPEG-1 video
ISO/IEC 13818-2 for MPEG-2 video

I know what bitrate means when refering to MPEG-1 and MPEG-2 standard compliant streams. Absolutely nothing to do with the decoder order bitrate, or stream order bitrate for that matter :D

[dragongodz]

yep the individual frame sizes etc is totally useless information. i mean what could that help with ? dont worry i wont bother you with any tools that MAY be of some tiny use anymore, as you know it all and we little newbies who have only been working with encoding for years know nothing. those other times you "knew for certain" things and was proven wrong were aberrations obviously. :D

They refer to these standard documents:
ISO/IEC 11172-2 for MPEG-1 video
ISO/IEC 13818-2 for MPEG-2 video

are you part parrot ? no ? then why do you keep repeating yourself ? i know what the mpeg documents are.

[Easy123]

@Peter Cheat

I tested NuEnc 0.00d today with a chpater from "Lord of the Rings, Return of the King" and I was stunned by the Quality at an avg. of 2500kbit. Great Work... Is there any chance of implementing a feature to take the original chapters of a DVD as I-Frames so it is possible to add the original menu to a backup and the chapters match the exact original position?

[Peter Cheat]

@Easy123
This has been done, but can be accessed by the commandline only. The command is:

-forcekey ( 1 2 3 4 5 6 7 8 69 )

This will set frames 1,2,3,4,5,6,7,8 and 69 to I frames (keyframes). Just put in the frame numbers for the start of a chapter, and they will be set. For the other commandline options try NuEnc /h.

@dragongodz
Frame size information is important, its just that libavcodec gives all the information already (via the log). I can't see anything particularly special about it that other tools do not have. I am looking for one tool - something that reads a stream and checks for underflows. Nothing like this exists, so I am writing it.

btw, I have never said I am always right, I am following the MPEG-2 draft. I don't have access to DVD Book B, and probably won't be able to. I am however, certain I understand the MPEG-2 standard. Maybe I can get the DVD standard through Uni? I doubt it.

[Guest]

Cool you fixed the p4 problem - now NuEnc runs perfectly stable on my computer!

Thanks!
Tin2tin

[dragongodz]

I am looking for one tool - something that reads a stream and checks for underflows. Nothing like this exists, so I am writing it.
actually it may exist. there are a number of commercial mpeg analysers but they are VERY expensive and i dont know if they are available to the general public anyway.
so until there is one gaining data from a variety of programs helps back up the data. if you know what i mean.

btw, I have never said I am always right, I am following the MPEG-2 draft. I don't have access to DVD Book B, and probably won't be able to. I am however, certain I understand the MPEG-2 standard.
hmm should i go back and count all the "i am certain i am right"(or similar) statements ? no that would take to long. :D
i provided you with the page that says limitations of dvd book b. ok its not the thorough specs you buy but it is important and has shown that the dvd specs are more limited than the mpeg2 draft. and no i refuse to go over that ground again since that was already proven. :sly:

since you are doing video compression at uni they may be able to help get the specs but i would not count on it.

[Peter Cheat]

dvd!=video compression
Thats the problem. If it was on "standards online" I would be able to get it, but you have to by the standards as a huge wad of paper.

The specs on mpeg.org are not good enough. They don't explain the restrictions ie. low_delay is NOT permitted !!!!
Confusing, because if it isn't allowed, we can't use b-frames...

saying I am certain I am right isn't the same as saying I am always right. Remember, I am only human.

I am still right about maximum bitrate and the vbv buffer, you just refuse to change your way of thinking and point to the CCE manual instead. :rolleyes:

[dragongodz]

The specs on mpeg.org are not good enough. They don't explain the restrictions
i already said they were not as good as buying the specs. until either you or someone willing to share with you(which they are not meant to do, you have to sign a non-disclosure statement i read) they are better than nothing. that page DOES show dvd specific limits that are not in ISO/IEC 13818-2.

I am still right about maximum bitrate and the vbv buffer, you just refuse to change your way of thinking and point to the CCE manual instead.
ye ye ye ,same old same old. you are right and CCE and other pages i have pointed to ,including that book b page, are all wrong to say the maximum bitrate is 9.8Mbit/s. we bow to your obviously superior knowledge.

[Trahald]

scenarists multiplexer engine is very good at sorting out things (for what they charge per copy they can afford several copies of DVD technical standards) . If a hypethetical(sp) stream could be made that spiked bitrate yet maintained vbv, would be a good test.


I havent tried out the key frame option yet.. does it create a new seq header or just put an i-frame in that spot?

[mean]

I believe it is the other way around
Low delay=1 ==> no bframe

[hank315]

I believe it is the other way around
Low delay=1 ==> no bframeThat's right, taken from ISO 13818-2:
low_delay -- This flag, when set to ‘1’, indicates that the sequence does not contain any B-pictures, that the frame reordering delay is not present in the VBV description and that the bitstream may contain “big pictures”, i.e. that C.7 of the VBV may apply.
When set to ‘0’, it indicates that the sequence may contain B-pictures, that the frame reordering delay is present in the VBV description and that bitstream shall not contain big pictures, i.e. C.7 of the VBV does not apply.
This flag is not used during the decoding process and therefore can be ignored by decoders, but it is necessary to define and verify the compliance of low-delay bitstreams.

And according to the DVD specifications: low-delay is NOT permitted, so fortunately B-frames may be used in DVD-MPEG2 streams;)

[Peter Cheat]

How many times I've mixed up the low_delay parameter I on't know, but its been more than twice now :o

0 = frame delay due to b frames
1 = big pictures

I now see how I get mixed up.


I never disagreed that 9.8MBit/s is the maximum video bitrate on the contrary. I totally disagree with your definition of maximum bitrate. The decoding bitrate is irrelevant and in almost every case unrelated to maximum bitrate. The only applicable case is CBR at maximum bitrate.

[RobertR]

Originally posted by Trahald
I havent tried out the key frame option yet.. does it create a new seq header or just put an i-frame in that spot?

At this moment I believe it just inserts I-frame.

[dragongodz]

I never disagreed that 9.8MBit/s is the maximum video bitrate on the contrary.
bull. you have clearly stated you think its fine to go over 9.8Mb/s so long as the VBV os ok. fine go ahead and do what you like because i am sick of trying to talk to you about it and wont bother to reply to anything you say about it.

[Peter Cheat]

I've tried to force NuEnc to output a key frame (with sequence header) but I'm not sure that it does. The code is something like this.


if (c->frame_number== frame you want to make key frame) {
picture->pict_type=1;
picture->key_frame=1;
}


I don't know if it works in the last update (didn't test) and it is a hack (forcing the library to override its own decision - very bad programming but seemed to work)

@dragongodz
I wrote this document some time ago to try to clarify the meaning of maximum bitrate. You dismissed it as, and I quote rubbish
This is the url:http://petercheat.host.sk/libav/maxbitrate-truth.html

I never ever said that maximum bitrate to the buffer was irrelevant, I said that the maximum bitrate from the buffer to the decoder was irrelevant, as long as the VBV was happy. Maybe from now on to make it clear I'll refer to "peak bitrate" as the maximum decoded bitrate to make it less confusing.

maximum bitrate - maximum bitrate from medium to buffer
peak bitrate - maximum bitrate from buffer to decoder

BV and other tools report the peak bitrate. Many are mistaken to believe that this is the same as the maximum bitrate. It is not. The only case is CBR encoding at maximum bitrate.

I don't understand why you constantly critisize and flame everything I say. In another topic, you claimed that an encoder should add padding if it is unable to acheive the specified bitrate in VBR encoding, and that it was rate control that was responsible. I tried, as politely as I could, that rate control is not the problem. Its not the purpose of padding to fill up space for no reason except to reach a target bitrate. Rate control doesn't have anything to do with adding the padding anyway, it assigns quantisers. As far as you were concerned, padding should be added to acheive any bitrate specified. Think about noobs who don't know much about encoding? They might put in 2,500,000 instead of 2500. Big problem there. Your explanation of how an encoder works was horrible. I didn't critisize. Then you critisize my feature request of mp3 encoding in QuEnc. Why? Apparently it is dangerous. Although mp3 is 100% compatible with mpeg2, just that no hardware standard exists. Why constantly flame me?

[dragongodz]

n another topic, you claimed that an encoder should add padding if it is unable to acheive the specified bitrate in VBR encoding, and that it was rate control that was responsible.
go reread that thread. i said it was a POSSIBLE solution which i DISMISSED straight away.

Rate control doesn't have anything to do with adding the padding anyway, it assigns quantisers.
rate control handles the bit distribution which DOES include padding not just assign quants.

Your explanation of how an encoder works was horrible.
ye whatever. i try to make it as simple as possible for begginers but hey you want to give them the specs and let them work it out go ahead.

you critisize my feature request of mp3 encoding in QuEnc.
no i said why i didnt think it was a good idea. call that criticism if you want but it isnt.

I don't understand why you constantly critisize and flame everything I say.
Why constantly flame me?
flame you ? oh come off it. whos the one having little rants and constantly going "i know i am right" all the time i say i disagree(with examples and/or links most of the time) ?

dont worry i wont bother to post in this thread anymore. happy ?

[Nic]

Ok, think we should forget that particular argument and move on. I think that will be best otherwise i'll have to close this thread.

Peter has his opinions and Dragongodz has his, and I think we can all work with both those opinions in existence. So lets keep it all friendly :)

-Nic

[Peter Cheat]

I think it stopped being friendly 5 pages back :(

I just don't know why someone is so persistant at critisizing. Even if they are wrong.

You can't really distribute bits to frames. You can distribute quantisers only (well to mb's, but they make up a frame). Padding is added just before writing the frame, and just after passing through the software VBV which tells how much padding to add to the frame. You can't say you want X bits for a frame. But you can guesstimate a quantiser that will approximately use X bits. Usually you come up with a fraction like 2.34. So you round up to 3. But its only a guess (can be totally wrong). Padding is also tricky as the minimum stream bitrate can go below the minimum reading bitrate specified as long as no buffer overflow occurs. It's the same story as maximum bitrate and the peak bitrate of a stream, except that overflow is probably worse than underflow.

The thing that I found wrong with your explanation of encoding was that it rather described how lossless encoding worked, not lossy encoding.

You could have just said that filters like peachsmooth reduce higher signal frequencies (not exactly true, but would be good enough) and so when the encoder goes about compressing the frame, there are fewer frequencies it has to some how represent, therefore reducing bitrate.

But hey I'm sure that they don't really care anyway :). I'm not attacking your definition completely, just a little inaccurate.

[freelock7]

@Peter Cheat
------------
I'm very surprised to discover in a test that NuEnc 0.00a works better than the last version with the same parameters:
VBR:2700-HQ-Treillis:on-2Pass-GOP:15-Interlaced:no-Turbo:on
QLB Matrix-Scene detection:no
I see a degradation of the image in complex scenes (bloc) with NuEc00d.
In bitrateviewer Nuenc0.00a go to 8400kbs and Nuenc0.00d to 5900 (max bitrate)!
Strange...
Peter, can you fix the problem in your next modified libavcodec?

[Peter Cheat]

I've noticed this also and know why this happens. It will be fixed in NuEnc 0.01 (actually, it is fixed, just haven't released it yet).
Thankyou for testing and reporting.

[damian_dimitri]

sorry for asking...but is NuEnc dead?

just curious

D.

[jakefree]

Was wondering that myself, I see there is a nuenc 0.21 but I still get the vbv underflow problems and small file size. All in all the quality is very good, better than I have ever gotten with quenc, just dont like to have vbv problems so back to using HC I went.