The MJPEG/Linux square

On Thu, 28 Aug 2003, Gernot Ziegler wrote:

> This is already being discussed here on the list, right ?  :-)

	Yes, it has been discussed at great length in recent weeks :)

	The "hype" on Kvcd.Net's site should be discounted somewhat
	though.   The the bitrate savings are substantial in some
	cases.  However  the "6 hours with goodquality at 720x480" is,
	from what I have seen, not correct.   Using the 1/2 resolution
	(352x480) it might be possible though (or perhaps my idea of
	"good quality" is just too high ;)).

> Ben, please join this list and read the recent archives, I guess they
> contain some good info on this :-)

	By all means join and yes, the recent archives will have much
	to say about the "Quantization Matrix".

> I am wondering if it would be possible for you to either compile a special
> "KVCD" version of mpeg2enc, or somehow allow for an option to change the

> "Quantization Matrix". If this already exists, I apologize for missing it,
> but could you explain how to use the feature.


	The release candidate has the capability to use the KVCD
	tables.   Also present (and the archives should contain mention
	of this also) is the ability to use the TMPGEnc matrices if
	desired.

	The manpage for mpeg2enc contains the info (hint: -K ;)).

	Cheers,
	Steven Schultz

On 8/28/03 8:52 AM, "Steven M. Schultz" <sms@...> wrote:

> By all means join and yes, the recent archives will have much
> to say about the "Quantization Matrix".

Just did :)

> The release candidate has the capability to use the KVCD
> tables.   Also present (and the archives should contain mention
> of this also) is the ability to use the TMPGEnc matrices if
> desired.
> 
> The manpage for mpeg2enc contains the info (hint: -K ;)).

Where can I find the manpage? I tried downloading the docs, but it is for
mjpeg. I also downloaded the source for mpeg2enc and compiled it, but didn't
see any man pages in that setup as well.

Thanks,
Ben

http://www.shayufilms.com

On Thu, 28 Aug 2003, Ben Mackin wrote:

> Where can I find the manpage? I tried downloading the docs, but it is for
> mjpeg. I also downloaded the source for mpeg2enc and compiled it, but didn't
> see any man pages in that setup as well.

	http://mjpeg.sourceforge.net/ 

	Under Downloads you'll find "Tarballs".   That will bring up
	a long list of files (most of which are obsolete) from
	http://unc.dl.sourceforge.net/mjpeg/

	The ones you'll be interested in are dated August 23 and begin
	with:

		mjpegtools_1.6.1.90

	There is the usualy .src.tar.gz file but also present are
	rpms.  

	Alternatively check out a copy from CVS - that makes it easy to
	pick up fixes in the future.   The usual instructions are found
	at https://sourceforge.net/cvs/?group_id=5776

	A quick way to get a summary is "mpeg2enc -h" to get the usage()
	statement - think of that as a "quick reference guide to the
	options" ;)

	Steven Schultz

Hi!
On Thursday 28 August 2003 11:52, Steven M. Schultz wrote:
> On Thu, 28 Aug 2003, Gernot Ziegler wrote:
> > This is already being discussed here on the list, right ?  :-)
>
> 	Yes, it has been discussed at great length in recent weeks :)
>
> 	The "hype" on Kvcd.Net's site should be discounted somewhat
> 	though.   The the bitrate savings are substantial in some
> 	cases.  However  the "6 hours with goodquality at 720x480" is,
> 	from what I have seen, not correct.   Using the 1/2 resolution
> 	(352x480) it might be possible though (or perhaps my idea of
> 	"good quality" is just too high ;)).

Yes, probably this is the difference - what is a good quality :-)

I saw The Lord Of The Rings (Fellowship of the Ring) that was prepared with 
KVCD settings at 704x480 resolution MPEG1 with stereo 48kHz audio and was 
burned as VCD (my Philips DVD 724 can play this perfectly). It took just 2 
CD, ~ 1,6Gb. And this is 3 hours movie...

