[MPlayer-users] NTSC vob-to-divx Encoding

Michael Halcrow mah69 at email.byu.edu
Fri Jan 17 05:45:25 CET 2003


Time for fun NTSC timing problems!

Hopefully we can get some good documentation on exactly what is going on
with NTSC timing and what not. Also, I am asking any encoding guru's
around about the best way to encode this file (and what it would take to
automate the process). I am working on the dvd2divxscript.pl script.

For debugging purposes, I am uploading a stream dump of "The Winslow
Boy" in NTSC to (generated with -dumpstream):

ftp://mplayerhq.hu/MPlayer/incoming/winslow.vob

I'd like to use this as the ``test'' vob stream, since it is a prime
example of an NTSC vob that gives me problems.

I had A/V sync issues in the resulting file while making a divx backup.

I encoded the audio like so:

# mencoder winslow.vob -ovc frameno -oac mp3lame -lameopts
br=128:cbr:vol=3 -o frameno.avi

I encoded the video like so:

# mencoder winslow.vob -ofps 23.976 -ovc lavc -lavcopts
vpass=1:vcodec=mpeg4:vbitrate=830:vhq -oac copy -o winslow.avi

# mencoder winslow.vob -ofps 23.976 -ovc lavc -lavcopts
vpass=2:vcodec=mpeg4:vbitrate=830:vhq -oac copy -o winslow.avi

In reality, I would like to crop and scale this film according to
DOCS/tech/encoding-tips.txt (who wrote that, anyway?), and I'd like it
to be for a 4:3 aspect ratio screen. I will get around to that once I
get the whole A/V sync problem figured out.

(I actually don't recall the exact bitrate, but that should be
inconsequential to the A/V sync problem).

The audio is about 1.4 seconds early in the final product. An -af
delay=1400:1400 seems to fix things during playback.

I am working on the dvd2divxscript.pl script, and so if anyone can give
me pointers on how to detect the A/V sync issue (and the amount by which
I need to correct), then that would help me get that right in the
script. Better yet, let's fix it in mencoder. :-)

If I use two-pass encoding instead of three-pass, then there are no
audio sync problems (that is, if I encode the audio with the video in
both passes). If I use the -ofps 23.976 during the first pass of a
three-pass encoding (the audio only), then things really get messed up
in the video encoding.

Notice also that if you don't specify the "-ofps 23.976" option, you get
really, really bad results (with duplicate frames all over the place
while encoding). I've noticed that this happens with almost all NTSC
vob's.

There just doesn't seem to be a nice, clean way to get this file encoded
at the moment. Correct me if I'm wrong.

The bugreports.html page did not specify what the filesize limit is on
these, so I hope 3.1 gigabytes isn't too much :-) I recommend you keep
this file around as a prime NTSC example of a vob file so that the
developers can have plenty of opportunity to work with it.

Mike
-- 
---------------------------------------- | ------------------------
Michael Halcrow                          | mhalcrow at byu.edu    
Research Assistant, Network Security Lab | Dept. of Comp. Science  
                                         | Brigham Young University
For a man to truly understand rejection, |
he must first be ignored by a cat.       |
---------------------------------------- | ------------------------
GnuPG Keyprint:  05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20030116/3bb16a3f/attachment.pgp>


More information about the MPlayer-users mailing list