FFMPEG: Bitrate peaks
 

I really like the encodings done with ffvfw, and I couldn't control the max bitratepeaks either. So I looked at one movie in Bitrateviewer, and found that the average bitrate was¨839 kbit/s and with peak at 5540 kbit/s.
I was doing a SVCD at 480x576 and VBV 112 (56 in BV).
Muxed and burned as SVCD. When I was watching the movie in my standalone, I didn't see any difference at those scenes with the high bitrate peaks ????
I have now done 5 movies, they all have bitrate peaks between 3500 and 5540 kbit/s, and they all played perfectly...

Maybe I'm just lucky to have a standalone, that will play these movies, but I'm a very happy with my results and testings :D

Have anybody else actually tried to burn these high bitratepeaks movies and tested them in your standalone?

Well, just wanted to share my findings :D

Anerboda

Well it's good for you your player will play it, and I'm also pretty sure my player will play SVCDs with peaks of ~5000kb/sec, but when it comes to DVD encoding and the peaks go up to ~15.000kb/sec, I guarantee you that NO standalone on the world will play it, because it's just way out of standard... :roll:

Bitrateview calculates the bitrate BEFORE the use of the vbv buffer. If you want to create an standard svcd, it's only important, that the bitrate AFTER the use of the vbv buffer ist below 2756 kbit/s (oder something like that).

thats the case when i encode stuff with mencoder, even if there are the same bitrate peaks, too. Additionally, you can reduce the rate control tolerance, this will cut these peaks. not even scenarist complaints about peaks @ 10 mbit/s (+2 mbit/s audio), if rct is not too high, and this tool generally complaints about everything.

Hi anerboda,
I still didn't get peaks above vrc_maxrate in mencoder, did you get them?. What was your mencoder command-line, and what the bitrate peaks you got?. Did you take a look at that scene overbitrated?, how did it look?.
AFAIK there's no single function in mencoder to adjust rate control tolerance. How do you adjust it?. Do you make use of vrc_eq, vi/b_qoffset,...?.
I'm really curious about this bitrate peaks :?

:lol: I think he's talking about ffvfw encoding :lol:
This is getting a bit out of hands :lol:
So many encoders in these threads that we don't really know what we're talking about :wink:
Could you tell us which one you're experiencing over-bitrates?

@all,
When you start a thread be a sports and tell us which encoder and OS you refer to :wink:

Cheers

Well, Rui, I don't really know:
I understood he meant mencoder, but you're right: working with so many encoders at the same time... we'll finally mess them up! :lol: :lol: :lol:

There is such a feature called rate control tolerance, set it with :vratetol=1000: or something like this. i prefer a value between 1000 and 2000.

Hi amenophis, from man_page:
I didn't know filesize tolerance was the same as rate control tolerance. I thought the first refered to final filesize, and rate control would refer to same internal way of encoder to adjust bitrate. But just figured it out, since I don't have the knowledge. I see I was wrong.
Then, what is vratetol supposed to be doing?, how does it work?. Where did you take that 1000 value?. When you change it, what happens to the m2v file, and the image?.
Amenophis, I see that you use some settings (vqblur=0.3, lumi_mask, dark_mask) that I suppose that you got from your tests, or from guides, forums,... Could you help us with these settings, and how you decide which employ in every situation/film (increase filesize, increase compression, improve quality,...)?

in general, both things are something different, but it seems that both things are adjusted by this settings. i've choosen a value between 1000 and 2000, because values < 1000 will result in strange bitrate distribution and higher values will result in higher peaks. I thought it was called rate control tolerance in the manual, sorry if my first answer was a little bit confusing because of that.

i didn't use lumi- oder dark_masking, both will lower the quality. it may be good for low-bitrate rips, but i concentrate on dvd->dvdr conversation. i havn't tested the influence of vqblur yet, i did choose 0.3 in the gui because it's close to the standard and these results with this setting were ok.

You're right, I didn't make that clear, I'm sorry :oops:
My testings and results were done using the ffvfw codec, and my OS is XP pro.
This is not a new thing, it was discovered long ago in some other threads, I was just curious if these movies with high bitrate peaks would play in my standalone, and they do.

Anerboda

Lucky you, Anerboda :wink: .
As for some of us can't say the same...
Anyway maybe one of these days Milan solves it, for us.
Thanks for sharing it with us.
Cheers

I've got one question. Is the bitrate peek acceptance for standalones related to VBV value :?: I mean, DVDs cann accept 9MB/s with VBV224 (good value ?) , so what will hapen when we'll set VBV value to 224 for SVCD streams. Maybe this will solve peek problems.

It will be great if some with problem of high bitrate on standalone test this way. I have no problem with them.

sorry to ask here, but with what kind of bitrate peaks does your player have no problem? you're not talking about the >10.000kb/sec peaks are you? 8O

Just for info,
my player also doesn't accept high bitrates. It seems to me that with bitrates above 9500 for DVD, and above 2900 for SVCD, it beggins to "skip" frames or "slow motion" like.
In SVCD I managed to raise a bit (I think to 3000) adjusting VBV.
But this small change for DVD means nothing

Do'h. No.
Problem was with ~5000kbps as Anerboda pointed, so I was just wonder if that type of file (with bitrate peek let say around 5000kbps, with VBV set to 224, and muxed as SVCD) will be playable on standalones that do have problem with VCD bitrate peeks above permited ~3000kbps. As the DVD with the same bitpeek value will be playable.

