[MEncoder-users] Trouble transcoding 1080i "video" to NTSC DVD -- SOLVED!

[Nico Sabbi]

Walter Belhaven wrote:

>Score!
>
>Here's the mencoder command line I settled upon for each file (and
>repeat with vpass=2 for a 2-pass VBR encode).  Original files were
>1080i at 1280x1088 with a 384kbps AC3 audio sound track:
>
>mencoder \                 # Righteous open-source transcoder. :)
> -oac copy \               # Leave Audio "as is" (AC3 DD5.1 384kbps)
> -ovc lavc \               # Use lavc to transcode the video
> -of mpeg \                # Output "container" is MPG
> -mpegopts format=dvd \    # - specifically, DVD-compliant MPG (VOB)
> -vf \                     # Filters:
>    [phase=t,] \           # [Only when field order needs reversing]
>     crop=1264:1072, \     # Crop to multiples of 16 (see man!)
>     scale=720:480:1, \    # INTERLACE-aware scaling to DVD res.
>     harddup \             # See man: helps keep A/V sync
> -lavcopts \               # Codec options:
>     vcodec=mpeg2video: \  # Output video is mpg2
>     vrc_buf_size=1835: \  # DVD Standard sez so
>     vrc_maxrate=9696: \   # Max = 10800 (DVD max) - 384 (audio)
>     vbitrate=5731: \      # Makes the whole thing fit on one DVD-R
>     keyint=18: \          # DVD Standard sez so (NTSC)
>     aspect=16/9: \        # Cuz it is. :)
>     ildct: \              # INTERLACE-aware DCT
>     ilme: \               # INTERLACE-aware ME
>     top=0: \              # Output Top field first
>     mbd=2: \              # /  Some "high quality" options
>     trell: \              # \  (off on first pass)
>     vpass=1 \             # [Change this to vpass=2] on 2nd pass
>  -ofps 30000/1001 \       # NTSC standard frame rate (interlaced)
>  -o output.mpg \          # Output file
>  input.mpg                # Input file
>
>Anyway, hope this helps other folks struggling with the same thing. 
>  
>

good. Can you tell me what version you are using? Users are reporting a 
lot of problems
with last revisions, but it's still unclear when the muxer was broken

>Nico et. al. -- is it possible that there's a memory leak somewhere in
>the mpeg muxer?  
>

it's possible because the muxer does a lot of memory allocations, but I 
paid attention to
reuse always the same buffers (enlarging them when necessary), so I tend 
to believe
that the muxer deals correctly with memory usage (although bugs are 
always possible)

>Working well with short files, but not with longer
>ones might be an indication of such.  
>

what do you mean with "not with longer files"?

>Of course, it could also be that
>the filters and/or codecs didn't react well when 'interlaced' was
>enabled and the field order kept changing.  Just throwing out some
>ideas FWIW.
>
>Cheers,
>WB
>
>  
>

Bye,
       Nico