Compression quality was excellent (no squares and any other compression 
artefacts were present) BUT seems that lots of filters were applied to the 
stream before compression - image almost didn't have small details. It was 
compared to 352x288 (viewing fullscreen on computer at 1024x768) except 
upscaling artefacts were not visible. It looks very good on TV, just it is a 
bit too smooth.

So, I definetely believe that it is possible to put 6 hours at 720x480 in 
4,7Gb because it is possible to put 3 hours at 704x480 in 1,6Gb. And with a 
better quality that these CDs (you'll have about 50% more space for quality 
improvements - to add details). It is just a question of the filtering...

	Alexei

When trying to run a clip I have through mpeg2enc, I get the following:

[ben-computer:~] kupan787% mpeg2enc -K kvcd -f 8 -o /here.m2v
/Volumes/60GB/sampleRun.mov
**ERROR: [mpeg2enc] Could not read YUV4MPEG2 header: bad header magic!
[ben-computer:~] kupan787%

Is there a specific input file type I have to use? I have only "used"
mpeg2enc through ffmpeg, and that was using one of the presets that is built
in to ffmpeg, so I don't totally know what can and can't be passed though.

I tried reading through the man page (which I found, yea!), but didn't see
any mention of a specific input file type.

Thanks,
Ben

http://www.shayufilms.com

Hallo

> When trying to run a clip I have through mpeg2enc, I get the following:
> 
> [ben-computer:~] kupan787% mpeg2enc -K kvcd -f 8 -o /here.m2v
> /Volumes/60GB/sampleRun.mov
> **ERROR: [mpeg2enc] Could not read YUV4MPEG2 header: bad header magic!
> [ben-computer:~] kupan787%
> 
> Is there a specific input file type I have to use? I have only "used"
> mpeg2enc through ffmpeg, and that was using one of the presets that is built
> in to ffmpeg, so I don't totally know what can and can't be passed though.
> 
> I tried reading through the man page (which I found, yea!), but didn't see
> any mention of a specific input file type.
Than try reading the general help: man mjpegtools
Or the html version on mjpeg.sf.net in the doc area. 

mpeg2enc cannot open a file. And only understands yuv with some mor
header inforamtion. 

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: shadowlord@... bernhard.praschinger@...
www: http://www.lysator.liu.se/~gz/bernhard

On Thu, 28 Aug 2003, Gert Wollny wrote:

> Hello, 
> 
> attached is a patch, that resolves two issues I had with the mplex
> program: 
> 
> 2. Makefile.am
>    g++ should link stdc++ automatically, therefore, it is not

	I have seen that too and it did not feel right (did not hurt
	anything but still looked out of place).

> 4. vector.(cc|hh)     
>    -for some reason the original implementation segfaults when
>     compiled with icc - therefore, i propose to replace the C-array
>     by a std::vector. With this the allocated data is freed, when

	The changes were checked in to CVS about 2 minutes ago.

	Cheers,
	Steven Schultz

In article <1061652312.31305.41.camel@...>,
Ronald Bultje  <rbultje@...> wrote:
>some distros be in other places. **PLEASE** let me know whether the
>location is /sbin/ in your distro and whether it works at all. This is

/usr/bin/install-info

I don't know why it would EVER be under /usr/sbin, much list /sbin.

What, I don't want to install stuff into my home directory as a normal
user?

This kind of stupid decision probably comes from the same idiots who put
pidof into sbin.

mrc
-- 
     Mike Castle      dalgoda@...      http://www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Mike Castle wrote:
> 
> In article <1061652312.31305.41.camel@...>,
> Ronald Bultje  <rbultje@...> wrote:
> >some distros be in other places. **PLEASE** let me know whether the
> >location is /sbin/ in your distro and whether it works at all. This is
> 
> /usr/bin/install-info
> 
> I don't know why it would EVER be under /usr/sbin, much list /sbin.
Good question. In my system it is in /sbin. I'd just make a test if it
is aviable. Else do no install the info doku. 

