On 4 Jan 2004, Florin Andrei wrote:
> > Are you sure that was the cause or was it pusing the bitrate too high
> > and generating streams out of spec on the peaks? As I recall the
> > stuttering was caused by -b 9000.
>
> Ok, i can't reproduce the problem now, and i'm using 8500 kbps, so
> perh
On Sun, 2004-01-04 at 17:23, Steven M. Schultz wrote:
> On 4 Jan 2004, Florin Andrei wrote:
>
> > MPEG2 without B frames makes some DVD players choke. The default
>
> What player is so braindamaged and standards non-compliant as to
> choke on an *optional* part of the MPEG-2 specs? (B frames ar
On 4 Jan 2004, Florin Andrei wrote:
> MPEG2 without B frames makes some DVD players choke. The default
What player is so braindamaged and standards non-compliant as to
choke on an *optional* part of the MPEG-2 specs? (B frames are
optional).
Are you sure that
On Fri, 2004-01-02 at 16:29, Steven M. Schultz wrote:
> Actually most of the speed up was done by changing the defaults to
> omit B frames ("-R 0")
I do not agree with that decision.
MPEG2 without B frames makes some DVD players choke. The default
settings should attempt to be "safe" and should n
On Sat, 2004-01-03 at 18:47, Steven M. Schultz wrote:
>
> Hmmm, which automake do you have?
Both 1.4 and 1.7. Due to the mixture of requirements out there,
Mandrake includes both. I am not sure if their automake is s'posed to
work the same way, but their autoconf is actually only a wrappe
On Sat, 3 Jan 2004, Brian J. Murrell wrote:
> Except that for some reason any version of automake that I have here
> barfs on the indentation of variable assignments in some of mpeg4ip's
Hmmm, which automake do you have? I'd been using 1.7.3 for a long
time with good results.
On Sat, 2004-01-03 at 00:58, Steven M. Schultz wrote:
>
> As the toolbox is becomes more complete the management gets simpler.
Assuming the tools are all interchangeable. It's when you have some
software that wants automake 1.4 and others than want 1.6/7 and some
software wants one version
On Sat, 3 Jan 2004 [EMAIL PROTECTED] wrote:
> I have just ommitted the "--tag=CC" option from the call to libtool
> in the files utils/mmxsse/Makefile and mpeg2enc/Makefile and then
> compilation went ok. Should I expect any problem with the software
> as a consequence of that? mpeg2enc and mplex
On Sat, 3 Jan 2004 [EMAIL PROTECTED] wrote:
> I do not think 1.6.1.92 is that old. If I am not wronk, it has been
> released by the end of November.
Maybe it just _feels_ old ;) Seems that the next release candidate
has been "real soon now" for a long time.
> spead things up.
On Fri, Jan 02, 2004 at 04:29:54PM -0800, Steven M. Schultz wrote:
>
> On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote:
>
> > Currently I am using mjpegtools 1.6.1.92 to convert movies to
> > SVCD. How faster is the CVS version compared to the version I
> > have installed? Is it stable for SVCD produc
On Fri, Jan 02, 2004 at 05:19:41PM -0800, Steven M. Schultz wrote:
>
> On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote:
[...]
> > Now make fails:
>
> With a libtool related error.
>
> > /bin/sh ../../libtool --mode=compile --tag=CC /bin/sh ../../strip_fPIC.sh
> > /usr/bin/nasm -f elf -o mblock
Hi Steven,
On Sat, 2004-01-03 at 01:49, Steven M. Schultz wrote:
> No, there was a bug in configure.in that caused autoheader to never
> be run.
That was not a bug. ;). It was added by Bernhard some time ago. I forgot
why.
Ronald
--
Ronald Bultje <[EMAIL PROTECTED]>
Linux Video/Mul
On Sat, 3 Jan 2004, Brian J. Murrell wrote:
> The actual build, once you got everything right, yes you are right.
> It's the management of "this depends on that, so build that, which
As the toolbox is becomes more complete the management gets simpler.
> depends on the other so build th
On Fri, 2004-01-02 at 15:29, Steven M. Schultz wrote:
>
> If a couple minutes to save hours of encoding time doesn't make it
> worth the small amount of time then nothing will.
The actual build, once you got everything right, yes you are right.
It's the management of "this depends on
On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote:
> > No, there was a bug in configure.in that caused autoheader to never
> > be run.
> >
> > catches up in a couple hours) work around the bug by running
> > 'autoheader' manually. Then config.h.in will be generated and
>
> That worke
On Fri, Jan 02, 2004 at 04:49:15PM -0800, Steven M. Schultz wrote:
>
> On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote:
>
> > Decided to try the CVS version. Fetched the mjpeg_play module.
> > But ./autogen.sh fails with the error:
> >
> > [...]
> > config.status: creating mjpegtools.spec
> > config.
On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote:
> Decided to try the CVS version. Fetched the mjpeg_play module.
> But ./autogen.sh fails with the error:
>
> [...]
> config.status: creating mjpegtools.spec
> config.status: creating config.h
> config.status: error: cannot find input file: config.h.in
On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote:
> Currently I am using mjpegtools 1.6.1.92 to convert movies to
> SVCD. How faster is the CVS version compared to the version I
> have installed? Is it stable for SVCD production? I am thinking
> about installing it and trying it.
It's been so
On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote:
> Decided to try the CVS version. Fetched the mjpeg_play module.
> But ./autogen.sh fails with the error:
>
> [...]
> config.status: creating mjpegtools.spec
> config.status: creating config.h
> config.status: error: cannot find input file: config.h.in
On Fri, Jan 02, 2004 at 11:28:23AM -0800, Steven M. Schultz wrote:
>
> On Fri, 2 Jan 2004, Brian J. Murrell wrote:
>
> > Perhaps with the CVS version that is the case, but historically, I have
>
> cvs update works wonders ;)
Decided to try the CVS version. Fetched the mjpeg_play module.
B
On Fri, Jan 02, 2004 at 12:29:33PM -0800, Steven M. Schultz wrote:
>
> On Fri, 2 Jan 2004, Brian J. Murrell wrote:
>
> > Indeed, if you have the time to manage software in such a manner.
>
> If a couple minutes to save hours of encoding time doesn't make it
> worth the small amount o
On Fri, 2 Jan 2004, Brian J. Murrell wrote:
> Indeed, if you have the time to manage software in such a manner.
If a couple minutes to save hours of encoding time doesn't make it
worth the small amount of time then nothing will.
> MP4 containers huh? I will have to take a look.
Hi Brian,
On Fri, 2004-01-02 at 21:06, Brian J. Murrell wrote:
> MP4 containers huh? I will have to take a look. Do they overcome 2G
> file limitations?
MP4 = quicktime, IIRC, so yes.
Ronald
--
Ronald Bultje <[EMAIL PROTECTED]>
Linux Video/Multimedia developer
On Fri, 2004-01-02 at 14:28, Steven M. Schultz wrote:
> cvs update works wonders ;)
Indeed, if you have the time to manage software in such a manner.
> I put the stuff into MP4 containers with AAC audio and MPEG4 video.
MP4 containers huh? I will have to take a look. Do they overco
On Fri, 2 Jan 2004, Brian J. Murrell wrote:
> Perhaps with the CVS version that is the case, but historically, I have
cvs update works wonders ;)
> not been able to get more than 5fps with mpec2enc whereas libavcodec
> gives me closer to 20fps.
Part of that is that ffmpeg/menco
On Fri, 2004-01-02 at 12:54, Steven M. Schultz wrote:
>
> Then you'll also have seen
I just tuned in in the last couple of days, so I haven't seen much.
> that the speed difference isn't as
> great has been bandied about at times (well, at least for the
> cvs version - RC4's d
On Fri, 2 Jan 2004, Ronald Bultje wrote:
>
> It's indeed mpeg, and a system stream (so a muxed mpeg file, not an
> elementary video stream). You need to demux them in some way. I don't
> know how to do that with mplayer/ffmpeg. With GStreamer, it's
> "gst-launch filesrc location=file.mpg ! mpegde
On Fri, 2 Jan 2004, Brian J. Murrell wrote:
> Indeed. I have seen some of your traffic on the ffmpeg-devel list.
Then you'll also have seen that the speed difference isn't as
great has been bandied about at times (well, at least for the
cvs version - RC4's delayed until
Hi Brian,
On Fri, 2004-01-02 at 16:10, Brian J. Murrell wrote:
> I don't think so. Mplayer tells me this about the file (if there is a
> better utility to determine the parameters of an MPEG file, I would be
> more than glad to use it rather than mplayer):
[..]
> system stream synced at 0xB (0)!
On Fri, 2004-01-02 at 02:01, Steven M. Schultz wrote:
>
> Hmmm, I knew ffmpeg
Indeed. I have seen some of your traffic on the ffmpeg-devel list.
> had mpeg1 encoding capability (from libavcodec)
> and it can, if you say the right magic words, produce MPEG1
> ES (Elemental Str
On Thu, 1 Jan 2004, Brian J. Murrell wrote:
> I am using mencoder (libavcodec in reality I guess) to create an mpeg1
Hmmm, I knew ffmpeg had mpeg1 encoding capability (from libavcodec)
and it can, if you say the right magic words, produce MPEG1
ES (Elemental Stream) files
I am using mencoder (libavcodec in reality I guess) to create an mpeg1
video stream but when I try to use mplex to mux it with the audio, I get
the following:
INFO: [mplex] mplex version 2.2.2 ($Date: 2003/05/13 20:27:15 $)
**ERROR: [mplex] File test.mpeg1 unrecogniseable!
INFO: [mplex] File
32 matches
Mail list logo
