On Mon, 1 Nov 2004, Dik Takken wrote:
> > -q 4 is the practical limit with 5 being the usual value used.
>
> You mean that -q 4 can also trigger encoder bugs? I would like to get this
Ooops - I was unclear on that point. >= 4 is fine - by "practical
limit" I intended to sa
On Mon, 1 Nov 2004, Steven M. Schultz wrote:
On Mon, 1 Nov 2004, Dik Takken wrote:
Just something you might want to know about the DCT/iDCT overflow thing
(you might know it already): I managed to trigger this overflow problem at
-q 2 too. So, for braindead encoding purposes, -q 3 is the limit. May
On Mon, 1 Nov 2004, Dik Takken wrote:
> Just something you might want to know about the DCT/iDCT overflow thing
> (you might know it already): I managed to trigger this overflow problem at
> -q 2 too. So, for braindead encoding purposes, -q 3 is the limit. Maybe
For typical capture da
It seems to me that something must be wrong here. I use these
options for mpeg2enc:
... | mpeg2enc -f 8 -b 9500 -q 1 -a 3 -o output.m2v
Well - one thing that's wrong is using -q 1. Known, in some cases,
to suffer from DCT/iDCT overflow in the MMX/SSE code. Or are you
doing th
On Thursday 28 October 2004 20:21, Steven M. Schultz wrote:
> > I make them progressive when I send them to the MPEG encoder
>
> With yuvdeinterlace or similar processing? If it's really interlaced
> content then it won't work to simply tag it as progressive (but you
> knew that
On Thu, 28 Oct 2004, Steven M. Schultz wrote:
The other thing to look at is the output of 'mplex'. Mplex prints
out the "Average" and "Peak" rates. You can get those numbers fairly
quickly by specifying "-o /dev/null" to mplex:
mplex -f 8 -o /dev/null input.m2v
I have t
On Fri, 29 Oct 2004, James Bigler wrote:
> > That should have been 352x576 for 625line systems. the 352xN is
> > a valid DVD frame size that has worked well for me.
>
> Tell me more about this, please. You can encode an MPEG-2 stream with
> half the x resolution? I imagine you have
On Fri, 29 Oct 2004, James Bigler wrote:
One thing that has worked very well is to use the 1/2 encoded frame
size (352x480 for 525line systems and 352x288 for 625line systems).
That should have been 352x576 for 625line systems. the 352xN is
a valid DVD frame size
One thing that has worked very well is to use the 1/2 encoded frame
size (352x480 for 525line systems and 352x288 for 625line systems).
That should have been 352x576 for 625line systems. the 352xN is
a valid DVD frame size that has worked well for me.
Tell me more
On Fri, 29 Oct 2004, Steven M. Schultz wrote:
Argh - I shouldn't reply in haste between other tasks...
> One thing that has worked very well is to use the 1/2 encoded frame
> size (352x480 for 525line systems and 352x288 for 625line systems).
That should have been 3
On Fri, 29 Oct 2004, Dik Takken wrote:
> > Actually it is mentioned in the toplevel (mjpegtools) manpage:
> >
> > "A quality factor should be chosen that way that the mplex output of
> > Peak bit-rate and average bit-rate differ by about 20-25%\&...
>
> I read this manpage many times, but th
On Thu, 28 Oct 2004, Roman Shaposhnick wrote:
>I agree. But my point was to just draw attention to the fact that the line
>between progressive and interlaced is blurred. Especially when you don't
Well, bringing up "film" and "3:2" pulldown was perhaps not the
best way ;)
On Thu, 28 Oct 2004, Steven M. Schultz wrote:
Ah, that's an important detail. It might be a good thing if the man page
would be a bit more clear about this.
Actually it is mentioned in the toplevel (mjpegtools) manpage:
"A quality factor should be chosen that way that the mplex output of
Peak b
On Thu, 28 Oct 2004, Roman Shaposhnick wrote:
> > The one that causes dvdview to print "frame picture" or similar
> > info ;)
> That's the thing -- "frame picture" doesn't mean that your fields are
Well, take that with a grain of salt ;) I was going from (faulty)
mem
On Thu, Oct 28, 2004 at 08:31:12PM -0700, Steven M. Schultz wrote:
> On Thu, 28 Oct 2004, Roman Shaposhnick wrote:
>
> >Let's start from the very beginning -- you have your celluloid film,
> >that runs at 24fps, you scan it and you want to encode result onto
> >the NTSC DVD where the
On Thu, Oct 28, 2004 at 08:46:13PM -0700, Steven M. Schultz wrote:
>
> On Thu, 28 Oct 2004, Roman Shaposhnick wrote:
>
> > On Thu, Oct 28, 2004 at 09:28:28AM -0700, Steven M. Schultz wrote:
> > > Or rather, as I should have added: if you do take the two fields
> > > from the same point in tim
On Thu, 28 Oct 2004, Roman Shaposhnick wrote:
> On Thu, Oct 28, 2004 at 09:28:28AM -0700, Steven M. Schultz wrote:
> > Or rather, as I should have added: if you do take the two fields
> > from the same point in time then the encoder should set the flags
> > in the MPEG output stream s
On Thu, 28 Oct 2004, Roman Shaposhnick wrote:
>Let's start from the very beginning -- you have your celluloid film,
>that runs at 24fps, you scan it and you want to encode result onto
>the NTSC DVD where the frame rate is 30fps (or 3/1001). Obviously
Actually they run the
On Thu, Oct 28, 2004 at 09:28:28AM -0700, Steven M. Schultz wrote:
> > > You don't want to take two fields from the same point in time.
>
> Or rather, as I should have added: if you do take the two fields
> from the same point in time then the encoder should set the flags
> in
On Thu, Oct 28, 2004 at 09:04:26AM -0700, Steven M. Schultz wrote:
>
> On Thu, 28 Oct 2004, Dik Takken wrote:
>
> > > 1: 50 full-resolution images per second.
> > > 2: 25 full-resolution images per second.
> >
> > That would be number 2 in my case :)
>
> Ok - good, then mpeg2enc will do a
On Thu, Oct 28, 2004 at 08:57:28AM -0700, Steven M. Schultz wrote:
> > 3: Something completely different.
> >
> > In case 3: What? :)
>
> There's no case 3. Cases 1 and 2 cover all the possibilities - either
> the data is interlaced or it is progressive, I can't imagine an third
>
On Thu, 28 Oct 2004, Dik Takken wrote:
> > By the time the encoder detects that the rate is too high and adjusts
> > the effective -q the rate spike has already been passed to the output...
>
> Ah, that's an important detail. It might be a good thing if the man page
> would be a bit mo
But, the way mpeg2enc prevents the encoded data from going over that
9800 max (for VBR encoding) is by silently increasing the effective
-q value for you behind the scenes. So for the peaks, to keep the
True, BUT - it is NOT "instantaneous"! By the time the encoder
detects that the r
On Thu, 28 Oct 2004, Martin Samuelsson wrote:
> It could be. It depends on one's intentions. Technically, I believe we could
> agree that it is, in fact, a progressive stream distributed in an interlaced
> container. (Which doesn't make much sense, unless you're distributing the
That'
On Thursday 28 October 2004 17:57, Steven M. Schultz wrote:
> > This is
> > what the purists call an interlaced stream.
>
> It's not just what "purists" call an interlaced stream - it is an
> interlaced stream ;)
"Purist" in the nicest possible way, of course. Yes, it's interlaced.
>
On Thu, 28 Oct 2004, Dik Takken wrote:
> Quote from the mpeg2enc manual, -b option:
I replied earlier to that portion of the thread. In essence the
rate limiting is not instantaneous and spikes (sometimes considerably
higher than the -b value) get thru. The lower the -q
On Thu, 28 Oct 2004, Dik Takken wrote:
> > 1: 50 full-resolution images per second.
> > 2: 25 full-resolution images per second.
>
> That would be number 2 in my case :)
Ok - good, then mpeg2enc will do all the necessary work for you.
> > In case 2, however, you've got to do the same t
On Thu, 28 Oct 2004, Martin Samuelsson wrote:
> Dik, what are you generating? Your choices are these:
>
> 1: 50 full-resolution images per second.
> 2: 25 full-resolution images per second.
>
> In case 1, Steven is correct, you should take all odd-numbered (if starting at
> 1) lines of image 1
On Thu, 28 Oct 2004, Richard Ellis wrote:
> On Thu, Oct 28, 2004 at 12:26:24PM +0200, Dik Takken wrote:
> > Quote from the mpeg2enc manual, -b option:
> >
> > "If variable bit-rate mode has been selected (see the -q option)
> > this is the maximum bit-rate of the stream."
> >
> > So, the "-b"
On Thu, Oct 28, 2004 at 12:26:24PM +0200, Dik Takken wrote:
> Quote from the mpeg2enc manual, -b option:
>
> "If variable bit-rate mode has been selected (see the -q option)
> this is the maximum bit-rate of the stream."
>
> So, the "-b" value is not the average, but the upper limit when
> "-q"
On Wed, 27 Oct 2004, Steven M. Schultz wrote:
that I don't care about filesize, as long as my stand-alone DVD player
will play it. The only restriction I need for that is to use -f 8 and -b <
9700 IIRC.
Oh, it's not just the filesize or AVERAGE bitrate that's going to
be the problem. I
On Thu, 28 Oct 2004, Martin Samuelsson wrote:
On Thursday 28 October 2004 01:45, Steven M. Schultz wrote:
The frames that I feed to mpeg2enc are actually not interlaced, they are
ordinary 'progressive' images. But since I use png2yuv to generate an
Ok - that's what I figured. Now to interlace
On Thursday 28 October 2004 01:45, Steven M. Schultz wrote:
> > The frames that I feed to mpeg2enc are actually not interlaced, they are
> > ordinary 'progressive' images. But since I use png2yuv to generate an
>
> Ok - that's what I figured. Now to interlace that you need to take
> th
On Thu, 28 Oct 2004, Dik Takken wrote:
> Sorry, lame mistake. Rephrase:
:)
> Ok, thanks for pointing that out. Should -q 2 be safe enough? The thing is
It might be. And you might be lucky enough to not encounter the
artifacting - it's dependent on the material to a de
On Wed, 27 Oct 2004, Steven M. Schultz wrote:
On Wed, 27 Oct 2004, Dik Takken wrote:
I noticed something strange while playing with mpeg2enc. When I encode a
sequence of frames to progressive mpeg2, the output quality is *much*
better than when I encode the same image sequence to progressive mpeg2.
On Wed, 27 Oct 2004, Dik Takken wrote:
> I noticed something strange while playing with mpeg2enc. When I encode a
> sequence of frames to progressive mpeg2, the output quality is *much*
> better than when I encode the same image sequence to progressive mpeg2.
Something does not
Hello,
I noticed something strange while playing with mpeg2enc. When I encode a
sequence of frames to progressive mpeg2, the output quality is *much*
better than when I encode the same image sequence to progressive mpeg2.
It seems to me that something must be wrong here. I use these
options for
37 matches
Mail list logo