One wild guess: Or maybe there is some doku (LSB) that says you can
expect that install-info (and other files) in certain locations. 

> What, I don't want to install stuff into my home directory as a normal
> user?
> 
> This kind of stupid decision probably comes from the same idiots who put
> pidof into sbin.
There was as discussion about that install-info place some (26.Feb.03)
time ago. 
It seems that newer distribution place that install-info in sbin. And
the normal user has that path not in the PATH env variable. If you add
it manually install-info works well. 

I'm not soure (as I was in Feb) if this is behavior good or bad. 

At least the Suse 8.2 that that pidof in a place where every user can
use it. But the install-info it in a sbin direcotry and that directory
is not in the PATH env variable. 

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: shadowlord@... bernhard.praschinger@...
www: http://www.lysator.liu.se/~gz/bernhard

Hey,

On Tue, 2003-08-26 at 19:01, Bernhard Praschinger wrote:
> Good question. In my system it is in /sbin. I'd just make a test if it
> is aviable. Else do no install the info doku. 

That check is (fortunately) already there.

However, we need to check in more places than just /sbin/ for
install-info, that's all...

Ronald
-- 
Ronald Bultje <rbultje@...>

Hey,

On Tue, 2003-08-26 at 04:00, Mike Castle wrote:
> In article <1061652312.31305.41.camel@...>,
> Ronald Bultje  <rbultje@...> wrote:
> >some distros be in other places. **PLEASE** let me know whether the
> >location is /sbin/ in your distro and whether it works at all. This is
> 
> /usr/bin/install-info

Crap. OK, I'll do some autotools magic then.

*rant*

What distro is this anyway?

Ronald

-- 
Ronald Bultje <rbultje@...>

Hi James,

On Sat, 2003-08-23 at 20:02, James Klicman wrote:
> What is the CVS tag to the release candidate branch? I was hoping to
> modify the AltiVec source before the next release so that gcc-3.2+ was
> able to compile it.

It has no tag, it's just HEAD/CVS. The final 1.6.2 will be tagged as
MJPEGTOOLS_1_6_2.

Ronald

-- 
Ronald Bultje <rbultje@...>

Hi Ronald,

I get a link error for yuv2lav on Yellowdog 3.0. The yuv2lav binary
needs -lm to link.

The Makefile diff reveals that SDL_LIBS contains -lm on i386, but not on g4.

diff i386:lavtools/Makefile g4:lavtools/Makefile
< SDL_LIBS = -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread -lm -L/usr/lib -ldl 
-lartsc -DPIC -fPIC -lpthread -L/usr/lib -lesd -laudiofile -lm -L/usr/X11R6/lib 
-lX11 -lXext -lXxf86vm -lXxf86dga -lXv -ldl
---
> SDL_LIBS = -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread


Looks like -lm needs to be explicitly added for yuv2lav instead of
inheriting it from SDL.

-James


gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/home/james/mjpeginst/include -DG_LOG_DOMAIN=\"lavtools\" -DLAVPLAY_VERSION=\"1.6.1.90\"    -I/usr/X11R6/include -I /usr/X11R6/include -I../utils -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include     -g -O2 -Wall -Wunused -c `test -f 'yuv2lav.c' || echo './'`yuv2lav.c
/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -Wunused   -o yuv2lav  yuv2lav.o  ../utils/libmjpegutils.a liblavfile.la liblavjpeg.la 
gcc -g -O2 -Wall -Wunused -o .libs/yuv2lav yuv2lav.o  ../utils/libmjpegutils.a ./.libs/liblavfile.so ./.libs/liblavjpeg.so /usr/lib/libjpeg.so -Wl,--rpath -Wl,/home/james/mjpeginst/lib
yuv2lav.o(.text+0x78c): In function `main':
/home/james/mjpegtools-1.6.1.90/lavtools/yuv2lav.c:424: undefined reference to `ceil'
yuv2lav.o(.text+0x78c):/home/james/mjpegtools-1.6.1.90/lavtools/yuv2lav.c:424: relocation truncated to fit: R_PPC_REL24 ceil
yuv2lav.o(.text+0x7c4):/home/james/mjpegtools-1.6.1.90/lavtools/yuv2lav.c:424: undefined reference to `ceil'
yuv2lav.o(.text+0x7c4):/home/james/mjpegtools-1.6.1.90/lavtools/yuv2lav.c:424: relocation truncated to fit: R_PPC_REL24 ceil
yuv2lav.o(.text+0xc1c):/home/james/mjpegtools-1.6.1.90/lavtools/yuv2lav.c:291: undefined reference to `ceil'
yuv2lav.o(.text+0xc1c):/home/james/mjpegtools-1.6.1.90/lavtools/yuv2lav.c:291: relocation truncated to fit: R_PPC_REL24 ceil
collect2: ld returned 1 exit status
make: *** [yuv2lav] Error 1

Hey,

On Sat, 2003-08-23 at 23:18, James Klicman wrote:
> I get a link error for yuv2lav on Yellowdog 3.0. The yuv2lav binary
> needs -lm to link.

Thanks, fixed. I'm assuming this means all other things worked fine? :).

Ronald

-- 
Ronald Bultje <rbultje@...>

I've found that the GCC 3.2 and even 3.3.1 compilers have serious bugs
related to AltiVec. The mjpegtools AltiVec code compiles with 3.2 but
the binary output is broken. The 3.3.1 compiler segfaults and crashes. It
looks like 3.3.2 may work, but it's not released yet. For Linux the best
AltiVec compiler is still the AltiVec-enabled GCC 2.96.4.

Anyway, I'll update CVS. At least when GCC 3.3.2 is released the
AltiVec code will be ready for it.

-James

Hi Ronald,

The version number 1.6.1.90 causes a compile failure on MacOS X. This
should not be an issue for the final release since the version number
will be changed to 1.6.2.

-James

/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -Wunused   -o liblavfile.la -rpath /usr/local/lib -version-info 1.90:1.90:1.90 -release 1.6 -export-dynamic      editlist.lo lav_io.lo avilib.lo  
../libtool: test: 1.90: integer expression expected
expr: non-numeric argument
expr: non-numeric argument
gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/liblavfile-1.6..1.90.1.90.dylib  .libs/editlist.o .libs/lav_io.o .libs/avilib.o  -install_name  /usr/local/lib/liblavfile-1.6..dylib -compatibility_version  -current_version .1.90
gcc: .1.90: No such file or directory
make[2]: *** [liblavfile.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Ronald Bultje wrote:
> I've put up RPMs+tarball for mjpegtools-1.6.2 release candidate 1
> (versioned as 1.6.1.90, because that makes packaging easier) on
> sourceforge. This is a feature enhancement and bugfix release compared
> to 1.6.1. Most importantly, this release allows full-fledged DVD
> creation. Also, we now depend on libquicktime and we suggest using
> mplayer for divx encoding, so we have removed the quicktime4linux and
> avifile depdendencies. This should fix nearly 90% of all build failures.
> there are also smaller fixes, but I won't go into them here.
> 

This release looks great.  DVD creation will certainly prove useful.

Is two-pass encoding in mpeg2enc on the cards anytime soon? (I see it's 
mentioned in the TODO)

Greg

Hi!
This version seems to work fine for me. I've compiled it from your src.rpm on 
RH9.

I just have a couple of small notes on documentation for mpeg2enc: it has some 
typos that probably is better to fix before release.

1) mpeg2enc --help
...
--format|-f fmt
    Set pre-defined mux format fmt.
    [0 = Generic MPEG1, 1 = standard VCD, 2 = VCD,
     3 = Generic MPEG2, 4 = standard SVCD, 5 = user SVCD,
...
--video-buffer|-V num
    Target decoders video buffer size in KB (default 46)
...

Probably 2 should be "2 = user VCD". And I'm not sure about video buffer size 
- I always thought that it is dependant on selected format.

2) man mpeg2enc
...
       -f|--format 3      -    Generic MPEG2.

       A  basic  MPEG-1 profile that lets most parameters be adjusted for par-