And yes, my standalone (the one I'm testing) plays even 7000 bitpeeks with VBV set to 40.

Well, Hydeus, as I just posted, 5000 kbps won't play in my standalone in VCD neither SVCD (I already tested playing with VBV) :cry:

To what value, and how you adjusted this :?: (of course VBV)

Hya,
As far as I have understood from www.dvdrhelp.com any SAP could go up to the 4500kbps in an X(S)VCD.
But that means that some will do no more than 3000kbps.
Some won't go above SVCD specs., period.
As for DVD all should go fine up to DVD specs. which is 9800kbps for video only,
but very few should do more than that.
Maybe the new SAP era of DivX capable players will do > 9800kbps but what about the others...
DivX capable SAPs are still above 300€/$.
At least here in Portugal.
I can buy a SAP for less than 70€/$ here if I don't care about MPEG-4, and I don't :twisted: :!:
So let's see if in a not so far future Milan can give us a hand.
BTW have you noticed that now the FF forum is not exclusivly dedicated to U*NIX and Co. :?: :mrgreen:
Cheers

I think that bitrate viewer is bunk...

I have a secondpass file encoded with ffvfw...When I checked it with bitrate rate viewer, the maxium peak was 8879. After running pulldown, the bitrate peak jumps to 10612. How can that be?

You could be right :!:
I know that Bitrate Viewer does give incorrect average bitrates on MPEG-1 files.
The true average bitrate is found with VirtualDub.
Maybe it's time for me to write "Bitrate Peeper" :mrgreen:

-kwag

@ kvcd,

And, make :hammer: it command-line too :mrgreen:
-vhelp

A command line bitrate viewer 8O :screwy:

NOOO!! goofy!! :screwy: :confused:

I mean, if your tool was gonna give us a few numbers, it could be used in
other toolings or calculations, and we could :hammer: incorporate it somehow
into our apps for strength :idea:

-vhelp

I was thinking on something similar to Bitrate Viewer, but with more visual statistics :)
Maybe a combination of Bitrate Viewer + DVDPatcher + VBVPatcher + MPEGanalizzatore + mpegprop :D
But then again, that would take some time to build, as the full MPEG bit stream pattern has to be decoded, organized and displayed. That would be a usefull application, and it would really be a true MPEG analyzer ;)

-kwag

..about that DVD is was just talking about...It played perfectly, it tested it for two hours...definatly a problem with bitrate viewer...

There is already (beter to tell "will be") alternative to BV: MPEG Validator (information post on doom9), but there is no published code or binaries of this, for unknown reason :?
Is there someone able to answer my question about SVCD with DVD-VBV value :?:

Wishfull thinking:
A way to get rid of bitrate peaks could be an automated process like the following:
analyze m2v stream and find the over-standard spots -> break the stream at the nearest I frames -> run rejig on the over-bitrate segements -> splice all the segments back
marcellus

Actually, a simpler way (based on your thought :) ) would be to modify ReJig so instead of recompressing frames with a %, to actually "trim" frame bitrate that are above a treshold.
This way, we can just set a MAX bitrate, and anything that is >= to that bitrate, is re-encoded with that MAX bitrate.
I think this would be a simple modification to ReJig.
Then, we can call it ReClamp :mrgreen:

-kwag

And with this aproximation, Kwag, will quality suffer?.
I mean, after reencoding with Rejig (or it doesn't really reencode?), and lowering bitrate without adjusting Q, won't these scenes suffer of lack of bitrate?.

Yes it will suffer, but if they are quick "spikes', for example on a single I frame, then you probably won't notice it when playing it on the TV.
Only if you were to slow motion, then you would see some frames with blocks.
This would have to be tested :!:

-kwag

Yes kwag, this is my problem now: doing so many tests that most of them I see with my nose stuck to the monitor to look for artifacts-macroblocks, and many scenes in low motion... :lol:
But this is not the way we will see them later, isn't it :wink:

I dont know...I am not convinced that their is any program with the VBV...all of the streams that I have made have played perfectly....I think the program is where Bitrate viewer establishes the baseline...something in ffvfw conflicts with Biterate viewer or has a difficult time establishing a true baseline...this must be related to the VBV issue....

I'm also thinking that is unlikely to see any artifacts because the target bitrate (after rejig) should be the maximum permited by the standard, meaning a big enough bitrate to alow artifacts to be seen.
marcellus

Hey, you're steeling my idea! :twisted:

From my first post ever on this forum... :roll:
Posted: Wed Jan 28, 2004 12:21 pm

http://www.kvcd.net/forum/viewtopic.php?t=8835

Bilu

If ReJig does set a MAX bitrate constraint, and restricts it to the DVD standard, then running ReJig as it is set to 100%, would do the trick :)
It would basically "clip" the MAX bitrate, and make it standard. Worth a try :cool:

-kwag

8O WOW, sorry, I surely missed your post!
marcellus

Actually it's not the same thing :!:
The way ReJig works, is that it recompresses frames in order to achieve a destination size.
What I proposed, is a modification to ReJig, so it "clips" high bitrate peaks only.
So it's not the same ;)

-kwag

Well, just made the test with ReJig at 100% (no compression). It didn't work :!:
I encoded a small clip with ffvfw (anamorphic 720x480) which peaked at 10,553Kbps, and after processing with ReJig, the peak is still 10,553Kbps.
So ReJig doesn't clip MAX bitrate to DVD standard.

-kwag

Probably at 100% rejig simply does nothing. In my algorithm I thought that at every spot with over-standard bitrate, before rejig, it must be figured out a percent for rejig to do his task. Besides, I don't think rejig incorporates the code to analyze the bitrate at every frame, it simply requanitzes the entire stream by a coeficient obtained from actual bitrate/target bitrate ratio. The analysis must be made outside rejig
marcellus

But it is!!! :twisted:

Rejig is based on M2VRequantizer, and I was looking for " any way to use a requantizer tool like M2VRequantizer to post-process the FFMPEG output that overlaps max bitrate."

I was referring to "requantize when needed". To requantize the whole thing was an already known process ;)

Bilu