On Tuesday 26 August 2003 20:14, Bernhard Praschinger wrote:
> Hallo
>
> I remember that I have changed that loop option. At least I applied the
> patch from a user to have that feature.
>
> I trie to answer all mails about that topic in one mail.
Might aswell. :)
> > Uh. That would mean cvs acce
Hallo
I remember that I have changed that loop option. At least I applied the
patch from a user to have that feature.
I trie to answer all mails about that topic in one mail.
> > Perfect, I would have proposed the same thing. I don't see any advantage
> > for the current behaviour as default ov
Hallo
> I also noticed that using either -f8 or -f9 that something wasn't quite right with
> some sort of timestamps. I did a 'mplayer test.m2v -ss 15:00' for example and that
> really took me about 45 minutes into the movie (maybe a little further). This
> worked when I encoded using the old
Hey Steven,
On Tue, 2003-08-26 at 18:00, Steven M. Schultz wrote:
> It'll probably take 24 hours for SF to catch up but perhaps Ronald
> will be creating a new release candidate tarball in a couple days
> or so.
I'll wait for Martin to commit some of his proposed fixes for other
On Mon, 25 Aug 2003, Steven M. Schultz wrote:
> Typo. The default limit for both formats (DVD and DVD-like)
> is 7500. For now rely on the usage summary (mpeg2enc -h) until
> the manpage is repaired.
I've fixed the manpage for mpeg2enc and the -f 8 and -f 9
On Tue, 26 Aug 2003, Scott Bigham wrote:
> [Hmm, this hasn't shown up on the list for twelve hours, so I'm assuming
> it got lost in the shuffle and resending it. We Apologize for the
> Inconvenience.(TM)]
SF is just backlogged - sometimes worse than other times. I've
seen s
On Mon, 25 Aug 2003, Ray Cole wrote:
> It went from 6 hours encoding a 2 hour movie to 24 hours (total time
> includes filters, which I did not change filters between tests).
> top shows mpeg2enc using 99% of the CPU (which I would expect). I
> don't see any dip in CPU usage so I don't believe
On Mon, 25 Aug 2003, Ray Cole wrote:
> Here's the command line I used on the old one vs the new:
>
> Old Command:
> nice mpeg2enc -f 8 -b ${aRate} -V 230 -n n -s -a 2 -g 6 -G 18 -I 0 \
>-r 24 -4 2 -2 2 -F 1 -p -v 0 -o ${aName}.m2v
>
> New Command:
> nice mpeg2enc -f 9 -b ${aRate}
On Tuesday 26 August 2003 12:07, Ronald Bultje wrote:
> Perfect, I would have proposed the same thing. I don't see any advantage
> for the current behaviour as default over the old behaviour.
Cool.
> I'll apply ... ehm... damn, I'm gone all week ('till monday). Please
> apply yourself or wait for
[Hmm, this hasn't shown up on the list for twelve hours, so I'm assuming
it got lost in the shuffle and resending it. We Apologize for the
Inconvenience.(TM)]
On Sun, Aug 24, 2003 at 12:09:03PM -0700, Steven M. Schultz wrote:
> On Sun, 24 Aug 2003, Scott Bigham wrote:
> > Actually, I'm probab
On Tue, 26 Aug 2003, Martin Samuelsson wrote:
> The man page has this to say:
>
>-l num
> Specifies the nummber of loops (default: 0 loops )
> When this option is not used the given range of images is only
> processed once. If you use this option and as
On Tuesday 26 August 2003 10:25, Ronald Bultje wrote:
> Interesting code in line 464 of jpeg2yuv.c:
>
> if (param->loop != 1)
>loops--;
>
> Somehow, I believe this is a typo and should read '-1' instead of '1'.
> Could you re-try with that change?
Could be. Just changing that line did
The help from the configure script no longer lists the --with-jpeg-mmx option,
even though it appears to still exist. If the script doesn't guess where
jpeg-mmx is, there is no error most users (especially those who don't know to
look) are going to notice. The result is no MMX jpeg, which is a pr
Hey Martin,
On Tue, 2003-08-26 at 10:11, Martin Samuelsson wrote:
[..]
Interesting code in line 464 of jpeg2yuv.c:
if (param->loop != 1)
loops--;
Somehow, I believe this is a typo and should read '-1' instead of '1'.
Could you re-try with that change?
Ronald
--
Ronald Bultje <[EM
On Tuesday 26 August 2003 08:22, Ronald Bultje wrote:
> Hey Martin,
>
> On Tue, 2003-08-26 at 01:33, Martin Samuelsson wrote:
> > With 1.6.0, I could give jpeg2yuv an absolute filename, and get the
> > expected output. With 1.6.1.90, it will go into a tight loop. Is there
> > any change I've overlo
It went from 6 hours encoding a 2 hour movie to 24 hours (total time includes filters,
which I did not change filters between tests). top shows mpeg2enc using 99% of the
CPU (which I would expect). I don't see any dip in CPU usage so I don't believe I'm
seeing a stall but am willing to try.
-
On 25 Aug 2003, Florin Andrei wrote:
Not sure if/when this'll make it out - SF's mail system apparently
has its knickers twisted. Sigh.
> So, when looking at the man pages for the release candidate, i noticed
> that "-f 9" is the new thing.
Ai. If you're making DV
Hey Martin,
On Tue, 2003-08-26 at 01:33, Martin Samuelsson wrote:
> With 1.6.0, I could give jpeg2yuv an absolute filename, and get the expected
> output. With 1.6.1.90, it will go into a tight loop. Is there any change I've
> overlooked?
-n 1, I suppose?
Ronald
--
Ronald Bultje <[EMAIL PROT
On Mon, 2003-08-25 at 09:58, Steven M. Schultz wrote:
> There were issues with mplex and mpeg2enc that caused problems
> (2GB limit, timestamps, etc) with some DVD players. Also some
> fixes were made to interoperate with dvdauthor - dvdauthor had
> some misassumptions about the MPEG2 header for
On Mon, 25 Aug 2003, William R Sherman wrote:
> Hmmm, I'd say that red&white are component audio, and yellow is composite
> video. (a bit off the topic of the subject I'll admit, but just thought
> I'd clarify.)
ARGH! Wow, did I ever get that reversed/wrong. Sigh, fingers
were
> I've found that doing as much as possible in 4:1:1 and converting
> to 4:2:0 at the last moment produces better looking output at
>
> If you have a recent ffmpeg on the system (do a 'make' but skip
> the 'make clean') then build the smilutils with something like:
>
>
Thanks for the reply (Stevens too :-)
> > I am too long of a good 10 minutes and I'd like to reduce the muxrate.
> D'oh! How long is that movie anyway? (timewise)
1h25...
> While i suspect that increasing -q will produce a similar decrease in
> space requirements, i'd rather try -N first.
I am
On Mon, 2003-08-25 at 16:50, Edouard Chalaron wrote:
> Hi
> There
> Trying to fit the unfitable What is the minimum muxrate acceptable for a
> DVD ?
> I am too long of a good 10 minutes and I'd like to reduce the muxrate.
D'oh! How long is that movie anyway? (timewise)
> So far I have been
Hi!
On Monday 25 August 2003 15:01, Ronald Bultje wrote:
> > abandoned that course when I was asked for libquicktime-devel, and found
> > out that the libquicktime people didn't have any official rpms for
> > download. The mjpegtools project can't be blamed for that, though.
>
> If I'm correct, usi
Hi
There
Trying to fit the unfitable What is the minimum muxrate acceptable for a
DVD ?
I am too long of a good 10 minutes and I'd like to reduce the muxrate.
So far I have been using the -f 8 standard but could a
mpeg2enc -f 3 -b 8000 -B 96 with mplex -r 8250 be Ok ?
Or should I go to mpeg2
25 matches
Mail list logo
