NuEnc 0.00d & Libavcodec improvements/suggestions [Archive] - Page 4

dragongodz

20th October 2004, 01:54

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

20th October 2004, 08:33

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

20th October 2004, 12:07

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

20th October 2004, 12:46

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

20th October 2004, 12:56

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

20th October 2004, 13:11

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

20th October 2004, 18:37

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

20th October 2004, 19:13

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

20th October 2004, 20:30

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

21st October 2004, 13:17

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

21st October 2004, 15:31

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

21st October 2004, 16:23

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

21st October 2004, 16:51

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

21st October 2004, 19:19

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

21st October 2004, 20:32

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

22nd October 2004, 07:18

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

22nd October 2004, 09:48

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

22nd October 2004, 13:12

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

22nd October 2004, 18:19

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

23rd October 2004, 00:19

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

23rd October 2004, 07:02

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

24th October 2004, 17:13

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

dragongodz

25th October 2004, 05:34

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

26th October 2004, 01:23

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

26th October 2004, 01:30

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

26th October 2004, 01:49

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

26th October 2004, 04:16

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

26th October 2004, 07:40

@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

26th October 2004, 08:18

@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

26th October 2004, 09:38

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

Thanks!
Tin2tin

dragongodz

26th October 2004, 11:34

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

27th October 2004, 11:10

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

27th October 2004, 12:21

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

27th October 2004, 14:15

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

27th October 2004, 18:27

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

hank315

27th October 2004, 19:44

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

28th October 2004, 09:06

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

28th October 2004, 10:56

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

28th October 2004, 11:21

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

28th October 2004, 14:01

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

28th October 2004, 14:22

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

28th October 2004, 14:25

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

29th October 2004, 09:18

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.