...

Shouldn't this be "A basic MPEG-2 profile..."?

...
       -K|--custom-quant-matriceskvcd|tmpgenc|default|hi-res|file=inputfile|he
       lp Specify which quantization matrices to use instead of  the  defaults
       (which  can be specified by using "-K default").   Using "-K hi-res" is
       identical to using the -H option.   The value kvcd  uses  the  Kvcd.Net
       matrices  from  http://www.kvcd.net  and  the value tmpgenc invokes the
       TMPGEnc matrices from http://www.tmpgenc.net/e_main.html.   On  average
       (and  it  is  somewhat  source  material  dependent) the tmpgenc tables
       reduce the average bitrate about 10% and the kvcd tables about 16% com-
       pared to the default tables.
...

This paragraph is very strange - missing spaces, unexpected linebreaks etc.
Probably words about kvcd matrix should be a bit different - to avoid any 
problems. What they say on their site:

"The KVCD "Notch" Quantization matrix may be used on any hardware or software 
encoder capable of accepting custom tailored matrixes.
 It is optimized for space/quality, and has also been optimized to reduce 
visible DCT blocks on low lit/dark scenes. 
 The KVCD "Notch" Quantization Matrix is Copyright (c) 2002, 2003 of Softronex 
Corporation. It may be used freely on any product, but it must be clearly 
stated that the matrix in use is "KVCD "Notch" Quantization Matrix". There 
are no other restrictions on it's use."

... 
       -q|--quantisation 2..31
...

mpeg2enc --help states that it is "1..31".

... 
       -I|--interlace-mode 0|1|2
...

mpeg2enc --help states that it is "0|1".

... 
-Q|--quantisation-reduction 0.0..4.0
...

mpeg2enc --help states that it is "0.0..5".

And some command line options mentioned in --help are not present in the man - 
though I consider this better than to have different explanations for the 
same options.

	WBW, Alexei

On Saturday 23 August 2003 10:45, Ronald Bultje wrote:
> Hey all,
>
> I've put up RPMs+tarball for mjpegtools-1.6.2 release candidate 1
> (versioned as 1.6.1.90, because that makes packaging easier) on
> sourceforge. This is a feature enhancement and bugfix release compared
> to 1.6.1. Most importantly, this release allows full-fledged DVD
> creation. Also, we now depend on libquicktime and we suggest using
> mplayer for divx encoding, so we have removed the quicktime4linux and
> avifile depdendencies. This should fix nearly 90% of all build failures.
> there are also smaller fixes, but I won't go into them here.
>
> You can get the tarballs and/or source/binary RPMs (x86) at
> http://sourceforge.net/projects/mjpeg/. Please report bugs or success
> stories here. If all goes well, this will become 1.6.2 in a few days.
>
> Special thanks to Steven for kicking me to do this release. ;).
>
> Ronald

Hey Bernhard,

On Sun, 2003-08-24 at 12:31, Bernhard Praschinger wrote:
> If you rewrite the *.info files your canges will be lost the next time I
> update the doku!!
>  
> Where/Why have the 2 scripts be vanished ? When I updated my CVS
> repository I got:
> cvs server: docs/install-info.sh is no longer in the repository
> cvs server: docs/uninstall-info.sh is no longer in the repository

I've integrated them into the Makefile. The advantage of this is that I
can use $(srcdir) and $(top_srcdir) variables, which makes 'make
distcheck' pass successfully.

Ronald

-- 
Ronald Bultje <rbultje@...>