Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
11-03-2003, 03:45 AM
|
Free Member
|
|
Join Date: Sep 2003
Posts: 18
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I have another script doing only the first pass using mencoder, and the final size is not the right size for the average bitrate I set. Looks like ffmpeg was more precise adjusting the bitrate on the first pass, doesn't it?
Anyone else tried it using the options vbitrate=$bitrate and pass=1 with success?
I'm using mencoder from CVS.
|
11-03-2003, 04:58 AM
|
Free Member
|
|
Join Date: Oct 2003
Posts: 5
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I'm tempted to believe that ffmpeg and mencoder are doing an equally good job here, since both use libavcodec (part of ffmpeg) to do the actual encoding. They might use different approaches to achieve their target bitrates, though, as libavcodec has _very_ elaborate (and to many (myself included), utterly confusing) rate control settings.
|
11-03-2003, 05:59 AM
|
Free Member
|
|
Join Date: Sep 2003
Posts: 18
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hmm maybe the difference is between the options I used with ffmpeg and mencoder. By the way, is there any difference between using vpass=1 and not using vpass?
What I'm looking for is the best approach to an average bitrate I set with one pass encoding. For example, if I set average bitrate to 750, and the source file is 6800 seconds, the resulting file should be 750*6800/8 = 637500 Kb (622Mb), or the best approximation to that size.
That way, knowing the source file length in seconds, I could adjust the average bitrate to the optimum value for getting the best quality and getting the size under 800 Mb.
Any ideas?
|
11-03-2003, 06:13 AM
|
Free Member
|
|
Join Date: Oct 2003
Posts: 5
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
This bitrate discussion has been going on on the ffmpeg-devel list for a while too.
The main problem is that ffmpeg/libavcodec doesn't have strict enough bitrate enforcing, generating streams that may fail to comply with various standards, even if the user sets the correct limitations. The most notable problem has been the lack of a hard max bitrate, and streams occationally have short peaks that go well over the required max.
However, this is a work in progress, and I'm sure someone will come up with the right set of options to generate a guaranteed (s)(k)vcd/dvd compliant stream soon.
Using two-pass encoding should help, though, but even then it's not 100% certain that you get the bitrate you asked for. :-/
|
11-03-2003, 06:14 AM
|
Free Member
|
|
Join Date: Jul 2003
Posts: 106
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by el_mozo
For example, if I set average bitrate to 750, and the source file is 6800 seconds, the resulting file should be 750*6800/8 = 637500 Kb (622Mb), or the best approximation to that size.
|
Doesn't that depend on the movie? (motion estimation)
If everything is well a low motion movie will be less in size and a high motion one will have a bogger size, else vbr didn't make sense.
__________________
Groetjes Japie
|
11-03-2003, 09:33 AM
|
Free Member
|
|
Join Date: Sep 2003
Posts: 18
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Doesn't that depend on the movie? (motion estimation)
If everything is well a low motion movie will be less in size and a high motion one will have a bogger size, else vbr didn't make sense.
|
That is true using CQ (constant quality) like using a fixed quantum and no bitrate settings.
However, if you define an average bitrate, it should give you that, even if it uses variable bitrate (it would use bigger bitrate than the average on high motion scenes, but lower bitrate than the average on low motion scenes, thus compensating the bitrate to reach the desired average bitrate.). Sometimes they need two passes: to collect motion data on the first pass, and to actually encode the file on the second pass using the data from the first pass, so they know exactly where are the high and low motion scenes beforehand.
Thanks, vidar for your information regarding the ffmpeg/libavcodec bitrate enforcing. Let's wait then for a new release solving these issues...
|
11-03-2003, 10:55 AM
|
Free Member
|
|
Join Date: Sep 2003
Posts: 18
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
|
11-04-2003, 02:33 AM
|
Free Member
|
|
Join Date: Sep 2003
Posts: 18
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Well, I tried it, (using vrc_eq=1 in lavcopts) and...
Code:
Without the option: 727570032 2003-11-03 17:07 dvd2kvcd.mpg
With vrc_eq=1: 727570032 2003-11-03 17:45 dvd2kvcd.mpg
As you can see, it is exactly the same, no difference at all, and I'm using mencoder from CVS.
So I still can't force the encoding to an average bitrate.
|
11-04-2003, 09:20 AM
|
Free Member
|
|
Join Date: Oct 2003
Posts: 23
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hello
I tested japie's latest mencoder 2pass script (installed mplayer and ffmpeg by the instructions found in the README, everything worked fine), which is blazingly fast and produces great quality mpegs. There's just one big problem.
I encoded a movie, it resulted as 781MB, ok, no problem with that. But when it's time for vcdimager to create a bin/cue, it gives me this info (this is from a 1-minute clip):
Code:
INFO: scanning mpeg sequence item #0 for scanpoints...
++ WARN: mpeg stream will be padded on the fly -- hope that's ok for you!
++ WARN: APS' pts seems out of order (actual pts 18.059989, last seen pts 18.100000) -- ignoring this aps
++ WARN: autopadding requires to insert additional 1002984 zero bytes into MPEG stream (due to 3634 unaligned packets of 3635 total)
because of this autopadding, the resulted videocd.bin is too big to be burned to cdrom, even if I would use the --overburn option.
Also, if I burn the 1-minute clip to a cd and play it on my standalone dvd-player, it plays fine, but as soon as I forwardseek it, the audio goes out of sync with video. Argh! This happens with every damn movie source I have tested with.
Does anyone else have these problems or have a solution to this, it would be grately appreciated!
TIA
/tetra
|
All times are GMT -5. The time now is 08:09 PM — vBulletin © Jelsoft Enterprises Ltd
|