Michael Niedermayer <[email protected]> added the comment:

[...]
> > > COMMAND LINE 1 RESULTS
> > > ----------------------
> > > No "impossible bitrate constraints, this will 
> fail" 
> > > warning
> > > Buffer underflow
> > 
> > > Video Peak 9845 Average 8398
> > 
> > What tool was used to find these 2 values?
> 
> "MPEG Bitrate Viewer" (bitrate.exe) 1.5.054

Considering that google shows zero hits for
"mpeg bitrate viewer" "video buffer verifier"

I have no faith that this tool implements a VBV, and if it does not, its
output would be wild guesses and meaningless

[...]
> > > 
> > > WHAT WE KNOW SO FAR
> > > -------------------
> > >  
> > > a) Buffer underflows seem to occur more severely 
> with "high 
> > quality" 
> > > encodes that involve e.g. -mbd 2 - trellis. Both 
> average and peak 
> > > bitrate are also higher.
> > 
> > > b) Hervé found that reducing -buf_size avoids 
> excessive 
> > bitrate, but 
> > > at the expense of DVD-Video compliance of course. 
> It's 
> > unclear whether 
> > > this was in the presence of the -maxrate option.
> > 
> > what i know is that you guys dont know too much.
> 
> That is quite correct in my case :-).
> 
> > a increase in bufsize breaks compliance, a decrease 
> does not 
> > normally also iam not convinced that there is any 
> bug in 
> > libav* at all at least you have not provided a non 
> > contradictionary case that produced any issues
> > 
> > [...]
> > > CLOSE
> > > -----
> > >  
> > > I am under lots of pressure to finish my current 
> DVD magnum 
> > opus soon, 
> > > and if there's any prospect of investigating and 
> hopefully 
> > fixing this 
> > > bug in the near future, please let me know where I 
> can help with 
> > > testing and/or more information.
> > 
> > given that you managed to feed ffmpeg with 
> contradictionary 
> > parameters the buffer underflows you report are just 
> a case 
> > of garbage in, garbage out.
> > 
> > If you can provide a minimal command line with non 
> > contradictionary paremeters (you need a gap between 
> muxrate 
> > and the sum of all video and audio max rates), how 
> large that 
> > gap has to be, i dont know but not 0, and also not 
> 0.1%, 
> > mpeg-ps is a mildly bloated format it does need some 
> space 
> > for its bloat!
> 
> Yes.
> 
> The very compelling evidence is on my hard drive. It 
> involves an encode with more real-world bitrates:
> 
> ffmpeg -i "Movie.avi.37.avs" -target pal-dvd -muxrate 
> 10080000 -acodec ac3 -ab 128000 -flags ildct+ilme -g 
> 15 -vcodec mpeg2video -b 6300000 -pass 
> 1 "Movie.avi.37.mpg"
> ffmpeg -i "Movie.avi.37.avs" -target pal-dvd -muxrate 
> 10080000 -acodec ac3 -ab 128000 -flags ildct+ilme -g 
> 15 -vcodec mpeg2video -b 6300000 -pass 
> 2 "Movie.avi.37.mpg"
> 
> That encode works.
> 
> When I add -maxrate 9800000, the average and peak 
> video bitrates shoot up and (on pass 2) buffer 
> underflows result.
> 
> Much more believable evidence? ;-)

nope,
10080k - 128k - 9800k = 152k
152k / 10080k = ~ 0.015 that is 1.5%

1.5% might simply not be enough for mpeg-ps overhead

[...]
> 2) You and I need to find a way to get that 36GB file 
> to you. Then everybody would be perfectly happy, but I 
> have neither fast nor much bandwidth! If you have any 
> suggestions, please let me know.

I dont need the file, though if you ever want to send someone
large amounts of data, a bunch of DVD-R/CD-R/SD cards/usb sticks
(whatever is cheapest) per snailmail is the way to go.

> 
> LATEST SVN
> ----------
> Because I am finding FFmpeg useful, as a token of 
> gratitude I am trying to contribute to the greater 
> effort what I can. What I can contribute is helping to 
> idenfity and correct code and documentation errors. My 
> programming has become too rusty for anything else.

That is a pitty, if you did code as much as you write english
text you would surely be a pretty valuable developer.

also id like to repeat that the target dvd option enables a maxrate and
that your adding of a maxrate command line option really is just changing
its value not adding a limit where none was before.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle

----------
status: open -> closed
substatus: needs_more_info -> invalid

_____________________________________________________
FFmpeg issue tracker <[email protected]>
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1081>
_____________________________________________________

Reply via email to