VideoHelp Forum




+ Reply to Thread
Results 1 to 9 of 9
  1. I have a whole slew of 480x480 NTSC MPEG2 files (TiVo) I would like to convert to 720x480 MPEG2 using ffmpeg. I've had no trouble using constant-quality encoding, but my target bitrate always seems to fall in the gap between "-qscale 2" and "-qscale 3". The obvious way to gain better control over bitrate is to use 2-pass VBR encoding. Maybe I'm a dumbass, but I can't seem to get it to work with ffmpeg.

    Here's the command line I'm using in my batch file for the first pass:

    ffmpeg -i %~n1.mpg -pass 1 -passlogfile %~n1 -an foo.mpg

    This runs fine, i.e. it produces the log file and "foo.mpg", which I assume is junk.

    I'm assuming that the log file is all I need for the second pass. Is this correct? If so, is there a way to write foo.mpg to a null device during the first pass so I don't waste time writing a file to my HD that I'm just going to delete anyway?

    Here's the command line I'm trying to use for the second pass:

    ffmpeg -i %~n1.mpg -pass 2 -passlogfile %~n1 -b 2200 -bufsize 600 -vcodec mpeg2video -s 720x480 -an %~n1(720x480).mpg

    It starts to churn then gives me a million of these:

    [mpeg2video @ 0067237C]rc buffer underflow

    I suspect that I just haven't figured out the correct syntax for the second pass command line (trial and error is a poor substitute for good documentation). Can anyone help? I have no idea what the -bufsize parameter means, what it should be or if I really even need it. Any inputs?

    If someone has an example of commands that have worked for them, I'd love to see what you've got!
    Quote Quote  
  2. Member Soopafresh's Avatar
    Join Date
    Jan 2004
    Location
    United States
    Search Comp PM
    Looks like all you need to do is change the header in the 480x480 mpeg2 file to read 720x480, ala DVDpatcher


    I had the same problem running FFMPEG from the command line. Tons of Buffer Underflows. Finally gave up and tried some alternates - mencoder.exe and mpeg2enc.exe from dvdauthor. Wasn't crazy about the results of any of them.
    Quote Quote  
  3. Believe it or not, my problem was that I had errors when I compiled ffmpeg. Should have looked at the log file, eh? I've re-compiled it and have had very good results with the following commands:

    ffmpeg -i %~n1.mpg -pass 1 -passlogfile %~n1 -b 3000 -minrate 0 -maxrate 8000 -bufsize 224 -vcodec mpeg2video -s 720x480 -r 29.97 -aspect 4:3 -hq -an foo.mpg
    del foo.mpg
    ffmpeg -i %~n1.mpg -pass 2 -passlogfile %~n1 -b 3000 -minrate 0 -maxrate 8000 -bufsize 224 -vcodec mpeg2video -s 720x480 -r 29.97 -aspect 4:3 -hq -an %~n1(720x480).mpg

    Note that I've nulled the audio stream because I'm only going to demux the file later; i.e., I might as well just pull the audio from the original file to save some processor time and disk space.

    Below is the Windows batch file that I use to to resample and demux my MPEG-2 files to prep them for DVDLab. Note that I'm using BBdemux http://members.cox.net/beyeler/bbmpeg.html and a little tool I found called mpegdmx.exe http://www.hampa.ch/mpegdemux/. Because TiVo is my source, I've set it up to leave Dolby 5.1 audio alone and to convert stereo MP2 audio to stereo AC3 at 192 kbps.

    I hope someone finds this helpful.

    @echo off

    set PATH=C:\Program Files\MPEG Demux;%PATH%
    set PATH=C:\Program Files\BB Tools;%PATH%
    set PATH=C:\Program Files\ffmpeg;%PATH%

    if exist foo.* del /Q foo.*

    for /F "tokens=*" %%I in ('dir /b *.mpg') do call :Proc "%%I"
    goto :done


    :Proc

    echo %time%: Resampling %~n1.mpg ...
    ffmpeg -i %~n1.mpg -pass 1 -passlogfile %~n1 -b 3000 -minrate 0 -maxrate 8000 -bufsize 224 -vcodec mpeg2video -s 720x480 -r 29.97 -aspect 4:3 -hq -an foo.mpg
    del foo.mpg
    ffmpeg -i %~n1.mpg -pass 2 -passlogfile %~n1 -b 3000 -minrate 0 -maxrate 8000 -bufsize 224 -vcodec mpeg2video -s 720x480 -r 29.97 -aspect 4:3 -hq -an foo_p2.mpg

    echo %time%: Extracting Video (0xE0) from "%~n1.mpg"...
    mpegdmx -d -s 0xE0 -b foo_p2.m2v foo_p2.mpg
    ren foo_p2.m2v %~n1_p2.m2v
    del foo_p2.mpg

    echo %time%: Extracting MP2 audio (0xC0) from "%~n1.mpg"...
    ren %~n1.mpg foo.mpg
    mpegdmx -d -s 0xC0 -b foo.mp2 foo.mpg

    if exist foo.mp2 echo %time%: Converting %~n1.mp2 to %~n1.ac3
    if exist foo.mp2 ffmpeg -i foo.mp2 -ab 192 -ar 48000 -ac 2 -acodec ac3 -y foo.ac3

    if not exist foo.mp2 echo %time%: Extracting AC3 audio (0xBD) from "%~n1.mpg"...
    if not exist foo.mp2 bbdmux foo.mpg 0xBD foo.ac3 0x80

    ren foo.mpg %~n1.mpg
    if exist foo.ac3 del foo.mp2
    if exist foo.mp2 ren foo.mp2 %~n1.mp2
    if exist foo.ac3 ren foo.ac3 %~n1.ac3

    echo %time%: Finished with %~n1.mpg
    echo **************************************

    goto :eof


    :done
    echo %time%: Batch complete
    pause
    Quote Quote  
  4. I'm a new user of ffmpeg and I like it a lot but I'm having problems growing to use its full capabilities. Can you point me somewhere to get a better understanding of what it can do and how to get higher quality results?

    I've found the product documentation to be no better than what one might find on the back panel of a software retail box. I guess what I really need is a users manual.

    Any suggestions?

    Thanks.
    Quote Quote  
  5. Having just recently struggled by trial and error through getting ffmpeg to do a 2-pass, I thought I would add this late comment.

    Slider originally asked: "I'm assuming that the log file is all I need for the second pass. Is this correct?"

    As far as I can tell, the answer is no, you need to use the output file of the first pass as the input of the second pass. Shame the doc(s) don't have more to say on that point. The question also arises of what happens if the parameters are varied after the first pass, ie, can a clash result?

    Whilst I'm on the job, does anyone (presumably someone who has dived into the source code) have any idea what algorithm(s) ffmpeg uses when it performs a resize? Packages like VirtualDub and AVISynth seem to support a variety ...
    Quote Quote  
  6. Member Soopafresh's Avatar
    Join Date
    Jan 2004
    Location
    United States
    Search Comp PM
    I believe some of the resize algos were used for the Avidemux2 app. Since Mencoder and FFmpeg are 1st cousins, the resizers are most likely shared.

    I agree about the docs. I wish they'd just hold off on the development and work on some docs, especially syntax examples. Mencoder is better documented.
    Quote Quote  
  7. BTW, a common reason for buffer underflows is through specifying an inadequate bitrate. Note that the ffmpeg units are b/s, not kb/s. Slider's use of 3000 b/s looks a tad low 8). From memory, grief can be caused if a paste from GUI4ffmpeg is used to build the command-line, the reason being that kb/s rather than b/s are displayed.

    As for an appropriate bufsize, I don't know for sure. A second's worth worked for me. Too small, and the bitrate of the output seems to suffer. One way round it is to forego the -maxrate argument, which seems to be what triggers the requirement for bufsize to be defined, and just let the application decide during the second pass. Another way round it is to use one of the pre-defined targets, provided you are comfortable with the associated bitrate which is automatically supplied.
    Quote Quote  
  8. Member
    Join Date
    Dec 2004
    Location
    Triptonia
    Search Comp PM
    Originally Posted by Public Image Ltd
    Slider originally asked: "I'm assuming that the log file is all I need for the second pass. Is this correct?"
    As far as I can tell, the answer is no, you need to use the output file of the first pass as the input of the second pass.
    Whilst I'm on the job, does anyone (presumably someone who has dived into the source code) have any idea what algorithm(s) ffmpeg uses when it performs a resize?
    That's untrue. Only the logfile is required.
    You'll see slider added a del command between passes to kill the junk file.
    AFAIK you have to output the first pass though as there is no way to output to nul like you can with mencoder.

    I believe until last year ffmpeg and mencoder were completely different regarding resizing.
    Mencoder uses swscaler. With the -sws switch you can set the algorithm.
    Swscale has been intergrated into ffmpeg but I can't find a single instance of example usage...
    I'd guess default is bicubic.

    Originally Posted by Public Image Ltd
    BTW, a common reason for buffer underflows is through specifying an inadequate bitrate. Note that the ffmpeg units are b/s, not kb/s. Slider's use of 3000 b/s looks a tad low
    The underflow is due to setting a low bufsize. Killing the switch should stop underflows.
    Or fix bitrate values!
    Indeed it's b/s. You can add a 'k' though: -bufsize 224k

    Originally Posted by SliderVF14
    ffmpeg -i %~n1.mpg -pass 1 -passlogfile %~n1 -b 3000 -minrate 0 -maxrate 8000 -bufsize 224 -vcodec mpeg2video -s 720x480 -r 29.97 -aspect 4:3 -hq -an foo.mpg
    -hq???
    exactly how old is your ffmpeg version?

    As for quality.
    I believe it's very good.
    I haven't really tried it much because they're bastards to run,
    and lately I see less and less reason to using anything other than HC,
    but I'm pretty sure quality is very good.

    here's a sagittaire batch using mencoder and 3pass to work with
    sagitaire.bat

    gl
    Quote Quote  
  9. Member Soopafresh's Avatar
    Join Date
    Jan 2004
    Location
    United States
    Search Comp PM
    Good points, 45tripp . To add more fun to the puzzle, the bitrate syntax has changed in ffmpeg (in the newer builds) , ala

    -b 3000K -minrate 0K -maxrate 8000K

    As far as Mencoder and Mpeg2 encodes, the syntax varies pretty widely, depending on the build as well. IIRC, Sagittaire's batch files (and GUI front-end) didn't like the newer mencoder builds. I think this one DID work (although I could be wrong, and have been...many, many times).

    http://www.mplayerhq.hu/MPlayer/releases/win32/MPlayer-mingw32-1.0pre8.zip
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!