bug-vcdimager
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VCDImager Bugs/Devel] SVCD out of sync


From: Andrew Stevens
Subject: Re: [VCDImager Bugs/Devel] SVCD out of sync
Date: Mon, 25 Jun 2001 19:51:26 +0200

Hi Udo,

I can help with the mjpegtools stuff but I'll leave the SVCD to
someone more expert than me.

> I'm using DV material and conbvert it with the mjpegtools to
> MPEG2 (SVCD format). After getting the mpg-files I'm using vcdimager
> & cdrdao to burn them. Under Linux it's absolutely no problem, mplayer
> can read and play them correctly, no matter if you
> play the files directly or as track from the SVCD.

How odd...   is the time offset constant or does it grow/decrease with
playing time?  Do you get the same problems if you encode from some
other source than DV?

If it stays constant you can neatly correct for it using mplex'
sync offset (the -O flag). If you mux with -O 100 all the video frames will 
have their presentation (playback) timestamps set 100mSec 
later relative to audio and so play back 1/10 second later.


> But my Yamakawa 780 has almos 1/10 of a second difference. The video
> stream comes before the audio stream. Is this an issue with
> my DVD player ? 

>Or is it vcdimager, cdrdao or even the mjpegtools ?
-----------------------^
No chance of the mjpegtools being wrong. They're well known for
being absolutely *perfect* *bug-free* and *wonderful* ;-) ;-) :-)

Actually, if its not just something in the way DV is being handled I'd
bet on an mjpegtools problem.   There's really very little cdrdao or
vcdimager can to affect the relative sync of audio and video (that's
set by the original data-streams fed to mpeg2enc and mp2enc,
and then modified by mplex).

> Another question: I have several options in mplex (belongs to
> the mjpegtools) creating a SVCD. There is a default blocksize of
> 2324 bytes, but with vcdimager I can write them with 2336 or 2352
> Bytes, so what is recommended ? Shall I set the blocksize in
> mplex to 2336 ? Is it better to write 2336 size blocks with
> vcdimager ?

Roughly: the sector size mplex worries about is *payload* the size vcdimager
adds some extra info to this when building the image to burn.  2324 is the
right blocksize.

> Another thing is the number of buffers in mplex. In the manual it
> says it's important for playback. What are they for ?

If you've set standard SVCD output the buffer size assumed by
mplex will be correct.  If you're using "user-rate" SVCD then:

1) You need to specify the buffer size you're assuming for the player
(anything over 230KB is definately over the specification).

The size number is simply the size mplex *assumes* the decoder playing
the stream has.  More allows for more efficient handling of temporary bursts
of activitiy in the video.   Too much means the player can't play it at all!
If in doubt: 224KB.  N.b. you need to tell mpeg2enc this parameter too 
otherwise it can produce a stream mplex can't *fit* to the assumed buffer 
size. 

2) There's no guarantee the SVCD will be playable by every player!


        Andrew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]