On Sat, 16 Aug 2003, Maik Holtkamp wrote:

> I already had a discussion on the dvdauthor list
> (http://sourceforge.net/mailarchive/forum.php?thread_id=2942599&forum_id=13261)
> on this topic, so sorry if doubled for someones.

        I'll give the same advice here that I've given in the past on
        the dvdauthor list:

                Use a single file.

        More about why this is necessary later on.

> I tried to make dvd5 from my dvd9. It is no problem when I use one
> big file, but it will facilitate things here, if I could just use
> chaptering:
        
        That is not the way DVDs work ;(

        DVDs are _track_ oriented.  Each file goes into a track (sometimes
        called a "title or titleset").   Chapters within a title/chapter
        play seamlessly as you have discovered - but transitioning across
        a track boundary is not seamless.

> transcode -i /dev/dvd -T 1,$I -x auto,null -V -y mpeg2enc,null -F
> 8,"-c -b 8000 -q 6" -o track$I                            [1][2]
> 
> Viewing the single streams with mplayer I receive at the end of
> _some_ streams:
> 
> a52: CRC check failed
> a52: error at resampling

        I believe that is harmless and simply means the last few bytes
        of an audio packet were not written out to the file.

> As I have some problems when authoring the DVD from single files to
> the effect that the picture at _every_ new chapter get frozen for some
> ms, I am interessted if this issue is probably base on mpec2enc or

        Each file goes into a separate track/title.    Jumping from
        the end of one track to another is not the same as playing thru
        one chapter into another within a single track.

        There is nothing mpeg2enc can do about the situation.   It is
        an authoring tool and/or DVD design issue.    dvdauthor would
        need to add a "jump to track N+1" at the end of track N - and I
        am not sure if that would be seamless or have a brief pause.  I 
        believe there would be a brief pause - have you ever noticed that
        at the end of a movie there is a brief pause before the next menu
        gets displayed again?   I think that is the "seek to next track"
        happening.

        Using large files and chapters really is the way to create a DVD.

> [1] In spite of really understanding what -c is for, man page sounds
>     promissing for me.

        Are you creating DVDs with multiple angles in the video stream?
        If that is not what you are doing then do not use '-c'.  Creating
        closed gops increases the size of the file by a small amount
        (~1%) but does not change how tracks and chapters work.
        
        The primary use of -c is to create video streams suitable for
        multi-angle DVDs.   Oh, and it is required that all video streams
        have the same GOP size for all the angles - thus using -g and -G
        to set a fixed GOP size will also be necessary.

> [2] Is there any chance to roughly estimate how the resulting
>     file-size will be reduced when:
>     decreasing -b for 100
>     increasing -q for 1
>     in variable bitrate encoding? Or is there a other option I sould
>     use in order to get more predictable results?

        -b sets the maximum (+/- a couple percent of course) rate
        (filesize).   This is the upper bound on filesize.  Use the
        value of -b, add the audio rate, and then add about 2.5% for the
        other information written to the stream.   Use that total and
        multiply by the playing time - that is the maximum size of the
        file.   Then vary -q according to the desired quality (lower -q
        values will cause the file to more closely approach the max
        filesize).
        
        As an alternative use constant bitrate encoding ;)   Leave off the
        -q and simply specify the bitrate according to the desrired 
        filesize.

        What I often do is encode a representative sample, between 5 and
        10 minutes worth of data, and extrapolate the final size of the
        file.    

        To partially answer the question decreasing -b by 100 will
        decrease the filesize by 100/8 or 12.5kbytes per second.  Multiply
        by the number of seconds of course :)

        The effect of -q is data sensitive and there is not a fixed/firm
        relationship between increasing -q by 1.  I have seen in some
        cases going from 5 to 6 a change in the average bitrate around 15%
        but that varies from run to run depending on the data.

        Cheers,
        Steven Schultz  



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to