Re: [Mjpeg-users] writing multi threaded code

[Steven M. Schultz]

On Fri, 23 Sep 2011, Alan Cox wrote:

> It's a very sane default because the performance difference is
> astronomical

I disagree.  I do not see how having a thread which obtained a lock
be the one which  releases it causes any performance change.  The same
amount of unlocking is done.

> > #ifdef __linux__
> Far better is
> if (defined __linux__) && defined(DEBUG_MUTEXES)

Better name would 

defined(NON_PORTABLE_MUTEXES)

linux is the only system I've encountered which doesn't use the 
concept of thread ownership.  And it was a big pain to port a program
written to use the 'ownerless mutex' concept to systems which did
use that concept. 

If the program is written to use the concept of thread ownershio (by
turning on either DEBUG_MUTEXES or NON_PORTABLE_MUTEXES) then WHERE
is the performance difference coming from?   Turning that option off
would make it easy to produce non portable threaded code.

> then you can build for debug or for performance as needed with a compile
> option.

To me it is an egregious error for a thread which did not lock a
mutex to unlock it -that's the way it's been for as long as I can
remember.  It has, in MY experience, always been a logic or design
error for a thread to unlock a thread of which is it not the owner.

> Even better still for many applications is not using pthreads in the

OK with me.When I see the mjpegtools rewritten into whatever
replaces pthreads I'll believe it ;)

> first place. The fundamental models pthreads use are basically
> 'everything is shared, nothing is locked unless you remember to do so'

we have to live within the confines of the pthreads model unless
someone volunteers to

Wasn't trying to start a religious argument and it seems the reference
to brain dead did push a hot button.   Was simply pointing out
that the default behaviour of a system that many use is not as 
portable as many would like to think.   Java -> /dev/null

Steven Schultz


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] writing multi threaded code

[Steven M. Schultz]

>From: Mark Heath 
>
>I assume I'd need to use glib but it appears to be broken on my system.
>I also tried the gcc atomic operations but I've only got gcc 4.0.1.
>
>I've also sig_atomic_t but I've got no idea if it's reading and  
>incrementing as an atomic action.  The read and increment is such a  
>short duration I cannot get it to break even without locking.

I think this talk of threaded applications says it's time for
a reposting of my caution and plea for portability...


Threaded programming is hard.  PORTABLE threaded programming is 
very hard.

Two things to keep in mind:  1) Check ALL return values and status
indications (I've seen too many programs *assume* that 
pthred_mutex_unlock() 
can not/will not fail) and 2) all the world is NOT linux (as much as
some might think otherwise ;)).

With those two cautions here's what I've posted several times over
the years (and is what mjpegtools uses in mpeg2enc).  Happy reading :)

With linux a mutex can, according to the manpages, be of type 'fast',
'recursive' or 'error checking'.  The 'fast' type has no concept of
thread "ownership" and any thread can unlock any mutex *even if it is
not the thread that locked it*.   On the other hand the 'error checking'
type does enforce mutex "ownership" and only the thread that locked
a mutex may unlock it, attempting to unlock a mutex not owned by the
thread returns an error (EPERM) - thus checking the status returned
by pthread_mutex_lock() and pthread_mutex_unlock() is a good idea.

FreeBSD, Solaris and BSD/OS all use 'error checking' mutexes (I did
verify this with a simple test program).  MAC OS/X says unlocking a
mutex not owned by the calling thread is undefined.  The default linux 
mutex attribute is, for some unknown reason,  'fast'.

As you can imagine a program that relies on 'fast' mutex behaviour
will not function correctly on a system which uses 'error checking' 
(i.e. ownership) mutexes (the reverse case might work - I haven't 
tried it ;)).

The workaround is to override the brain damaged default with:

#ifdef __linux__
pthread_mutexattr_t mu_attr;
pthread_mutexattr_t *p_attr = &mu_attr;

pthread_mutexattr_init(&mu_attr);
pthread_mutexattr_settype( &mu_attr, PTHREAD_MUTEX_ERRORCHECK );
#else
pthread_mutexattr_t *p_attr = NULL;
#endif

pthread_mutex_init( &frame_buffer_lock, p_attr);

Cheers,
Steven Schultz


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] lavplay input source

[Steven M. Schultz]

On Mon, 5 Apr 2010, Bernhard Praschinger wrote:

> I'm nor sure any more but y4mscaler was programmed by Matthew 
> Marjanovic. He did a lot for the mjpegtools project but he did never put 
> y4mscaler into the mjpegtools project. So I/we did never distribute the 
> y4mscaler with the mjpegtools or include it to the CVS.

I think it would be a very good idea to integrate the current
version of y4mscaler  into mjpegtools.  

That way the same ./configure (autoconf, etc) process would be used
and then people would not have to manually edit the y4mscaler Makefile.

Cheers,
Steven Schultz


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] jpeg2yuv Segmentation fault

[Steven M. Schultz]

On Sun, 20 Dec 2009, Matt Scherer wrote:

> I'm having a problem with jpeg2yuv. This binary is currently a
> dependency of the MythArchive package from my software repository. The
> command that I'm trying to run is:

> mythserver share # jpeg2yuv -v 2 -n 449 -v0 -I p -f 29.97 -j 
> /tmp/work/background-1.jpg
> YUV4MPEG2 W720 H480 F3:1001 Ip A1:1 C420jpeg
> Segmentation fault

> I've attached the .jpg that it is trying to process.

The -v 2 and -v0 are redundant - just need one or the other :)

Works fine here:

[curlyjoe:~] sms% jpeg2yuv -v 2 -n 449 -v0 -I p -f 29.97 -j background-1.jpg > 
foo
[curlyjoe:~] sms% ls -l foo
-rw-r--r--  1 sms  sms  232764343 Dec 21 09:17 foo

[curlyjoe:~] sms% head -n 1 foo
YUV4MPEG2 W720 H480 F3:1001 Ip A1:1 C420jpeg

I have not played or viewed the resulting file but the header looks OK.

I am curious where jpeg2yuv came from - did you build it from CVS
or find a pre-built version somewhere.   

The CVS version appears to work fine on OSX 10.6.2 - maybe someone 
else with a different OS can try the command and reproduce the
failure.

Cheers,
Steven Schultz


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] qttoy4m / solved

[Steven M. Schultz]

On Thu, 8 Oct 2009, E Chalaron wrote:

> Ha well let's install libquicktime-devel then ...
> No such luck, Yast is preventing me to do so thanks to a depedency on
> libdc1394_control_12-devel /ffmpeg which leads me to a cascade of
> depedencies of various stuff ...

	Right - and while "package" system offer convenience you are also
	at the mercy of how the packager decides he/she wants to build/configure
	the package ;(

> Ok ... so downloaded libquicktime source to compile  and make fails
> on some libtool >:o

	And from the errors I'd guess something is very wrong with the
	libtool setup on your system.
> 
	You did run ./autogen.sh first I hope.

> -I../include -I../include   -DLOCALE_DIR=\"/usr/local/share/locale\"
> -march=k8 -mtune=k8 -O3 -funroll-all-loops -fomit-frame-pointer 
> -finline-functions -Wall -Winline -Wmissing-declarations
> -Wdeclaration-after-statement -fvisibility=hidden -MT audio.lo -MD -MP
> -MF .deps/audio.Tpo -c -o audio.lo audio.c
> ../libtool: line 824: X--tag=CC: command not found
> ../libtool: line 857: libtool: ignoring unknown tag : command not found
> ../libtool: line 824: X--mode=compile: command not found

	Those types of errors really make me suspicious of the libtool
	setup/installation.

> Went back to Yast and to the risk of seeing some corruption in the system
> eventually accepted 20 different depedencies.

	Very strange.  Other than gtk and a couple other libs for the gui portion
	of libquicktime there aren't that many dependencies (I thought).. On
	the other hand it sounds like your system was under-populated 
	software-wise ;)

> Now y4mscaler... in an another thread.

	And that is a puzzler too - that's a small number of C++ files and
	it doesn't even use autoconf.

	Good Luck (I think you need it :-))

	Cheers,
	Steven
--

Come build with us! The BlackBerry(R) Developer Conference in SF, CA

is the only developer event you need to attend this year. Jumpstart your

developing skills, take BlackBerry mobile applications to market and stay 

ahead of the curve. Join us from November 9 - 12, 2009. Register now!

http://p.sf.net/sfu/devconference___

Mjpeg-users mailing list

Mjpeg-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/mjpeg-users

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] qttoy4m

[Steven M. Schultz]

On Wed, 7 Oct 2009, E Chalaron wrote:

> I am sorry for what seems to be a recurent question but can not get the
> qtoy4m to compile.

We can be recurring too - as in the recurring request for additional
information :)

What is the error - cut/paste or include the build/compile session.
Perhaps also include the config.log file created when you ran
./configure.

> I remember this to be solved by adding the devel libs of libquicktime
> but this time it does not seem to work.

It could be a different problem - very hard to tell what is going on
with "can not get the qtoy4m to compile" being the only info  we have.

Could be a pkg-config issue, could be a libquicktime packaging issue
(building from source avoids that issue at least), who knows?  

> Platform is opensuse 11.

Builds fine on 10.3 - haven't bothered with 11.  Also builds on OSX
10.6 in 64bit mode.

> In the same kind of issue I cant eithe compile (or use the binaries) of
> y4mscaler with error loading libmjpegtools-1.7.so.0, where I had the
> feeling I was on 1.9 :-(

Your system may be 1.9 but the binary that you're trying to run was
built on a system that had 1.7 at the time of the build - you need
the same version of the library that was linked against at the time
the y4mscaler binary was built.

Steven Schultz


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc -M and quality (was: Converting vnc session to a movie file)

[Steven M. Schultz]

On Fri, 2 Oct 2009, Christian Ebert wrote:

> Hi,
> 
> [ sorry for half-hijacking the thread ]
> 
> > If you only have one CPU/Core you don't even need mpeg2enc's -M 2 
> > option. The only thing that might help you than is the buffer program 
> > for buffering the I/O. The mjpegtools with the piping can only be mad 
> > faster with more cores.
> 
> Has bumping up the -M option a negative effect on quality?

No.  But it also doesn't improve the encoding speed as much as
people would prefer.  There are enough serialisation points in
the encoder that prevent effective parallel processing.

In the case of the original poster's thread - look at the size of the
frames being encoded?  They are huge - 1024x768!   A standard DVD
frame is 720x480 or perhaps 720x576 so it's not surprising to me
that a single cpu system takes 4x realtime to do 1024x768 frames!

One way to speed things up would be to scale the frames down to
1/2 the size before encoding. 

The other way to speed things up would be a dual core cpu so that
other programs in the pipeline can run in parallel. The encoder 
will realize some benefit from more cpus but the primary benefit
is that multiple stages in the pipeline can run in parallel without
taking cpu time away from the encoder.

Cheers,
Steven Schultz


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] latest change to cpuinfo.sh breaks build on MacOS 10.5.8

[Steven M. Schultz]

On Wed, 2 Sep 2009, Bernhard Praschinger wrote:

> I have tested it here on a Suse and MAC 10.5.8, and it compiles here to.
> 
> I get some error messages when I tries to compile the newdenoise.cc on 
> the mac. I will investigate it next weekend. It compiles well on the PC 
> running Linux.

Interesting.  I just did a compile on the Mac (10.5.8) a minute ago
and didn't see any errors with newdenoise.cc

Let us know what you find out.
> 
Cheers,
Steven Schultz


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] latest change to cpuinfo.sh breaks build on MacOS 10.5.8

[Steven M. Schultz]

On Mon, 31 Aug 2009, Christian Ebert wrote:

> Hello,
> 
> I believe it must be the last change to cpuinfo.sh that breaks
> compilation on MacOS X:

> configure:   - arch/cpu compiler flags   : -march=core2 -mtune=core2

Seems some versions of gcc have sprouted a new cpu type that is not
accepted by gcc on OSX 10.5.8.

> $ sw_vers
> ProductName:  Mac OS X
> ProductVersion:   10.5.8

Got your 10.6 on order ? :-)

> Let me know if you need more info.

I should have tested the change.  Looked simple enough but broke
things as you notice for cpu type 23 (which is what the 2.93GHz
T9800 in the notebook has).

A change was checked in to do a test compile and force $proc back to 
"nocona" if the 'core2' is rejected.

Works fine now.

Cheers,
Steven Schultz


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Top-forward for DV?

[Steven M. Schultz]

> Rats...my memory of the conversation was that TOP_FORWARD was
> necessary to correct DV of telecined video.

And for a long time that was the prevailing method - but I ran into
problems back (3 or 4 years).  

> (I searched the
> mailing list archives, by asking Google for "TOP_FORWARD
> site:mail-archive.com", but couldn't find why TOP_FORWARD was harmful.)

I took a quick look and saw bits/pieces of the threads but not parts
I was looking for.  Try searching for yuvkineco and yuvcorrect

I've got to get out the door and don't have time to do much more than
clear out the mailbox.  

> As an experiment, I tried running yuvkineco on video without
> doing TOP_FORWARD, and it was visibly worse.=A0 Maybe that's
> because yuvkineco is top-field-first only?=A0 It didn't seem to
> complain about being given bottom-field-first video.

Hmmm, I thought yuvkineco would complain about the wrong field order


> The reverse-telecined videos I make with yuvkineco TOP_FORWARD
> look great to me...and I thought I was nitpicky about these
> things.=A0 :-) Have I been living a lie?=A0 What should I be doing?

SHift the video one line up or down within the frame.  This is MUCH
better (I think) than shifting the video 1/2 frame.  Here's what I 
wrote up about 3 years ago:

#!/bin/sh

N=rites

# NOTE: lie and say it's a progressive stream instead of bottom first.  This
#   hushes y4mscaler and we will tag the stream as top first anyhow after
#   shifting down 1 line.
#
# Take the first 479 lines of a frame and place them in the last 479 lines
# of the output frame.  This places 1 black line at the top and converts the
# stream from bottom to top field first:
#  y4mscaler -v 0 -I active=704x479+8+0 -O sar=src -O size=704x480 -O align=BC
#
# OR
#
# If 720x486 input we can skip one top line and take the next 480 lines:
#y4mscaler -v 0 -I active=704x480+8+1 -O sar=src -O size=704x480
#
# -A ${N}.wav as needed.

qttoy4m -i p -a 10:11 /Volumes/TEMP/tmp/${N}.mov | \
 y4mscaler -v 0 -I active=704x480+8+1 -O sar=src -O size=704x480 -O align=BC | \
 yuvdenoise -t 4,6,6 | \
 yuvcorrect -v 0 -T INTERLACED_TOP_FIRST | \
 yuvkineco -F 1 -C yuvkineco-${N}.txt | \
y4mtoqt -a /Volumes/TEMP/tmp/${N}.wav -o /Volumes/RAID/TEMP/${N}.mov

and with that I'me off

Steven Schultz
>yuvkineco is top field first only.

>[...]

>yuvcorrect top_forward is harmful.



Rats...my memory of the conversation was that TOP_FORWARD was

necessary to correct DV of telecined video.  (I searched the

mailing list archives, by asking Google for "TOP_FORWARD

site:mail-archive.com", but couldn't find why TOP_FORWARD was

harmful.)



As an experiment, I tried running yuvkineco on video without

doing TOP_FORWARD, and it was visibly worse.  Maybe that's

because yuvkineco is top-field-first only?  It didn't seem to

complain about being given bottom-field-first video.



The reverse-telecined videos I make with yuvkineco TOP_FORWARD

look great to me...and I thought I was nitpicky about these

things.  :-) Have I been living a lie?  What should I be doing?



Steven Boswell






  --

___

Mjpeg-users mailing list

Mjpeg-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/mjpeg-users

--
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Top-forward for DV?

[Steven M. Schultz]

On Wed, 24 Jun 2009, Roman V Shaposhnik wrote:

> why? Don't the tools handle reverse telecine of NTSC material properly?

No.

yuvkineco is top field first only.  no effort has been made to fix
that and the author hasn't been heard from in eons.

and using yuvcorrect to shift the fields introduces what I call
a phaseshift - you're basically moving the top field of Frame A into
one of the fields of Frame B and so on.   Temporal order is preserved
but the frames now have fields from two different frames and this 
effectively destroys the 2:3 pattern which makes yuvkineco work harder
and err more often.  yuvkineco will produce *something* of course.
But folks wonder why they have to edit the output of yuvkineco...?

Anyhow there was a big discussion several years ago when I cared
about such things - yuvcorrect top_forward is harmful. 

and with that I'm going to go back into hibernation.

Steven Schultz


--
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] y4mtoqt missing ?

[Steven M. Schultz]

On Mon, 15 Jun 2009, E Chalaron wrote:

> Just recompiled from CVS. Y4mtoqt is not buidling, all other y4mtools
> have a .o and exe file but his one.

I wager that you are also missing qttoy4m

Both y4mtoqt and qttoy4m depend on having libquicktime correctly 
installed.  In
y4mutils/Makefile.am there are the three lines:

if HAVE_LIBQUICKTIME
bin_PROGRAMS += y4mtoqt qttoy4m
endif

If y4mtoqt is not being built then there is a high probability that 
qttoy4m is
also not being built.  Both depend on libquicktime being detected at 
configure
time.

Libquicktime being properly installed means:

1) if you didn't build from sources then you need to also install the 
matching
   "devel" package in addition to the runtime package.

2) If you did build from sources then the PKGCONFIG (.pc) flle needs to 
be
   in a place that pkg_config can  find it - this may mean adjusting the
   PKG_CONFIG_PATH environment variable.

3) If present the version  of libquicktime must be greater than  0.9.7  
(should
   not be a problem since 1.0 has been available for quite a while).

Solution would be to check  libquicktime out from CVS and build/install 
it.

> If someone has a quick fix please; kinda urgent here.

Rebuilding/updating while something urgent is happening is not a good 
idea.
As the saying goes "don't ugprade in the middle of a project"...

Cheers,
Steven Schultz


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] y4mstabilizer segmentation fault

[Steven M. Schultz]

On Wed, 3 Jun 2009, Richard Archer wrote:

> I'm running mjpegtools on a Centos 5 x86_64 (Intel) system and 
> y4mstabilizer is crashing.

mjpegtools build either from the last release (end of Dec 2009) or from 
CVS (which
hasn't changed too much)?

> My source file is a snippet of interlaced video from a DVD.
> I pre-process it with ffmpeg and pipe it into y4mstabilizer. 

Oh - and I think that is the problem.

> I have also tried using yuvdeinterlace prior to y4mstabilizer 
> but then it crashes on frame 2.

I think it's the output from ffmpeg that's the problem.

> I have tried scaling the stream to 768x576 (SAR 1:1) but that 
> didn't help either.

Not necessary.

> Here's the setup and the results:
> 
> $ ffmpeg -deinterlace -i "test.m2v" -r 25.000 -s 720x576 
> -aspect 4:3 -f yuv4mpegpipe -aspect 4:3 -pix_fmt yuv444p - | 
> y4mstabilizer -v -v >/dev/null

ffmpeg doesn't know the rate or frame size?  I would have thought that 
none of those
options would be necessary if the input stream is properly formed.

The PROBLEM the use of "-pix_fmt yuv444p".  -pix_fmt does not scale or 
resample the
data!!   -pix_fmt simply tells ffmpeg what value to put into the 
yuv4mpeg header.

So the next application is getting 4:2:0 data but is TOLD that the data 
is 4:4:4

and that I think is causing the problem.

MPEG-2 is 4:2:0.  The correct -pix_fmt ot use is 420p.

You need to use y4mscaler to do the chroma upsampling.

Maybe ffmpeg can do the chroma resampling but I'm fairly sure that 
-pix_fmt is not
the way to do it.

> Seems stream 0 codec frame rate differs from container frame rate: 50.00 
> (50/1) -> 25.00 (25/1)
ffmpeg is saying your input is 50 frames/sec?  Hmmm, interesting.

> Input #0, mpegvideo, from 'test.m2v':
>   Duration: 00:00:46.50, bitrate: 3938 kb/s
> Stream #0.0: Video: mpeg2video, yuv420p, 720x576 [PAR 16:15 DAR 4:3], 
> 3938 kb/s, 25 tbr, 1200k tbn, 50 tbc
> Output #0, yuv4mpegpipe, to 'pipe:':
> Stream #0.0: Video: rawvideo, yuv444p, 720x576 [PAR 16:15 DAR 4:3], 
> q=2-31, 200 kb/s, 90k tbn, 25 tbc

UGH!  What is a PAR (Pixel Aspect Ratio) of 16:15?  PAL is something 
like 59:54 as 
I recall.  But then I always ignored the y4m header that ffmpeg output 
and
put on my own ;)

Maybe it's just as well the programs crashed :)  Looks like the video 
is being 
mangled.

> Press [q] to stop encoding
>INFO: [y4mstabilizer]   frame size:  720x576 pixels (1244160 bytes)
>INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
>INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
>INFO: [y4mstabilizer]interlace:  top-field-first
>INFO: [y4mstabilizer] sample aspect ratio:  16:15

The 'frame size' is calculated by multiplying the width, height, and 
chroma sampling.
That value is correct for 4:4:4 but the data is still just 4:2:0

> And there ends my ability to debug this problem :(

I can't recall if there were issues with y4mstabilizer on the 64 bit 
platforms or
not.  I never used the program much and the author has abandoned the 
program
(you can try email to jmac8...@gmail.com (Jim) but I suspect he hasn't 
been actively
involved with the program for some time).

> I'm happy to follow instructions to help isolate the bug and 
> to apply patches and rebuild to test a solution.

I would try getting correct data into the program  before any more 
debugging ;)

with ffmpeg something like this might stand a better chance:

   ffmpeg -i test.m2v -pix_fmt yuv420p | \
   yyuvdeinterlace | \
   y4mscaler -v 0 -O sar=src -O chromass=444 | \
   y4mstablizer | \
   y4mscaler -v 0 -O sar=src -O chromass=420_MPEG2 | ...

the last y4mscaler goes back to 4:2:0 for encoding, etc.

My preference for decoding is to use 'mpeg2dec' but I think if you let 
ffmpeg emit
4:2:0 things will work OK.

Good Luck!

Cheers,
Steven Schultz


--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] png2yuv memory leak and fix

[Steven M. Schultz]

On Thu, 14 May 2009 j...@bitminer.ca wrote:

> A simple fix, the png library needs to free memory after every read of a
> png image.
> 
> +  png_destroy_read_struct(&png_ptr, &info_ptr, &end_info);
>fclose(pngfile);
> 
>return 1;

Fix checked in.  Interestingly enough the memory _was_ being freed 
everywhere
else (in all the error cases) - just not on the normal/success 
instance. 

Cheers,
Steven Schultz


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] DV->YUV tools for fedora?

[Steven M. Schultz]

On Mon, 27 Apr 2009, steve tell wrote:
> As a longtime mjpegtools user, I'm excited to start using my new ADVC-55 
> (replaces a LML33 card and occasionaly troublesome zoran driver).

I had a Canopus ADVC-100 but gave it to a friend in Austria.  Still 
have my AJA Io-LA
though ;)

> Anyone know of a ready-to-use package for fedora containing smilutils
> (smil2yuv, etc.)?  I can't find one in the usual repositories, and thought 
> I'd ask before rolling my own rpm.

You'll have to roll your own by checking out a copy from CVS.  I have a 
feeling that
any rpms you could find wouldn't work right with the current 
ffmpeg/libavcodec (the changes
to do that were made quite recently). 

Cheers,
Steven Schultz


--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Bug in yuv2lav 1.9.0

[Steven M. Schultz]

On Sun, 19 Apr 2009, Graham Murphy wrote:

> As distributed, lines 245-250 in yuv2lav.c are:
> 
> #ifdef HAVE_LIBQUICKTIME
>  dotptr = strrchr(param_output, '.');
>  if ( (!strcasecmp(dotptr+1, "mov")) && (param_format == 'x') )
>  param_format = 'q';
> #endif
>  if ( (!strcasecmp(dotptr+1, "avi")) && (param_format == 'x') )
>  param_format = 'a';
> 
> Apparently, the version compiled for SUSE 11.0 does not have 
> HAVE_LIBQUICKTIME defined 
> (which might just be a pkg-config issue), and so yuv2lav is broken.


To me the way I would prefer to fix the problem is require Quicktime 
support but
that idea has been shot down in the past.  

I've checked in a change to not only initialize 'dotptr' but also check 
for a
NULL pointer (if there is no extension on the filename).

Cheers,
Steven Schultz


--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] OT: compiling y4mscaler on MacOS X

[Steven M. Schultz]

On Sat, 24 Jan 2009, Christian Ebert wrote:

> > The changes are most definitely NOT recent.  The changes date back...
> 
> When the logging output was changed?

April 1, 2007.  'cvs log' says:

date: 2007/04/01 18:06:06;  author: sms00;  state: Exp;  lines: +12 -2
LOG_* is used NOWHERE except internal to mjpeg_logging.  A new routine was
defined to map strings ("info") to log level_t

The LOG_* defines were causing conflicts - seems many projects (and
the syslog daemon) all want to define LOG_*.   To me the sensible thing
to do was use strings rather than '#define' values.  

> ... extra FLAGS because I have not everyting in /usr/local, it built fine.

One of the benefits of integrating y4mscaler into mjpegtools would
be easy of building - no extra FLAGS or Makefile editing.

> Thank you very much.

You're welcome.  

Cheers,
Steven Schultz


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] y4mstabilizer problem (solved)

[Steven M. Schultz]

On Sat, 24 Jan 2009, Marko Cebokli wrote:

> I managed to compile the y4mscaler.c that was attached to a previous message 
> of another thread (10 min ago).

Good!  Maybe in the future there will be either a 0.91 version of
y4mscaler or the program will be integrated into mjpegtools.

> But when I try y4mstabilizer with it and 4:4:4 (using the exact y4mscaler 
> options from the y4mstabilizer help) , I get exactly the same problem, brief 
> flash of first frame and then a green frame that floats away

Oh, ok - I misunderstood the problem.  I thought the entire frame 
turned green.  Anyhow, that 'green' is 0/0/0 in YUV so something is
zero filling a buffer.

Since there are only 3 uses of bcopy it was not too much effort to
change them to use memmove.  I used memmove instead of memcpy because
the manpages state that memmove correctly handles overlapping copies
while memcpy does not.  BSD versions of bcopy also handle overlapping
buffers correctly but perhaps other systems do not.

Since the problem doesn't happen on my system I can't test the change.

Try the CVS version of mjegtools and see if the problem goes away. If
it does then the released packages can be updated.

Cheers,
Steven Schultz


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] OT: compiling y4mscaler on MacOS X

[Steven M. Schultz]

On Sat, 24 Jan 2009, Christian Ebert wrote:

> y4mscaler to switch to 444. Trying to compile it on MacOS 10.5.6
> fails like so:
> 
> ~/src/y4mscaler-9.0$ make
> y4mscaler.C: In function ?int main(int, char**)?:
> y4mscaler.C:197: error: ?LOG_INFO? was not declared in this scope
> y4mscaler.C:219: error: no matching function for call to 
> ?ysStreamInfo::log_info(, const char [5])?
> ysStreamInfo.H:109: note: candidates are: void 
> ysStreamInfo::log_info(log_level_t, const char*) const

Sigh.  The author of y4mscaler _still_ hasn't made the (simple) changes
even though he was aware of the API change.  Still hasn't autotool'd
the building which avoid editing the Makefile.

> I was successful in compiling it on MacOS 10.4 afair, but could
> this also be due to the recent changes in mjpegtools?

Nothing to do with the version of OS/X

The changes are most definitely NOT recent.  The changes date back
to spring of 2007 (April 1, 2007 is the timestamp on the logging files
in mjpegtools).  Almost 2 years ago!  I have a copy of y4mscaler.C 
dated 2007/11/30 so I've had the mods at least that long.

I'm very much tempted  to add y4mscaler to mjegtools - then changes
would be possible.

In the meantime try the attached replacment y4mscaler.C file

Cheers,
Steven Schultz
/*
Copyright 2003 Matthew Marjanovic 

This file is part of y4mscaler.

y4mscaler is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

y4mscaler is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with y4mscaler; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
*/


#include "y4m-config.h"
#include "debug.h"

#include 

#include "ysScaling.H"
#include "ysSource.H"
#include "ysTarget.H"


void print_version(char *argv[])
{
  printf("%s is y4mscaler %d.%d\n", argv[0],
 YS_VERSION_MAJOR, YS_VERSION_MINOR);
  printf("Copyright 2004 Matthew J. Marjanovic\n");
}


void print_usage(char *argv[],
 const ysSource &source, const ysTarget &target,
 const ysScaling &scaling)
{
  print_version(argv);
  fprintf(stdout, "\n");
  fprintf(stdout, "[This is just a summary --- read the manpage!]\n");
  fprintf(stdout, "\n");
  fprintf(stdout, "usage: %s [options...]\n", argv[0]);
  fprintf(stdout, "\n");
  fprintf(stdout, "  -I input_parameter:\n");
  source.describe_keywords(stdout, "  ");
  fprintf(stdout, "\n");
  fprintf(stdout, "  -O output_parameter:\n");
  target.describe_keywords(stdout, "  ");
  fprintf(stdout, "\n");
  fprintf(stdout, "  -S scaling_parameter:\n");
  scaling.describe_keywords(stdout, "  ");
  fprintf(stdout, "\n");
  fprintf(stdout, "  -v N  verbosity: 0=quiet, 1=normal, 2=debug\n");
  fprintf(stdout, "  -Vshow version info and exit\n");
  fprintf(stdout, "  -hshow this help message\n");
}


enum parsing_mode_t {
  GLOBAL = 0,  /* stream-independent arguments */
  SOURCE,  /* '-I' input arguments */
  DEST /* '-O' output arguments */
};


static void parse_args(int argc, char *argv[],
   ysSource &source, ysTarget &target,
   ysScaling &scaling, parsing_mode_t mode)
{
  int verbosity = 1;
  int c;

  optind = 1;
  while ((c = getopt(argc, argv, "I:O:S:v:hV")) != -1) {
switch (mode) {

  case GLOBAL: /* process 'global' options only */
switch (c) {
case 'v':
  verbosity = atoi (optarg);
  if (verbosity < 0 || verbosity > 2) {
mjpeg_error_exit1("Verbosity level must be [0..2]");
  }
  break;
case 'h':
  print_usage(argv, source, target, scaling);
  exit(0);
  break;
case 'V':
  print_version(argv);
  exit(0);
  break;
case 'S':
  scaling.parse_keyword(optarg);
  break;
case '?':
  mjpeg_error("Unknown option character:  '%c'", c);
  mjpeg_error("Use '-h' to get usage hints.");
  exit(1);
  break;
case 'I':
case 'O':
default:
  break;
}
break;

case SOURCE:  /* process stream-dependent options only */
  switch (c) {
  case 'I':
source.parse_keyword(optarg);
break;
  case '?':
mjpeg_error("Unknown option character:  '%c'", c);
mjpeg_error("Use '-h' to get usage hints.");
exit(1);
break;
  case 'O':
  ca

Re: [Mjpeg-users] y4mstabilizer problem (solved)

[Steven M. Schultz]

On Sat, 24 Jan 2009, Bernhard Praschinger wrote:

> I have a similair machine Athlon Phenom but running OpenSuse 11.0 x64.
> There y4mstabilizer does not produce a green output. bcopy, and memcpy 
> produce visualy the same output.

I tested on a SuSE 10.3 64bit Opteron system and saw no green.

> > After replacing all instances of
> > bcopy(a,b,c)
> > with
> > memcpy(b,a,c)

> Could you please check if you don't have any other problem (lib where a 
> patch is aviable), before I check in the changes.

I think there is something wrong on the system (libc or other library
as you suggest).  

y4mstabilizer does say, in its help output that the input should
be deinterlaced and be 4:4:4.  That's more than just a hint or
suggestion as I found out.  the program becomes quite unstable at times
if those conditions are not satisfied.

try using deinterlaced 4:4:4 and seeing if the problem goes away.  if
so then y4mstabilizer has a bug

> Replacing the outdated function sounds good to to me.

Harmless but could just hide/mask the real problem.

Cheers,
Steven Schultz


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Multi-angle / Camera DVD authoring

[Steven M. Schultz]

On Wed, 31 Dec 2008, Todd Freeman wrote:

> I see that mpeg2enc supports closed GOPs which are necessary for multi-angle 
> DVDs and I happen to be working on a project that I need to make such DVDs.
> 
> Has anyone had luck with mpeg2enc/dvdauthor/etc making such a DVD? Care to 
> share?

mpeg2enc works fine with closed gops - and the gop size can be set
with "-g" and "-G" options.

to actually use the encoded streams to create a multi-angle DVD
use DVD Studio Pro.   Multi-angle DVDs weren't supported/implemented
in dvdauthor, etc.

Cheers,
Steven Schultz


--
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc: any hope of further development?

[Steven M. Schultz]

On Sun, 30 Nov 2008, Steven M. Schultz wrote:

First posting in eons and I make a typo...

>   Actually I'd hope you would resurrect and do battle with, and hopefully
>   drive a stake thru the hear of, the "-q" option.  Make that thing

drive a stake thru the heart of, ...

In essence be a vampire slayer and get rid of -q ;)

Steven Schultz


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc: any hope of further development?

[Steven M. Schultz]

On Sat, 29 Nov 2008, Andrew Stevens wrote:

Andrew - you're alive! :)

Welcome back!

> - no longer doing any kind of analog video capture and so having zero use for 

I know that on at least a couple occasions I have mentioned that you
do not need an analog capture device.  Simply rip a section from
one of your DVDs and re-encode it.   Motion scenes and lower values
of -q seem to tickle the bug (but the problem can appear almost any
time).

You might check with Bernhard Praschinger - I send him a DVD of test
data to give to you (if he happened to drive and visit you).

> - I got rather depressed about the embarrassing state of the "grown" C++ code 
> compared with my professional efforts.

It's not as ugly as some.  But there's still time to redeem yourself
and rewrite it into C so that the next fellow can understand it :) :)

> > this version still gives the me most satisfying results (compared
> > to other tools) in dv -> dvd conversion, it would *really* be

It _can_ do a sericeable job BUT (and this is the huge caveat) you
can't _trust_ mpeg2enc - you never know when the artifacting/bugs
will show up!  

> - I want to reach some kind of closure on mpeg2enc to leave it in a reasonable
> state.

Actually I'd hope you would resurrect and do battle with, and hopefully
drive a stake thru the hear of, the "-q" option.  Make that thing
go away!  Please!  Specify a rate, a minimum and a maximum.  THe 
encoder should automatically, I think, adapt the quantization (-q)
with NO help from the user except for the desired average bitrate and
perhaps an absolute "do not exceed" value.

> Here's a deal.  If you can supply me with snippets of video where stuff is 
> going wrong I'll see if I can get the half-finished stuff in mpeg2enc working 

I might have the snippet of DV data I sent to Bernhard - I'll check
to see if I have it, otherwise you might talk to him

THe problem, as I recall, was quite ugly when it happened - usually
when playing with "-q"  - lower values seemed to make things worse.

Cheers,
Steven Schultz


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Found in the Tracker

[Steven M. Schultz]

On Tue, 9 Sep 2008, Bernhard Praschinger wrote:

> I have found that in the tracker:
> Initial Comment:
> Tried to build mjpegtools today (mjpegtools-1.9.0rc3) with the latest 
> (debian testing) gcc release.  gcc-4.3 appears much more strict about 
> header files now-a-days, I'm having to fix up lots of my C and C++ trees.

I thought changes were made in CVS for the gcc 4.3 issues but maybe
memory is playing tricks on me

> I haven't tested the patch. Maybe someone else has time.

Maybe someone with gcc 4.3 could test the current CVS version of
mjpegtools.  If the problem is in y4mdenoise then that's C++ and
we'll need someone who knows C++ to fix the problem.

Steven Schultz


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] 10 bits and more

[Steven M. Schultz]

On Tue, 29 Jul 2008, E Chalaron wrote:

> My point is actually to work in 10 or more bits from frame acquired from
> a machine vision cam.

> Trying to sort out what I can really do before investing in bits I could
> not use.

	Point to remember:  the type of hardware that is used to do
	10 bit or higher acquisition:

	http://www.aja.com/html/products_macintosh_kona_LSe.html
	http://www.aja.com/html/products_Io_IoLAD.html

	(there are others)

	are not supported by the OS some folks prefer to run

	If you can afford the $$ acquistion hardware and associated system to
	run the card, etc then it's also a good wager you can afford to buy
	the software/plugins to deal wth 10bit from start to finish ;)

	Cheers,
	Steven Schultz


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] 10 bits and more

[Steven M. Schultz]

On Tue, 29 Jul 2008, E Chalaron wrote:

> Do the MJPEGtools support more than 8 bits/channel ?

Nope.

A couple simple utilities 'qttoy4m' (and it's counterpart 'y4mtoqt')
can be used to downconvert Quicktime files from 10bit/channel (v210)
to 8bits.  And even that can be done in the Quicktime app on export

Steven Schultz


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Building Cross platform binaries

[Steven M. Schultz]

On Sun, 22 Jun 2008, Bernhard Praschinger wrote:

> Mark Heath wrote:
> > On 12/06/2008, at 11:23 PM, Mark Heath wrote:
> > It would be nice to be able to automate this into one seamless make.   
> > If anyone is responsible for the Makefile and configure scripts, I'd  
> > like to hear from you to see what we could change to make it build  
> > cleanly.
> I think Steven should be able to help you with that problem.

Very unlikely.  I have absolutely NO interest at all in a universal
binary for mjpegtools.  Not worth the time and effort.  The source
is portable and builds easily on both platforms assuming you don't
break the makefiles or whatever.  Takes a massive 84 seconds to build
on a quad PowerMac.  even faster on a newer system

Have fun - patches will be accepted but I'm content with the current
state of affairs (the encoder doesn't work well anyhow as folks should
probably be reminded).

Steven Schultz



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] frame rate conversion

[Steven M. Schultz]

On Sun, 25 May 2008, Christian Ebert wrote:

> Oh, sorry for the misunderstanding. I do have mpeg2enc installed
> and libmpeg2encpp.dylib in /usr/local/lib, only not latest CVS as
> quantisation is broken. In fact I mainly need mpeg2enc, and all
> distributions after 1.9.0rc1 do not work correctly.

> So I tried compiling yuvafps against 1.9.0rc1 and also against
> mjpegtools as of 2007-02-20 (last working mpeg2enc) but I still
> get the error I mentioned.

On OSX:

pkg-config --libs mjpegtools

says:

-L/usr/local/lib -lmjpegutils -lmpeg2encpp  

So you can either use 

`pkg-config --libs mjpegtools'

or manually add:

-L/usr/local/lib -lmjpegutils -lmpeg2encpp  

to the linking command. 

If neither works then there is something wrong with the mjpegtools
installation.

Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] File size differs from two tools for MPEG2

[Steven M. Schultz]

On Thu, 28 Feb 2008, Stan Gammons wrote:

> That's Ok with me. What do I need to change to make it work?

It'll be _REALLY_ obvious when you try to compile it ;)

Basically all the old LOG_WARN, LOG_ERROR, LOG_INFO, ... defines
are no longer public.  You have two choices when something like

   mjpeg_log(LOG_WARN, ...) 

is encountered.  Either change it to

   mjpeg_warn(...)

or

   mjpeg_log( mjpeg_loglev_t("warn"), ...)

This was changed to avoid conflicts with LOG_* and system defines (and
to avoid yet another package adding its own LOG* stuff to the namespace)

> Looks like I misunderstood what you were saying. From what I saw on the

It was mutual.  You won't obviously be able to pipe into the encoder.
But I thought you knew it would be up to you to create whatever
container an encoder would need.

> website, tmpgenc requires an avi file. So, I wondered how one took raw
> DV, edited it with Kino, and so forth an ended up with an avi file for
> tmpgenc to process? 

Kino can write an AVI file, right?  It's been 5 or 6 years since I ran
it but I thought it could write AVI files back out.


With ANY other encoder it's up to you to get the data into whatever
container the program will accept.  I create Quicktime files with
uncompressed 4:2:2 video since that's the most convenient format.

> I'll go back to the old version of mjpegtools. 

That's probably the best way.  

Steve


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] File size differs from two tools for MPEG2

[Steven M. Schultz]

On Thu, 28 Feb 2008, Stan Gammons wrote:

> Will mjpegtools compile Ok if I fetch the CVS, then replace the mpeg2enc
> directory from CVS with the mpeg2enc directory from the old version?  

Probably not unless  you're willing to do a little work.  The logging
API has changed and there are some 'mjpeg_warn/log/...' style 
statements in mpeg2enc.  

> > least 1 windows encoder will run using Wine.  There's also the
> > TMPGEnc encoder (http://www.tmpgenc.net/en/index.html) - it is where
> 
> Use tmpgenc in place of mpeg2enc?  How does one go about doing that?

Buy it first.  Then install on a windows system and or see if it
will run under wine.  Maybe there are discussion groups or a forum.

Or look back a little bit in the archives of this mailing list. There
was mention of another encoder that was free as I recall and the
poster provided sample scripts/proceedures.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] File size differs from two tools for MPEG2

[Steven M. Schultz]

On Wed, 27 Feb 2008, Stan Gammons wrote:

> I tried this using the latest CVS of mjpegtools on a video capture from
> satellite TV using the ADVC-110.  Video was 84,120 frames long. Average
> bit rate indicated was 5,017,600  Peak bit rate was 9,274,800   The file
> length was 1,706,553,307

For standard definition TV and a clean (no static) signal between
5 and 6Mb/s is perfectly adequate so the average you're seeing is fine.
It's a good 2hr of video on a DVD value.

The peak rate is probably from the beginning of the encoding - the
encoder starts with 0 and overshoots for a few frames and then
settles down.  Nothing to worry about.

> I have not yet made a DVD from this to see what it looks like.  I'll try
> to make one later today.

You could also play the .m2v file on the computer without having
to make a DVD - that;s useful as a quick check

> I noticed, as the info lines were scrolling by, some of the q= numbers
> were rather high at times. 62.00 is the highest I saw. EVERY time I saw

Yep - that bug's still present.  The frequency of huge values
was reduced but the problem still happens.  When it does the picture
quality goes to almost null and the bitrate plummets - that is 
probably why your average rate is somewhat lower than I'd expect.

> So I still don't know if the problem is fixed or what.

No, it's not.  It is somewhat less severe than it was.  Since it is
unpredictable when the problem will happen I guess you'll have to
go back to an earlier version (just keep going back until the
problem goes away ;)) OR use an alternate encoder.  Seems that at
least 1 windows encoder will run using Wine.  There's also the
TMPGEnc encoder (http://www.tmpgenc.net/en/index.html) - it is where
the 'tmpgenc' quantization matrices were obtained for use with mpeg2enc.
Maybe TMPGEnc runs under wine?  Don't know - I've my encoding needs
met in other ways.

Good Luck!

Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] File size differs from two tools for MPEG2

[Steven M. Schultz]

On Mon, 25 Feb 2008, [UTF-8] Bernhard Fr??hmesser wrote:

> I was wondering if anyone knows the programm Compressor from Apple?!

I've used it and the later version (Compressor2).  Not very often
for video, mostly for AC3 audio encoding.  Haven't seen the latest
version (3).

> I am asking because i was curious and did a test with a 6 minutes video, 
> one i encoded to MPEG2 using "Compressor" under MAC OSX and then i used 
> mpeg2enc on the same video on my Linuxbox.

> I am sure i used the same settings on both computers but the file 

That's impossible ;)   

That of course requires some explanation so here we go...

You almost certainly specified a "-q" with mpeg2enc.  That is a flooor,
a minimum below which mpeg2enc will NEVER go.  mpeg2enc will raise "-q"
(increase the amount of compression) to keep the bitrate below the
maximum.  In its extreme and buggy form this increase will cause the
effective quantization to be 30, 40 or more and poor quality.  

However, if the encoding produces a bitrate LESS than what you specified
on the command line then mpeg2enc will NOT lower '-q'!  

This has the effect of transforming  the '-b' (bitrate) option into
a "maximum" (try not to exceed) RATHER than an "average".  

SO if you don't specify a low enough value of '-q' the average bitrate
will be less (often a lot less) than the value specified by '-b'.  You
may specify "-b 8000" but depending on the -q you may end up with an
output file closer to 3500.

Compressor on the other hand uses the bitrate you specify as an
AVERAGE and will not only increase the effective quantization ("-q")
to keep the bitrate low enough, Compressor will also DECREASE the 
quantization to increase the bitrate towards the specified average
value.

This means it's really not possible to say much more than "I specified
the same bitrate" to both compression programs.  How that that value is
used is different.  And the concept of '-q' and the other options
from mpeg2enc are not present in Compressor (just very limited choice
of GOP size).

Compressor is doing what mpeg2enc _should_, in my opinion, be doing:
use the specified bitrate ('-b') as an average (not maximum) value
and doing completely dynamic and _INTERNAL_ adjustment of quantization
("-q" should be removed from the list of options).

> with mpeg2enc has only 114MB so far i don't see much quality difference.

Which brings me to the point I believe I've made before.

Pushing -q too low doesn't necessarily increase visual/perceived
quality.  It will raise the bitrate but will you see the difference?
Maybe, maybe not.

Too much time is wasted fiddling with "-q" in the name/quest of 
"quality".  This is because mpeg2enc doesn't do it automatically
but  realistically most folks could just stick a "-q 4" in place and
be done with it.  Maybe some day -q will go away but I'm not holding
my breath (you turn blue that way :)).

> So i was wondering what this could come from? Any ideas?!

I think, in your case, the video doesn't need as high a bitrate as
you specified and the values you used with mpeg2enc caused a lower
bitrate to be used.  It's also possible you're seeing a mild version
pf the bug that can causes mpeg2enc to push -q up too high.

You can get a good idea of the average bitrate like this:

mplex -f 8 -o /dev/null input.m2v

Try that on the two .m2v files you have and see what the average bit
rate and frame sizes are.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] cpuinfo.sh update needed

[Steven M. Schultz]

On Mon, 11 Feb 2008, Bernhard Praschinger wrote:

> Does anyone know how I change the cpuinfo program so I get the correct 
> value for the model ?

I have checked in  a change to cpuinfo.c  

The problem was that the family/cputype field is only 4 bits wide, so
for cputypes greater than 15 it is necessary to use the "extended
family info" field.

I can't test this since I don't have my 8core system yet.

Updating the cpuinfo.sh script to use the new values returned by
cpuinfo needs to be done yet - but I think you can handle that ;)

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] cpuinfo.sh update needed

[Steven M. Schultz]

On Mon, 11 Feb 2008, Bernhard Praschinger wrote:

> I have my new MAC beside me, and cpuinfo from the uitls directory tells 

Congratulations!

> me that:
> vendor_id   : GenuineIntel
> cpu family  : 6

the cpu family value looks OK.

> model   : 7

Hmmm, that seems low and is a Pentium-3 as you have noticed.
My Core2 notebook says:

 ./cpuinfo
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 15
 stepping: 6
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 cflsh ds acpi mmx fxsr sse sse2 ss tm
 cpu MHz : 0.000
 model name  : Intel(R) Core(TM)2 CPU T7600  @ 2.33GHz

> So I have a little problem because the script thinks that I only have a 
> Pentium 3 running at 2.8 GHz, well the script does not know that I have 

That will work.

> I have Suse 10.3 installed in a virtual machine on the OSX and there 
> /proc/cpu tells me that I have:
> cpu family 6
> model 23
> stepping 8

That's interesting.  23 would seem to be more reasonable than 7

> Does anyone know how I change the cpuinfo program so I get the correct 
> value for the model ?

The cpu probe logic in cpuinfo was borrowed from MPlayer.  Take a look
at how MPlayer or ffmpeg probes for the cpu type.  The 'cpuid' 
instruction was used, as I recall, to get the info - I would have
thought that would work the same for all Intel cpus.

Cheers,
Steven


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] cvs HEAD mpeg2enc: still random quant amplitudes

[Steven M. Schultz]

On Sun, 3 Feb 2008, Andrew Stevens wrote:

> Christian, quantisation up to 60 almost certainly a Bug someplace.   Can you 
> put a section of your source video someplace online so I can download 
> reproduce the problem reliably?

I saw something similar last night.  The encoding would be going
along with effective 'q' around 5 or so and then zoom up to 30 or 40
for a little while and then go back down.  This would happen at 
apparently random intervals thru the encoding process.

> Examples ... I need examples (no longer have a dumb analog capture card or 
> JPEG capture cared).

If ~1.5GB of NTSC-DV data would be useful to you let me know and
I'll put it up for FTP for you.  I think you might want something a
little more than a few seconds for testing (to see the rise/fall
cycles).

I think it would be possible to manufacture examples - decode one of
your DVDs and then re-encode it.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness

[Steven M. Schultz]

On Thu, 17 Jan 2008, Christian Ebert wrote:

> $ qtinfo test.mov
> Type: Quicktime
>   1 audio tracks.
> 2 channels, 16 bits, sample rate 48000, length 481920 samples, compressor 
> twos.
> Sample format: 16 bit signed.
> Channel setup: Not available
> Language: eng
> supported.
>   1 video tracks.
> 720x576, depth 24
> rate 25.00 [25:1] constant
> length 251 frames
> compressor dvcp.
> Native colormodel:  YUV 4:2:0 planar
> Interlace mode: Bottom field first
> Chroma placement: PAL DV
> Pixel aspect ratio: 59:54
> supported.
>   0 text tracks.

Ok - that says the plugins are being found.  Guess the problem you're
having, while similar, is not the same I had at one time.

> > (need that to include ffmpeg's libavcodec as I recall)
> 
> so dv decoding would actually be done with ffmpeg's libavcodec?

I was in error.  The gpl option is for faac/faad (AAC) audio modules.

libavcodec is used for dv even without the option mentioned.

> > If you still have problems the libquicktime-devel list is probably 
> > a better place to carry on the conversation.
> 
> will do.

See you over there ;)

> can't afford that atm.

Unfortunate.  It is a nice package with everything needed for good
video work.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness

[Steven M. Schultz]

On Wed, 16 Jan 2008, Christian Ebert wrote:

> I get buffer underflows for longer stuff when encoding from dv to
> mpeg2 for dvd with ffmpeg, and i really played around a lot with

That's the rate control issue(s) I had in mind.

> the ever changing options...

Yep - hard to keep up sometimes.

> But I'd like to decode with lav2yuv, but it segfaults here on dv movs

Works fine here - BUT I have seen the problem you mentioned earlier
(symptom is that 'twos' audio isn't recognized as valid).

> I've built the latest cvs libquicktime to no avail. No
> errors when compiling, small stuff like qtinfo works.

You're using the latest (and thanks for that info) from CVS. That's
good.

> What configure options do give to libquicktime? I'm asking as
> you're on a Mac as well, even though I still have 10.4.

./configure --enable-gpl

(need that to include ffmpeg's libavcodec as I recall)

You may have a corrupt or outdated .libquicktime_codecs in your
home directory.  Try removing it and then running any program 
linked to libquicktime.  If .libquicktime_codecs IS recreated then
things are setup/installed correctly and you shouldn't have any
problems.  

If .libquicktime_codecs is NOT recreated or is empty then libquicktime
can't find the *.so files (loadable modules/plugins) for the codecs.

ls  /usr/local/lib/libquicktime

lqt_audiocodec.la   lqt_ffmpeg.so   lqt_rtjpeg.la
lqt_audiocodec.so   lqt_lame.la lqt_rtjpeg.so
lqt_dv.la   lqt_lame.so lqt_videocodec.la
lqt_dv.so   lqt_mjpeg.lalqt_videocodec.so
lqt_faac.la lqt_mjpeg.solqt_vorbis.la
lqt_faac.so lqt_opendivx.la lqt_vorbis.so
lqt_faad2.lalqt_opendivx.so lqt_x264.la
lqt_faad2.solqt_png.la  lqt_x264.so
lqt_ffmpeg.la   lqt_png.so

You should NOT see ".dylib" files and you MUST have .so files.  At
one time there was a bug and either extensionless (no .so) or wrong
extension (.dylib) files were installed.  Since the code was looking
for .so only it didn't find anything.

If you still have problems the libquicktime-devel list is probably 
a better place to carry on the conversation.

Oh, 10.5 is fine if you're on a PPC based Mac.  If you're on an
Intel based Mac and want to run 10.5 then either 1) delete or 2) do
one last build/install of xvid, ffmpeg, theora, and a couple others 
I can't recall at the moment - they don't compile/link.

> There's an Apple compressor for mpeg2?

And 3gpp, H.264, AC3, MPEG-1, AAC, MPEG-4 and a bunch of others I'd
have to lookup.  "Compressor" (I'm only at Compressor2, not having
upgraded to 3) is Apple's compression engine frontend.  It's not
sold separately but only as part of the Final Cut Studio bundle 
(a bit pricey but a fair value for the amount of software and 
documentation you get).

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness

[Steven M. Schultz]

On Wed, 16 Jan 2008, Mark Heath wrote:

> I've used bitVice professionally and I have found it's constraints  
> too limiting.  Maybe it was just the version I was using.

You must have used version 1.0 ;)

Most of the items listed are not relevant to the current version.

True, it's limited to MP-ML (max frame size of 720x576).  Since HD
DVD (or Blu-Ray) authoring and burning are in the future that 
limitation is tolerable for now.

It is NOT limited to quicktime files.  Any file that the Quicktime API
installed on the system can read is acceptable.  I've used AVI files
for example.

I'll not bother with the other points except to say they're either
not correct or not important (especially when making DVDs at home ;))
movies ;))

> Anyway I've been using the mpeg2 encoder in ffmpeg and have been  

I'm 1 step away from deleting ffmpeg from the system.  You're 
obviously not running on a Intel Mac with OSX 10.5 or you'd know
it's no longer possible to build a shared version of ffmpeg(libavcodec).
At one time the ffmpeg crowd valued speed over quality and had
horrible rate control.  That may have, and probably has, change. Now
they don't care the program's not buildable.  I unsubscribed from
all of thair lists and my stress level went way way down.  Anyhow
ffmpeg is not an option (for me).

I wouldn't mind an alterative but with mpeg2enc "in progress" and
ffmpeg unbuildable, well, the choices are limited.  Apple's 
Compressor is pretty good - could use that I guess.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness

[Steven M. Schultz]

On Wed, 16 Jan 2008, Christian Ebert wrote:

> > Which says:

> > DV Color Correction - DV Luma Correction
> > DV Luma Correction has changed as of BitVice 1.4. If you create
> > video with iMovie, Final Cut Pro or other programs using the Apple
> > DV Codec, then check the DV Luma box. The Apple DV Codec

> > changes luma values when going from RGB to DV ...
> > Again, this is only for users of the Apple DV Codec.

> > That's the DV Color correction checkbox option.

Ok - two checkboxes.  One is the Color correction one and the other
was called (in 1.4 and earlier) DV Luma Correction.  

> Ermh, from :

> |Minor GUI changes
> |DV Luma Correction changed to Use gamma 2.2 which is more accurate 
> nomenclature

The name was changed and and the box is selected by default.

> |DV luma correction, is a filter for DV movies, which have gamma
> |1.8 as standard. This will make the resulting MPEG2 picture too
> |dark for TV. Check this box to correct that problem before
> |encoding QT DV movies. But use your eyes.
> 
> [ the last sentence being my biggest trouble ;) ]

 My biggest trouble is the first sentence (how do you know what
 setting was used - I think 1.8 is uncommon/rare/obsolete) combined 
 with the default setting of 2.2.  The default being 2.2 tells me
 that the checkbox only exists for the (rare) case (probably 
 of an incorrectly built camcorder ;-))

> Sorry for being stubborn but I think you've got it the wrong way around.

Wouldn't be the first time. 

My turn to be a bit stubborn -  I don't think the setting is needed
or useful anymore and not something that mjpegtools has any use for.

The bug was (is? - may be fixed by now after all this time) when
Apple's DV codec was used to convert between RGB and DV.  If you're
not doing that then don't worry about it.

> movtoy4m  speaks of a
> similar issue.

That's a bug in movtoy4m from my reading of the page.Unclear
if it was in the ffmpeg libraries or introduced by movtoy4m elsewhere.

Haven't done much with DV since 2006 but that movie came out fine.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness

[Steven M. Schultz]

On Tue, 15 Jan 2008, Christian Ebert wrote:

Hi Christian -

> On samples with /very/ noisy source material I just don't see the

Denoise it first ;)

> slightly clearer, but little jumps. I have pal-dv source
> material, in case it matters.

So the 'DV Luma Correction' does not apply to your situation.

> As an aside lav2yuv doesn't work on my Mac, perhaps some mistake
> in my libquicktime build, I get
> 
> [codecs] Warning: Could not find audio Decoder for fourcc twos
> [codecs] Warning: quicktime_decode_audio_stub called
> [codecs] Warning: Could not find video Decoder for fourcc dvcp
> [codecs] Warning: quicktime_decode_video_stub called

I've seen that.  It is indeed related to the libquicktime 
build/configuration.  

> Must be blind then, it looks almost more "pixely" to me.

I wonder if that isn't the noise being more accurately encoded.  

(The reason I switched encoders should be apparent now if you've
 had time to view the sample encodings and test data)

> >> BTW. is there a way to get the Luma Correction (gamma2.2) from
> >> mjpegtools (I'm encoding QuickTime files edited with Final Cut)?
> > 

> bitvice Users Guide, page 13/14.

Which says:

DV Color Correction - DV Luma Correction
DV Luma Correction has changed as of BitVice 1.4. If you create
video with iMovie, Final Cut Pro or other programs using the Apple
DV Codec, then check the DV Luma box. The Apple DV Codec
changes luma values when going from RGB to DV ...
Again, this is only for users of the Apple DV Codec.

That's the DV Color correction checkbox option.

The DV Luma Correction checkbox is described thus:

However, NTSC users will find that their DVD may look lighter than their DV
tape did. This is because of a flaw in the way NTSC DV camcorders
output an analog signal. We explain more about that in the discussion

You're using PAL so the checkbox is (or should be as No-Op) not
important.  

That's from version 1.4 of the manual.  Seems very strange to me
that the software's at 1.7 but the downloadable manual hasn't been
updated (that I could see).

Being in PAL land you do not have to worry about the NTSC setup.

> Actually Final Cut Express HD only, does enough for me needs.

Good enough for DV work but I think that's as far as it goes.

> Thanks for all your input!

Welcome.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness

[Steven M. Schultz]

On Tue, 15 Jan 2008, Christian Ebert wrote:

> Hm, I played around a bit with the demo and am not convinced.

I've done a lot more than play around with the demo and I am
completely convinced ;)

> Especially with bitrate around 4500 to get a 2h video on a singel
> layer dvd, I get lots of square pixels with noisy material.

You're supposed to denoise first ...

> Perhaps I haven't found the right tweakings, but so far mpeg2enc
> handles this much better.

Not in my case - 4500 to 6000 with properly processed input looks
far superior with Bitvice.

> BTW. is there a way to get the Luma Correction (gamma2.2) from
> mjpegtools (I'm encoding QuickTime files edited with Final Cut)?
> So far I've almost been using mpeg2enc, where/in which docs should I look?

I have no idea what that's about.  Wasn't aware that any gamma
correction is required if the chain of processing is setup right.

If you're running FCP then you might also be interested in:

http://www.mattias.nu/plugins/

The temporal denoise filter ghosts too much in my opinion but the
spatial filter does an excellent job of reducing noise.  And the
price is right - free ;)

if you have some money to spend then:

http://www.cgm-online.com/eiperle/cgm_e.html

is worth looking at (I have an earlier version of those)

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] 1.9.0rc2: jpeg2yuv loops forever when reading filenames from stdin

[Steven M. Schultz]

On Sun, 13 Jan 2008, Craig Leres wrote:

> If you do something like:
> 
> echo 000136_0.jpg | jpeg2yuv -f 25 -I p > /dev/null
> 
> jpeg2yuv loops forever processing the last filename seen on stdin.
> 
> I see 1.9.0rc3 is out and it appears to also have this issue.

Try the cvs version.  Looping problem is apparently triggered by
extra data in the file.

Problem's been fixed in cvs but a new RC (4) hasn't been released
pending the encoder being worked on (hopefully)

Steven Schultz
===

RCS file: lavtools/RCS/jpeg2yuv.c,v

retrieving revision 1.1

diff -u -r1.1 lavtools/jpeg2yuv.c

--- lavtools/jpeg2yuv.c 2008/01/13 19:36:05 1.1

+++ lavtools/jpeg2yuv.c 2008/01/13 19:45:47

@@ -462,7 +462,7 @@

  jpegsize = read_jpeg_data(jpegdata, jpegname, prev_jpegname);

}

else {

- jpegsize = 0;

+ jpegsize = -1;

}

}



-

Check out the new SourceForge.net Marketplace.

It's the best place to buy or sell services for

just about anything Open Source.

http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___

Mjpeg-users mailing list

Mjpeg-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/mjpeg-users

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] y4mscaler 9.0, current CVS of mjpegtools and opensue 10.3

[Steven M. Schultz]

On Mon, 7 Jan 2008, Matto Marjanovic wrote:

>  properly.  (Nothing like lighting a fire to get the frog to jump.)

Wasn't there an urban myth about gradually warming the pot and
the frog wouldn't notice it being boiled? :)

> ps:  Yah, looking ahead, I see sms responded as well.  :)

Should get folks by until 9.1

Hmmm - for 9.1 were you planning on autoconf'ing it?  

Cheers,
Steven Schultz


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] y4mscaler 9.0, current CVS of mjpegtools and opensue 10.3

[Steven M. Schultz]

On Sun, 6 Jan 2008, Stan Gammons wrote:

> Has anyone seen this error when trying to build y4mscaler 9.0 with the
> current CVS of mjpegtools on Opensuse 10.3?  

Of course.

matt was going to come out with a 9.1 version that would work
with the new logging API but so far that hasn't happened.

Attached is an updated y4mscaler.C that will compile with the
latest mjpegtools.

Steven Schultz
/*
Copyright 2003 Matthew Marjanovic <[EMAIL PROTECTED]>

This file is part of y4mscaler.

y4mscaler is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

y4mscaler is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with y4mscaler; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
*/


#include "y4m-config.h"
#include "debug.h"

#include 

#include "ysScaling.H"
#include "ysSource.H"
#include "ysTarget.H"


void print_version(char *argv[])
{
  printf("%s is y4mscaler %d.%d\n", argv[0],
 YS_VERSION_MAJOR, YS_VERSION_MINOR);
  printf("Copyright 2004 Matthew J. Marjanovic\n");
}


void print_usage(char *argv[],
 const ysSource &source, const ysTarget &target,
 const ysScaling &scaling)
{
  print_version(argv);
  fprintf(stdout, "\n");
  fprintf(stdout, "[This is just a summary --- read the manpage!]\n");
  fprintf(stdout, "\n");
  fprintf(stdout, "usage: %s [options...]\n", argv[0]);
  fprintf(stdout, "\n");
  fprintf(stdout, "  -I input_parameter:\n");
  source.describe_keywords(stdout, "  ");
  fprintf(stdout, "\n");
  fprintf(stdout, "  -O output_parameter:\n");
  target.describe_keywords(stdout, "  ");
  fprintf(stdout, "\n");
  fprintf(stdout, "  -S scaling_parameter:\n");
  scaling.describe_keywords(stdout, "  ");
  fprintf(stdout, "\n");
  fprintf(stdout, "  -v N  verbosity: 0=quiet, 1=normal, 2=debug\n");
  fprintf(stdout, "  -Vshow version info and exit\n");
  fprintf(stdout, "  -hshow this help message\n");
}


enum parsing_mode_t {
  GLOBAL = 0,  /* stream-independent arguments */
  SOURCE,  /* '-I' input arguments */
  DEST /* '-O' output arguments */
};


static void parse_args(int argc, char *argv[],
   ysSource &source, ysTarget &target,
   ysScaling &scaling, parsing_mode_t mode)
{
  int verbosity = 1;
  int c;

  optind = 1;
  while ((c = getopt(argc, argv, "I:O:S:v:hV")) != -1) {
switch (mode) {

  case GLOBAL: /* process 'global' options only */
switch (c) {
case 'v':
  verbosity = atoi (optarg);
  if (verbosity < 0 || verbosity > 2) {
mjpeg_error_exit1("Verbosity level must be [0..2]");
  }
  break;
case 'h':
  print_usage(argv, source, target, scaling);
  exit(0);
  break;
case 'V':
  print_version(argv);
  exit(0);
  break;
case 'S':
  scaling.parse_keyword(optarg);
  break;
case '?':
  mjpeg_error("Unknown option character:  '%c'", c);
  mjpeg_error("Use '-h' to get usage hints.");
  exit(1);
  break;
case 'I':
case 'O':
default:
  break;
}
break;

case SOURCE:  /* process stream-dependent options only */
  switch (c) {
  case 'I':
source.parse_keyword(optarg);
break;
  case '?':
mjpeg_error("Unknown option character:  '%c'", c);
mjpeg_error("Use '-h' to get usage hints.");
exit(1);
break;
  case 'O':
  case 'S':
  case 'v':
  case 'h':
  default:
break;
  }
  break;

case DEST:  /* process stream-dependent options only */
  switch (c) {
  case 'O':
target.parse_keyword(source, optarg);
break;
  case '?':
mjpeg_error("Unknown option character:  '%c'", c);
mjpeg_error("Use '-h' to get usage hints.");
exit(1);
break;
  case 'I':
  case 'S':
  case 'v':
  case 'h':
  default:
break;
  }
  break;

} /* switch */
  } /* while getopt */

  if (mode == GLOBAL)
mjpeg_default_handler_verbosity(verbosity);
  if (optind != argc) {
  mjpeg_error_exit1("STREAMS ONLY MY FRIEND!");
  }
  return;
}







// ***
// ***
// ***

Re: [Mjpeg-users] mjpegtools (fwd)

[Steven M. Schultz]

On Sun, 2 Dec 2007, Gernot Ziegler wrote:

> Hej !
> 
> Sorry, not involved anymore, but I forward the e-mail :-)
> 
> -- Forwarded message --
> Date: Sun, 2 Dec 2007 13:14:11 +
> Subject: mjpegtools

> I am trying to build mjpegtools on a newly built Intel E6750 Core 2 duo 
> machine running Slamd64 (a 64 bit port of Slackware).

More important than the specific model of Intel cpu (E6750) would
be the version of mjpegtools being used.

> No matter what CFLAGS I pass to the configure script, it insists that I am 
> running a pentium-m processor, and the compile crashes because it complains 

That sounds like an older version of mjpegtools.  Use the CVS version.
The CVS version knows about 'nocona' - that's what is in the Core2 Duo
MacBookPro.

> I have tried -march-nocona -mtune=nocona, but mjpegtools completey ignores any
> parameters passed to it!

Did you see and try the "--with-extra-cflags" option?  That can be
used to override options.  

Recent version (cvs) of mjpegtools should detect the nocona processor
type but if that doesn't happen then try:

--with-extra-cflags="-march=nocona -mtune=nocona"

Steven Schultz


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] ppmtoy4m and y4mtoqt format

[Steven M. Schultz]

On Thu, 8 Nov 2007, E Chalaron wrote:

> Thanks a lot Steven.
> I have actually remove the -X 308 it does not work either.

You mean remove the '-v308'?  That's what you were using and I know
that was incorrect.

-X, and I was not correct earlier, does not take an argument.

What -X does is enable the 10bit variant.  By default 4:4:4 uses
the 8bit 'v308' codec.  If you want the 'v410' codec for 10bit
4:4:4 then you use a simple '-X'.

> just y4mtoqt -o file.mov

That defaults to 'v308' for 4:4:4 and '2vuy' for 4:2:2.

> Just a syntax thing it seems, but the warning is a bit confusing

'-v' isn't a valid option so the program gave a usage() summary
and exited.  not a lot more that can be done (well, suggest that
folks don't use invalid options ;))

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] ppmtoy4m and y4mtoqt format

[Steven M. Schultz]

On Thu, 8 Nov 2007, E Chalaron wrote:

> Hi there
> I am trying to use y4mtoqt to convert some pnm files to a 444 qt video.
> I cant get where the error is coming from
> 
> Any help appreciated
> Thanks a lot
> Edouard
> 
> 
> script
> #!/bin/bash
> reel_name=$1
> (find . -name \*.pnm | sort | xargs cat) | \
> ppmtoy4m -F 17:1 -A 1:1 -I p -S 444 -v 2|\
> y4mtoqt -v308 -o "$reel_name"

> xargs: cat: terminated by signal 13

That means a process is exiting and breaking the pipeline - SIGPIPE
is 13 I believe.

Your use of y4mtoqt is wrong.  Why are you using '-v308'?  The usage
is:

y4mtoqt -h
++ WARN: [y4mtoqt] usage: [-k] [-X] [-a inputwavfile] -o outfile
++ WARN: [y4mtoqt]-X = use v210 (default 2vuy) for 4:2:2, v410 (default 
v308) for 4:4:4
++ WARN: [y4mtoqt]-k = do not perform lqt workaround (U and V plane 
swap) (default 0 - i.e. DO the workaround)

So would it be a better idea to use "-X 308' instead of 'v308'? 

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] hi-res matrix - not the best image quality?

[Steven M. Schultz]

On Tue, 6 Nov 2007, Florin Andrei wrote:

> Florin Andrei wrote:
> > I can probably test it also on Ubuntu 7.10, I'll see what I can do about 
> > that.
> 
> CVS compiles fine on 7.10 if I use the same -lX11 patch.

You can try without the patch.  I made a small change to the
lavtools/Makefile.am that should do the right thing.

Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] hi-res matrix - not the best image quality?

[Steven M. Schultz]

On Tue, 6 Nov 2007, Florin Andrei wrote:

> > which means that since SDL uses/needs the X11 libraries it includes
> > them and doesn't rely on the higher level applications adding them.
> 
> [EMAIL PROTECTED]:~$ sdl-config --libs
> -L/usr/lib -lSDL

Hmmm, but if SDL calls X11 shouldn't it include the necessary info
in its --libs?

> Maybe the output of this command could be used to make a decision when 
> lavtools/Makefile is generated?

No, it can't.  Some systems don't use X11 to do their SDL output.
On another system I have the sdl-config --libs gives:

-L/usr/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -Wl,-framework,OpenGL

> > A better workaround would be to edit the sdl-config script and add

> Hm, if I do that, I wonder what other things may break.

I don't think anything will break.

I'll look into the problem some  more.  There's only 1 place in 
lavtools/ that might need X11 - so maybe a more specific test can
be found.

> > You wouldn't happen to be getting an OLD version of...
> 
> Oops, yeah, I had 1.9.0-rc2 installed in /opt and it was in PATH and in 
> Moved it out of the way and today's CVS compiles just fine. Sorry for ...

Whew, that's a relief ;)

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] hi-res matrix - not the best image quality?

[Steven M. Schultz]

On Tue, 6 Nov 2007, Florin Andrei wrote:

> The following patch fixed it:

Well, 'worked around' ;)  On some systems that have SDL built to
include its own depencendies then included -lX11 again causes 
an error.  

> -SDL_LIBS = -L/usr/lib -lSDL
> +SDL_LIBS = -L/usr/lib -lSDL -lX11

Which says that the SDL kit wasn't built or installed quite 100%
correct.  If I run "sdl-config --libs" here I see:

-L/usr/local/lib -Wl,-rpath,/usr/local/lib -lSDL -lm -ldl -L/usr/X11R6/lib -lX1 
-lXext

which means that since SDL uses/needs the X11 libraries it includes
them and doesn't rely on the higher level applications adding them.

That's why I don't see the problem (on the 3rd different OS I've 
tried) - SDL is configured to include its own dependencies.

A better workaround would be to edit the sdl-config script and add
the -lX11 there.  That way it will be available for all applications
as well as future mjpegtools builds

> /bin/bash ../libtool --mode=link g++  -march=k8 -mtune=k8 -g -O2 
> -pthread-o mplex  main.o libmplex2.la  -lm  -lm
> g++ -march=k8 -mtune=k8 -g -O2 -pthread -o .libs/mplex main.o 
> ./.libs/libmplex2.so -lm -Wl,--rpath -Wl,/opt/mjpegtools/lib
> ./.libs/libmplex2.so: undefined reference to `mjpeg_loglev_t'
> collect2: ld returned 1 exit status
> make[2]: *** [mplex] Error 1
> make[2]: Leaving directory `/home/florin/work/mjpeg_play-cvs-20071106/mplex'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/florin/work/mjpeg_play-cvs-20071106'
> make: *** [all] Error 2

./utils/mjpeg_logging.c:mjpeg_loglev_t(const char *level)
./utils/mjpeg_logging.h:mjpeg_loglev_t(const char *str);

so it would seem that ../utils/.libs/libmjpegutils.so isn't being
included when linking mplex.  Another thing which doesn't happen,
it seems, outside Ubuntu.

> Well, it's Ubuntu 7.04 with the Ubuntu Studio packages installed (plus a 
> bunch of multimedia-related libs and apps), but I'll be happy to be a 

You wouldn't happen to be getting an OLD version of
libmjpegutils.so from somewhere?  It is an installed library and
if Ubuntu or an old mjpegtools was present and found first
(due to the order of library search path) that would explain
`mjpeg_loglev_t' being undefined - that routine is present in
utils/mjpeg_logging.c

Makes sure that utils/.libs/libmjpegutils.so is being used and
that the undef'd symbol is present in that.

Cheers,
Steven


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] hi-res matrix - not the best image quality?

[Steven M. Schultz]

On Tue, 6 Nov 2007, Florin Andrei wrote:

> I checked out the CVS about 30 minutes ago. make fails.
> rc2 compiles just fine.

Current cvs compiled fine this weekend on a SuSE 10.2 system so it
is puzzling why the problem:

> /usr/lib/libSDL.so -lm -Wl,--rpath -Wl,/opt/mjpegtools/lib
> ./.libs/liblavplay.so: undefined reference to `XOpenDisplay'
> ./.libs/liblavplay.so: undefined reference to `XGetWindowAttributes'

of not linking in -lX11 is happening.

I know what the problem is but not why it's happening to you.  
My guess is it was how the SDL was built/installed.

The fix is to add back in the X libs but that can't be done the
way it was being done because then the linker gives a fatal error
on OSX.

The temporary workaround is to edit lib lavtools/Makefile and add
"-lX11" after the "-lSDL".

I can try to fix the problem but since I don't have a system where
the problem happens it'll be a 'try it now and see if it works
this time' type of thing.

Steve


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc is feeling better

[Steven M. Schultz]

On Mon, 5 Nov 2007, Florin Andrei wrote:

> I said this before - you guys should make releases way more often. Very 

Of what?  Broken software?   No sense doing a release for the last
year or whatever since it was broken.  And now it _may_ be fixed
and it's time for testing, not a release.

> few people are going to track the CVS.

Then I guess they're not the folks that should be testing unreleased 
and possibly buggy software, right?  That's more of a developer 
(or development assisting) activity and that's what CVS is for.

A release means that testing has been done .  Testing is done out of
cvs and not a release.

> BTW, if I'm using 1.8.0 (default on Ubuntu), what do I get if I upgrade 
> to 1.9.0 RC1?

The last known working encoder perhaps.  I think it was after RC1 
that things broke  rather badly.  Number of the filters were enhanced
and I think the deinterlacing and denoising software was heavily
revised.

Now if you get the current CVS there's memory leaks fixed, further
revisions  / rewrites of the utils/filters.  Build support for OSX
10.5 (done just a couple days ago ;)) and lots more - I don't keep
a list in mind (that's what CVS is for ;))

Cheers,
Steven


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc is feeling better

[Steven M. Schultz]

On Sun, 4 Nov 2007, Andrew Stevens wrote:

> $229... inexpensive ... cough cough.  I've got MIPS and hard-disk space up the

Sure - compared to the ADVC300 or something like the Aja IO/LA
(http://www.aja.com/html/products_Io_IoLAD.html but can do everything
from 10bit uncompressed to DVCPRO50).

Think of the expenditure as a new accessory for the motorbike ;)

> wazzoo but my living-room box has got firewire. I was looking more a 
> recommendation for a straight analog capture card $50-$80 range

If it has firewire then you're set.

And an external ieee1394 converter box can be used on systems
without PCI slots (and those are becoming harder to find as PCIe
takes over).  If you have another system, a notebook for example,
you simple move the external converter box over to the notebook.
Try that with a PCI card :)

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc is feeling better

[Steven M. Schultz]

On Fri, 2 Nov 2007, Andrew Stevens wrote:

> Andrew here (mpeg2enc author).

> IF Steven and I are currently using the same test sample then the high q 

We are  - and yes it is rotten quality (tape was on the verge of
causing the VCR to mistrack).  The original 4:2:2 uncompressed data
was better but after the mjpeg-A downconvert (using mjpegtools ;))
the quality took another drop.

> bit-rate specified the quantisation level is reasonable.  Some of the 
> artefacts are in fact already present in the original MJPEG file.

The specific problem I had in mind was the blocks/squares that are
visible in the blue areas of the sky - those blocks are not visible
in the Bitvice encoded .m2v file.

HOWEVER - the new and improved mpeg2enc is vastly better than it was
2 days ago! 

I'll move on to better data now.

> LML33 support seems to have died in recent 2.6 kernels and I appear to have...

I think that's the general direction that MJPEG support's headed
as cards cease to work or be supported...

> Anyone got a recommendation for an inexpensive analog capture card that works 
> well with mjpegtools?

For inexpensive nothing beats a Canopus ADVC-110 (the -300 is good
but I've come to the conclusion it's not worth the extra money over
the 110).  Use dvgrab/kino to do the acquisition and editing.

the 'j' in mjpegtools is a bit out of place perhaps today :)

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc is feeling better

[Steven M. Schultz]

On Fri, 2 Nov 2007, Christian Ebert wrote:

> > mpeg2enc that restore (or should restore ;)) normal operation
> > and produce non corrupted video.
> 
> Great!

Well, I thought so too at first.

But look at the "q=" lines!  If you're seeing "q=18" or so then
there are still issues to be resolved.

> At first glance, all looks fine.

Hmmm, I encoded a test clip and it still looks awful :(   Better
than before but still not good.

> Feeling better as well.

Changes are in progress but it'll be a while still I think before
it's back to where I'd trust it.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

[Mjpeg-users] mpeg2enc is feeling better

[Steven M. Schultz]

Good News.

The author/maintainer of mpeg2enc has obtained a modicum of 
development/free time and has checked in, today, changes to
mpeg2enc that restore (or should restore ;)) normal operation
and produce non corrupted video.

So, do a 'cvs update', rebuild and commence testing.

Cheers,
Steven Schult


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] compiling on amd64

[Steven M. Schultz]

On Wed, 19 Sep 2007, mike wrote:

> sorry for my spartan informations

Usually the gcc and cpu info are enough - thanks for the info and
the suggested change.

> my modification on cpuinfo.sh:
> ...
> 6) iproc=686
>if test "$pmodel" -ge 15; then  #this is new
> proc=nocona
> #this is new
>elif test "$pmodel" -ge 13; then
> proc=pentium-m

That looked like a good idea so I checked the change into CVS.

Thanks!

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdeinterlace bug?

[Steven M. Schultz]

On Wed, 19 Sep 2007, Christian Ebert wrote:

> Are you sure? I still get output like

No, I am not sure. I had forgotten that mpeg2enc is a wrapper
around the loadable module libmpeg2encpp

> If I save the libmpeg2encpp.* for mjpegtools-1.9.0rc1 as well and
> copy the libraries back it seems to work at first glance.

Right, you can leave mpeg2enc itself alone - just replace the
libraries:

libmpeg2encpp-1.9.0.1.1.dylib   libmpeg2encpp.dylib
libmpeg2encpp-1.9.0.dylib   libmpeg2encpp.la
libmpeg2encpp.a

At least then you can use the recent utilities with the old unbroken
encoder.

Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] compiling on amd64

[Steven M. Schultz]

On Tue, 18 Sep 2007, mike wrote:

> i try to compile mjpegtools-1.9.0rc2 on my x86_64 multilib enviroment. 

I am not sure if that's enough information (it'd be nice to know
the distribution, version of gcc, etc) but I think a workaround
for the problem can be produced.

> but i get a strange error from make:
> configure: - MMX/3DNow!/SSE enabled  : true
> configure:   - arch/cpu compiler flags   : -march=pentium-m 
> -mtune=pentium-m

Isn't the "pentium-m" model the portable/notebook variant?  It's
been a long time since I've given much attention to the cpu model
info bits.

> how can i change the '-march' and 'mtune' option to generic or core2 or 
> athlon64? CC="gcc -mtune=generic" dosn't work. how can i compile without 
> this error?
> has anyone a idea?

--with-extra-cflags=flags

So you specify 

   --with-extra-cflags="-mtune=k8 -mcpu=k8"

(or whatever value you want to use).

The values you specify will override the values from cpuinfo.sh

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdeinterlace bug?

[Steven M. Schultz]

On Fri, 14 Sep 2007, Stan Gammons wrote:

> Actually I was wondering if the over compression problem has been fixed
> in CVS. The older version of mjpegtools I have is from March of this

Nope - it has not.   There is some (small) hope that the situation
will improve but it's a ways off ;(

Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdeinterlace bug?

[Steven M. Schultz]

On Thu, 13 Sep 2007, Stan Gammons wrote:

> On Thu, 2007-09-13 at 19:29 -0700, Steven M. Schultz wrote:
> > You should be able to fetch the CVS version - just ignore the mpeg2enc
> > executable (save your old one).
> 
> Better CVS instructions on how one does that?  All the mjpegtools source
> I have is pre-broken mpeg2enc.

cp /usr/local/bin/mpeg2enc /usr/local/bin/mpeg2enc.save

the usual

cvs checkout; ./autogen.sh; ./configure ; make install

cp /usr/local/bin/mpeg2enc.save /usr/local/bin/mpeg2enc

voila - you have the current cvs with the previous mpeg2enc

if that doesn't work then I guess just leave the video interlaced

Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdeinterlace bug?

[Steven M. Schultz]

On Fri, 14 Sep 2007, Mark Heath wrote:

> I haven't looked thoroughly into this but it appears that the version  
> of yuvdeinterlace crashes on 480 height files, while works fine on  
> 576 height files.

yuvdeinterlace has had buffer allocation/addressing issues - in one
case would end up calculating addresses outside of malloc'd memory 

I made a commit on March 6 2007 to work around one crash.

http://sourceforge.net/mailarchive/message.php?msg_id=E1HOOPS-0005dV-Gr%40sc8-pr-cvs7.sourceforge.net

> I'm not sure which version I am using, the tool doesn't have any  
> version information, it is the Motion-Compensating-Deinterlacer.  I  
> did compile it from the 1.9.0rc2, I'm not sure if there have been any  

There have been a few changes to the tools since 1.9.0rc2 - I know that
I had to disable the use of some Altivec routines if yuvdeinterlace
was used on a PPC platform.

> Thread 0 Crashed:
> 0__memcpy + 556 (cpu_capabilities.h:189)
> 1deinterlacer::temporal_reconstruct_frame(unsigned char*,  
> unsigned char*, unsigned char*, unsigned char*, int, int, int) + 108  
> (yuvdeinterlace.cc:175)
> 2deinterlacer::deinterlace_motion_compensated() + 112  
> (yuvdeinterlace.cc:709)
> 3main + 1856 (yuvdeinterlace.cc:1033)
> 4_start + 340 (crt.c:272)
> 5start + 60

That looks somewhat familiar.

You should be able to fetch the CVS version - just ignore the mpeg2enc
executable (save your old one).

Steven Schultz


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] [PATCH] [554/2many] MAINTAINERS - ZR36067 VIDEO FOR LINUX DRIVER

[Steven M. Schultz]

On Tue, 14 Aug 2007, Bernhard Praschinger wrote:

> Did you know that one major part of the mjpegtools is/was the driver for 
> the zoran based video cards. ;)

'was' is probably the best word at this point :) :)

> And that is a patch for the MAINTAINERS file in the Linux kernel.

So it should go to the Linux kernel mailing list, right? ;)  

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] [PATCH] [554/2many] MAINTAINERS - ZR36067 VIDEO FOR LINUX DRIVER

[Steven M. Schultz]

On Sun, 12 Aug 2007 [EMAIL PROTECTED] wrote:

> Add file pattern to MAINTAINER entry

Interesting - just one problem though...

> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b21841e..d291a71 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5244,6 +5244,7 @@ M:  [EMAIL PROTECTED]
>  L:   mjpeg-users@lists.sourceforge.net
>  W:   http://mjpeg.sourceforge.net/driver-zoran/
>  S:   Maintained
> +F:   drivers/media/video/zoran_*
>  
>  ZR36120 VIDEO FOR LINUX DRIVER
>  P:   Pauline Middelink

mjpegtools doesn't have a MAINTAINERS file

Was the patch intended for another project somewhere?

Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Compiling Problem

[Steven M. Schultz]

On Mon, 30 Jul 2007, Bernhard Praschinger wrote:

> I have a strange problem compiling the mjpegtools on my debian.
> With gcc: 4.1.2 20061115
> 
> It failes with that error:
> Making all in y4mdenoise
> make[2]: Entering directory 
> `/home/bernhard/download/cvs/mjpeg_play/y4mdenoise'
> if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/local/include -I../utils 
>-DNDEBUG -finline-functions -fno-PIC -march=pentium-m 
> -mtune=pentium-m -g -O2 -pthread  -MT newdenoise.o -MD -MP -MF 
> ".deps/newdenoise.Tpo" -c -o newdenoise.o newdenoise.cc; \
>  then mv -f ".deps/newdenoise.Tpo" ".deps/newdenoise.Po"; else 
> rm -f ".deps/newdenoise.Tpo"; exit 1; fi
> MotionSearcher.hh: In instantiation of 'MotionSearcher int, short int, int, 4, 2, short unsigned int, Pixel int>, ReferencePixel Pixel >, ReferenceFrame unsigned int, unsigned char, 1, Pixel >, short 
> int, int> >::MatchThrottleFloodFillControl':
> MotionSearcher.hh:507:   instantiated from 'MotionSearcher char, 1, int, short int, int, 4, 2, short unsigned int, Pixel char, 1, int>, ReferencePixel Pixel >, ReferenceFrame unsigned int, unsigned char, 1, Pixel >, short 
> int, int> >'
> newdenoise.cc:32:   instantiated from here
> MotionSearcher.hh:2444: internal compiler error: in tsubst, at cp/pt.c:7226
> Please submit a full bug report,
> ---END---
> 
> Than I have used the older g++ 3.3 and than I was able to compile it.
> Is that problem more g++ related or more to the y4mdenoise ?

Searching the mjpeg-users mailinglist archive (put y4mdenoise into
the search box) gives a number of results with "Compile error" in
the subject.

Here is the first one (which also lists some possible workarounds):

http://sourceforge.net/mailarchive/message.php?msg_id=eqj7om%24a15%241%40sea.gmane.org

It's not a new problem.  Looks like it is a  g++ compiler bug.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] "mpeg2enc is currently broken"

[Steven M. Schultz]

On Sun, 22 Jul 2007, sean wrote:

> Steven M. Schultz wrote:
> ..
> > 
> > That's why I switched to a different encoder (which as it turns
> > out gives better quality anyhow ;))
> 
> Any hints appreciated. What do you use??

BitVice from Innobits:

http://www.innobits.com/

Only for OSX but that was fine with me.  I'd already moved 
most of the video processing to the Macs some time ago so when
mpeg2enc broke I bought BitVice (had been hearing good things about
it for quite a while).

Downside is that the program can't be piped into - but disk is cheap
so it's not a problem to create an intermediate Quicktime file.

It's a complete 2-pass encoder so encodes take longer (unless you turn
on the 1-pass mode) but the quality is good (the blocks/splotches in
dark/dim areas are almost nonexistent)

Cheers,
Steven Schultz


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] "mpeg2enc is currently broken"

[Steven M. Schultz]

On Sun, 8 Jul 2007, David Kramer wrote:

> So what's the deal?

The maintainer/creator/person-who-broke-it is busy and has had no
time or inspiration to fix the bug introduceed during the last set
of changes (before becoming too busy)

> What's actually broken?

rate control logic in the encoder.

> When will it get fixed?

Either 1) when  the author has time and inclination or 2) when
someone else understands the code and volunteers to do the work

That's why I switched to a different encoder (which as it turns
out gives better quality anyhow ;))

Cheers,
Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Tue, 15 May 2007, herve.flores wrote:

> ...THANKS !!!

You're welcome.

> I tried it today, same behavior than with the original version (re- 
> thanks, thanks, thanks)

I am glad that the program is working for you.

> PS: if you decide to incorporate it in the mjpegtools, warn me, I  

I have no plans, at this time, to incorporate/integrate the program
into mjpegtools.  But that could change if enough folks indicate
an interest in having the program (including any bugs ;))

Cheers,
Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Tue, 15 May 2007 [EMAIL PROTECTED] wrote:

> You are right. There *is* a big difference between these two...  
> :-) Could you please fix your fix?

Only when you fix the code so it doesn't crash on my systems.

*before* yuvdeinterlace crashed.

*after* it does not crash.

Since yuvmotionfps is based on an older version of the deinterlacer
logic the problem, I think remains.  IF that is incorrect I can
add yuvmotionfps to mjegtools CVS and you can "fix" it (since it
appears to be an abandoned program).

I do not fix programs which 1) are working and 2) do not crash :)  So, 
no - I am not going to fix yuvdeinterlace.   If you need an account 
on the system where it will crash with the OLD way of doing things 
let me know - that can be arranged.

If yuvmotionfps works and doesn't crash then I have to say the same 
thing ;)

BUT the concept of vastly overallocating buffers strikes me as nonsense.
Why can't the code properly check the boundary conditions and NOT
"overshoot" (and thus access areas outside the frame)?  Is that too 
hard?  (a few more lines of code perhaps ;)? 

'night.

Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

The yuvmotionfps.tar.bz2 posted a few minutes ago has a bug that
will corrupt the output - I forgot to delete a debug printf()
statment.

You can either delete the printf (line 110 in motionsearch_deint.c)
or use the revised .tar.bz2 file attached to this mail item

Sorry for the confusion.

Steven Schultz


yuvmotionfps.tar.bz2
Description: Binary data
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Mon, 14 May 2007, herve.flores wrote:

> thanks a lot, no pb for the compilke, but the tool crashes on my PPC  
> computer with this build 

cpu arch (intel or PPC) has, as it turns out, NOTHING to do with it.
Program would crash on an Intel based MacBookPro.  I haven't tested
on other systems BUT I think there would be problems there also.

> (it certainly needs some other old stuff  from the 1.7version)

Not exactly.Or rather, "maybe" ;)

What it needed was a proper declaration of the 'psumsq' (pointer to 
the sumsq function).  That s

> just for info, a log from my system (maybe it can explain something  
> to you?):

Thanks but as you might have guessed I needed more.  Even then it
took a long time to figure out what the problem was.

There were, I think, 2 problems.  One is that motionsearch.h is NOT
installed by the mjpegtools installation and this line is needed in
motionsearch_deint.c (where psumsq() is called):

extern int (*psumsq) (uint8_t *blk1, uint8_t *blk2, int rowstride, int hx, int 
hy, int h);


But even after doing that there is the same type of error that
was found in yuvdeinterlace.

There is a HUGE difference between:

nframe[0] = buff_offset + (uint8_t *) bufalloc (buff_size);

and

inframe[0] = (uint8_t *) bufalloc (buff_offset + buff_size);

The FIRST one is what was being done.  It allocates a buffer of
buff_size bytes and THEN modifies the pointer.

The SECOND line allocates a larger buffer to allow for overshoot

Also, I changed the 'malloc' to be bufalloc() which will allocate
properly aligned buffers (required by MMX and Altivec routines).

Try the attached source kit and see if it works (it should at least
NOT crash ;)).

If it doesn't work then well, try Compressor2 - I'm out of free time
for a few days ;)

Cheers,
Steven Schultz


yuvmotionfps.tar.bz2
Description: Binary data
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc: status of low quality settings on ix86

[Steven M. Schultz]

On Mon, 14 May 2007, Jonathan Woithe wrote:

> Ok, I must be blind.  Ever since the issue came to light I've been watching
> for news on it but I never saw anything.

I was referring to -q discussion in general.  It felt to me that
have been many threads of discussion about "quality" and -q.

> > "or so" ;)  The mmx code was rewritten/updated/modified between
> > December 2004 and March 2005 to workaround/fix the issues with
> 
> Right.  I'm blind. :-)

Was so long ago I'd forgotten about it -  a "ls -lt" in the 
source directory refreshed my memory.

> > Last known working mpeg2enc is RC1.  RC2 is broken.
> 
> Given this I assume it's known what broke it and that it will be fixed
> before RC3 (or final) is released.  Is anyone working on it at the moment
> or is there a need for more eyes?

As far as I know nothing's been done .  All I did was effectively
disable the program to prevent complaints about corrupted and/or
poor quality.

The author/maintainer knows about it - but alas he is at a new
job and doing a lot of coding there which doesn't leave much 
time (or inspiration) to do more coding/debug at home ;(

Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Fri, 11 May 2007, herve.flores wrote:

> http://jcornet.free.fr/linux/yuvmotionfps.html
> the last time I managed to reach jerome was... two years ago (he  
> doesn't answer anymore :-(

480KB download, most of it is an OLD copy of mjpegtools.

> yuvmotionfps comes with a configure from mjpegtools 1.7 (and this old  

It is worse than that.  It comes with copies of old mjpegtools 1.7
utils/ directory instead of using mjpegtools that is installed on a 
system.

Out of the 480KB download for yuvmotionfps-1.6 only a total of *6*
files (about 6KB compressed) are needed.A build script is all
that is needed.  No autoconf or automake is needed.  

I created a build.sh script that will build yuvmotionfps using
mjpegtools installed on a system.

It is called yuvmotionfps-1.7 to distinguish it from the older
1.6 version that has benn, apparently, abandoned.

bzcat yuvmotionfps-1.7.tar.bz2 | tar xpf -
cd yuvmotionfps-1.7
./build.sh

Then copy/move/whatever yuvmotionfps to the desired location.

Cheers,
Steven Schultz


yuvmotionfps-1.7.tar.bz2
Description: yuvmotionfps cleaned up
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Fri, 11 May 2007, Stefan M. Fendt wrote:

> :) Basicaly "optical-flow" in marketing-lingo just means it is not 
> block-based but a dense field (vector for every single pixel)... That's 
> why it is so slow... If you look into the papers dealing with that 

Slow is almost an inadequate word ;)  Yes, processing each pixel
intead of 16x16 or 8x8 blocks slows the process down.  looks good
though if you have the patience ;)

Cheers,
Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Fri, 11 May 2007, herve.flores wrote:

> http://jcornet.free.fr/linux/yuvmotionfps.html

Ok.  

> the last time I managed to reach jerome was... two years ago (he  
> doesn't answer anymore :-(

So it is an abandoned program :-(

> yuvmotionfps comes with a configure from mjpegtools 1.7 (and this old  
> version desn't compile on macintel)
> take a look to the configure verbose I sent in this thread ;-)

I didn't pay attention to the beginning of the thread ;)

But if it's an autoconf problem then running either ./bootstrap
or ./autogen.sh (if either of those are provided) will regenerate
the ./configure script.

If neither ./bootstrap or ./autogen.sh are provided then you can
try this:

   autoreconf -f -i

to recreate the ccnfigure script.

> I tried it last year, TOOoo slow! (and not really better than the  
> tool)

 I thought the motion was supposed to be a little better looking while
 the deinterlacing was not quite as good.

> I don't want to use a commercial product for this "simple use"
> (and -from memory- Compressor doesn't know separate fields in  
> progressive frames, then you'll always loose half of your  

Not 100% true.  Compressor knows about interlaced video and can encode
it. 

It (Compressor) is not a deinterlacing tool, that is correct.  So
maybe if you have interlaced video it should remain interlaced during
the  conversion process.

> yuvmotionfps is not bad (not perfect, it makes some ghosts) but I  
> think it's the best free soluce (but I don't manage to compil it  anymore :-(

If I have some free time this weekend maybe i'll look at it - but
recreating the ./configure script might be all that is needed

Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Fri, 11 May 2007, Stefan M. Fendt wrote:

> Am Donnerstag, den 10.05.2007, 20:07 -0700 schrieb Steven M. Schultz:
> 
> yuvmotionfps is an external program, yes. I can not reach the guy who

Oh, ok - that explains why I couldn't find it ;)

> experience with Macs, I hoped you could help out in this case... (For
> me, at a first glance, it looks like some broken gcc which doesn't
> understand some flags, but ...)

If I saw any errors I could comment on them but the mail item
I responsed to had no additional information.

> ... which should give worse results, than the posted script, as they

Maybe, but you'll never know for sure - no Mac experience :)

Compressor does what is called optical flow analysis (advanced form
of motion compensated frame interpolation if I decode the marketing
lingo correctly ;)).  *SLOW* but very good.

Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] mpeg2enc: status of low quality settings on ix86

[Steven M. Schultz]

On Fri, 11 May 2007, Jonathan Woithe wrote:

> For a long time there have been known issues with encoding at low quality
> factors such as q=2 (ie: high quality encoding) on ix86.  I understand this

Not -q again.  Seems like just yesterday there was (yet another)
discussion about it.

> was due to something related to potential overflows in some parts of the MMX
> code.  From memory the general recommendation from a year or so ago was that

"or so" ;)  The mmx code was rewritten/updated/modified between
December 2004 and March 2005 to workaround/fix the issues with
overflow in the mmx routines.  

> on ix86 one shouldn't go below a "q" value of 3.

That's still, if you understand what -q is and so on,  good advice 
most of the time ;)  

> What is the current status on this - does mpeg2enc still suffer this
> limitation or has it been dealt with?

The current state, since approximately Feb 19, 2007, is that mpeg2enc
is BROKEN and should not be used.  If you DO use it then -q of 4 or
higher MAY produced uncorrupted output.  

Last known working mpeg2enc is RC1.  RC2 is broken.  Current CVS
has mpeg2enc effectively disabled (you can remove the error_exit call
if you want to use the program).

That is why I mentioned the BitVice encoder - not as flexible but the
output is fantastic (6Mb/s never looked so good!).

Cheers,
Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Standards converter?

[Steven M. Schultz]

On Thu, 10 May 2007, Stefan M. Fendt wrote:

> Am Donnerstag, den 10.05.2007, 13:56 +0200 schrieb herve.flores:
> 
> > sorry for hijacking the thread but I don't manage to compile
> > yuvmotionfps in MacIntel, 
> 
> hmm, I can not say anything to Mac's... Perhaps Steven can help with
> these? 
> 
mjpegtools builds easily on both the Intel and PPC based Macs.

mjpegtools does not have a program called yuvmotionfps

I can't see anything to help with.

It's been a while since I've needed to do any standards conversion
work but if you've got a Mac then Apple's Compressor2 (soon to
be Compressor3) program is slow but produced excellent output.  The
alternative (highly regarded but I have no personal experience)
is a Final Cut Pro plugin:

http://www.nattress.com/Products/standardsconversion/standardsconversion.htm

Cheers,
Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] bugs in mjpegtools-1.9.0rc2

[Steven M. Schultz]

On Wed, 9 May 2007, Petr Cerny wrote:

> > missing #include 
> 
> If you don't like malloc.h, probably posix_memalign() could be of use.

If you look more closely at the code you will see that the 
reference to memalign() (for which malloc.h is needed) is in the
posix_memalign() error handling.  If posix_memalign() fails (or is
one of the broken implemtations) then memalign() is used.

Changes have been made to check for malloc.h and conditionally
include malloc.h if it exists (it does not exist on all systems).

> if( qtchroma == QUICKTIME_YUV420 ){...}
> 
> Iit might be better to use:
> if(strcmp(qtchroma,QUICKTIME_YUV420)==0){...}

That will work since earlier usage of 'qtchroma' was 

qtchroma = QUICKTIME_YUV420; 

> (although under some conditions it will have the desired effect).

True.  Usually that is a bug - makes sense to change it.

Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] bugs in mjpegtools-1.9.0rc2

[Steven M. Schultz]

On Sun, 6 May 2007, Bernhard Praschinger wrote:

> I have got a bug report from Petr, he found in the mjpegtools RC2.
> 
> The patches look ok for me

Any patch that uses malloc.h is incorrect.

malloc.h should NEVER be used.  It was deprecated a decade or more
ago.  Also it does not exist on some systems.

> 2) mjpegtools-1.9.0rc2/utils/cpu_accel.c:364,368:
>   implicit declaration of 'memalign'
> 
> missing #include 

Incorrect.

Use  instead.And  is already bine

man memset

> Patches for both are attached. Please confirm, whether the first one is
> correct.

The other part of the patch looks ok - fixes what is obviously a
typo.

Cheers,
Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Authoring problems - size matters

[Steven M. Schultz]

On Mon, 23 Apr 2007, Edouard Chalaron wrote:

> Anne
> use y4mscaler to shrink your file:
> 
> | y4mscaler -O size=480x576 | etc ..
> 
> At least for PAL countries.. Surely there will be a NTSC version ... 

This is for a DVD, correct?

If a DVD is being created then you can NOT use 480x576!

For 625line video system (PAL countries) the Valid DVD frame sizes are: 
 

   352x288 (MPEG-1), 352x576, 704x576, 720x576

(corresponding 525line sizes are: 352x240, 352x480, 704x480 and 720x480)

> >   The only remaining problem is how to test it.  Sadly, 
> > it's 4.8GB.  I don't want to use dual-layer disks as coasters :-)  I'll have
> > to try to find a way to get xine to play direct from the directory.

Beware: using a software player for testing is not foolproff.  xine
would probably play an invalid DVD (one that uses 480x576) but a real
hardware player would reject it (actually the DVD authoring software
should reject 480x576).

If the video is 4.8GB then reducing the bitrate 8-10% should be
enough to fit the video on a single layer disc. 

Cheers,
Steven Schultz


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Mixing old and new recordings

[Steven M. Schultz]

On Sat, 31 Mar 2007, Anne Wilson wrote:

> > http://www.mediachance.com/dvdlab/
> >
> > Not very expensive and it runs under WINE

> It does look interesting.  Since I'm dealing with old Hi8 tape and an analo
> gue=20
> recorder, I still have to capture with the DC10+.  Do these editing suites

Are you sure you're looking at the same thing I hoped I was pointing
you to?  DVD-Lab is an authoring program.  It is NOT a capture program,
it is not a editing program.  

You do all the encoding in advance and present Dvd-Lab with the
MPEG-2 video files and accompanying audio (.AC3, or .MP2).

> start from .avi files?  The linux ones I've seen are generally aimed at
> starting from digital video.

"all in one" programs, in my opinion, tend to be "jack of all trades
and master of none" - doing many things half well rather than using
better independent programs.

DVD-Lab (and DVD Studio Pro from Apple, and Premiere from Adobe for
windows) are DVD authoring *only* programs - they do not do capture,
encode, edit - there are other programs to do that.

One of my brothers, alas in the windows world, started out trying to
use one of those 'all in one' packages - didn't work well.  Tried 
a free package - that was a flop, and then bought DVD-Lab and has
been happy (at least I don't hear coasters flying overhead  now ;))

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Mixing old and new recordings

[Steven M. Schultz]

On Sat, 31 Mar 2007, Anne Wilson wrote:

> this.  I did at first try Linux Video Studio, but it only partially worked
> and IIRC it didn't work at all after the 2.6 kernels started (could be wrong
> there).  Perhaps it's time I came into the 21st century?  :-)

It is less about coming into the 21st century than it is about
using the correct tool to do a job.  Even in the 19th century folks
knew that a screwdriver probably doesn't work well with nails ;)

Much of DVD authoring (especially if you're doing complex menus)
is visual in nature thus it makes sense, to me, to use tools that
work graphically/visually.

http://www.mediachance.com/dvdlab/

Not very expensive and it runs under WINE 

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Mixing old and new recordings

[Steven M. Schultz]

On Sat, 31 Mar 2007, Anne Wilson wrote:

> This is getting technical :-)

Uh, you think "add a new track" and "create a top level menu" is
technical and they you toss a blob of xml at me?  ;)  Now that is
_technical_ 

> At the moment I just use

Makes no sense to me.  Too technical ;)

> 
>   
>
>   
>   
>   
>   
>   
>   
>
> 

> Is the  the track?

Could be.  I just click "Add New Track" and drag the .m2v/.ac3 files
over to the "Track"s as appropriate.  Trivally easy and non technical -
no xml required ;)

> How do I make a top level menu?

Click "Add Menu"? 

I do all my DVD authoring with DVD Studio Pro 4 :) 

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Mixing old and new recordings

[Steven M. Schultz]

On Sat, 31 Mar 2007, Anne Wilson wrote:

> I want to mix some old avi recordings done at half-size with some new ones at
> full size, all into one dvd.  Am I wanting the impossible?  Do I have to
> locate the original tape and start again?

You certainly can mix streams of different frame sizes on a single DVD. 
 
Trailers, etc I often put as half size and the main feature at full 
size.

However you can not mix different frame sizes within a single track.
Put the 'full size" videos on one track  and the half size on a 
different
track and you'll be fine.

Or just put each video on a track of its own with a top level menu
to select which video clip to play.

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

[Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness

[Steven M. Schultz]

Howdy -

If you're using a PPC and OS/X there is a fantastically high quality
workaround for mpeg2enc's current buggy state.

The BitVice encoder from:

   http://www.innobits.com/

works _great_.  Not all the inner tweeking capability I'm used to
but the quality has to be seen to believed...

Cheers,
Steven Schultz

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Has mp2enc changed lately?

[Steven M. Schultz]

On Tue, 20 Mar 2007, Stan Gammons wrote:

> No. I've seen several messages about aspect ratio, but I haven't
> followed it that closely.

Ah, you want the _other_ topic of recent discussion ;)

> Maybe I still have an older CVS on the 32 bit machine (I went back to

RC2 is when the problem happened - so if you have that you've got
the problem :(

> the x86_64 bit distro for processing video) that I can use in the mean
> time. I grabbed a CVS today but I haven't tried it yet.

Have fun.  Watch the "q=" lines - I'd never seen values in the 18, 20
and 30+ range before.

Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Has mp2enc changed lately?

[Steven M. Schultz]

On Tue, 20 Mar 2007, Stan Gammons wrote:

> I encoded a DV capture today using the CVS version of mjpeg tools from
> last night. I noticed the length of the m2v file is MUCH smaller than
> one of a comparable run time (roughly 25 minutes) that I encoded a week
> or two ago. In the past the m2v files were roughly 1.3 Gigabytes. Now
> they are only 400 to 500 Megabytes. Has the command line switches
> changed? Here is the script I've been using.

Have you noticed the discussions on the mailing lists about a 
nasty bug in mpeg2enc's rate control logic?

I think there have been several postings mentioning severe pixelization
and blockiness - a sign that the the encoder is over compressing
the data.

Steve Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Strange sound problem

[Steven M. Schultz]

On Sat, 17 Mar 2007, Anne Wilson wrote:

> About 20 minutes into editing a long recording I realised that the sound was
> way out of sync.  Much of the sound previous to that was background, not...

> By the end, around 45 minutes, it was around 6 seconds late.

You say the sound is 'late' - meaning that you see something happen
and then 5 or 6 seconds later you hear the sound.

If audio data had been lost/cut you would hear the soundeffect first 
and then later see the action.

That sounds like several seconds of video frames were lost.  This would
have the effect I describe above - you see something earlier than it
sounds because video has been lost.

> I'm not sure whether it was lost in one chunk, or whether it had crept up,
> but I suspect a single chunk, as it was around 5 seconds when I first 
> noticed it.

Sounds like a frame dropping problem somehwere.  6 seconds would be
~150 frames.

> I've never come across this before.  Any idea what may have caused it?

What are you using to record?  I can't say I've heard of any problems
with quality DV converters (Canopus is a good example). 

I haven't heard of this problem before.  Can you re-do the capture?

Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Lost frames and signal stabilizers...

[Steven M. Schultz]

On Wed, 14 Mar 2007, Andrea Giuliano wrote:

> Okay, but here comes another problem: AC in USA has 60Hz frequency, in 
> Italy the frequency is 50Hz. So the stepdown transformer would give the 
> right voltage (120V), but the wrong frequency (50Hz), and the adapter 
> shipped with the CT2 could have problems: on it I read "120V/60Hz", no 

I think it will work fine.  The only other things to try are
either a higher quality 7.5V DC conversion unit OR a similar video
stabilizer manufactured in Europe (they are made - perhaps someone
living in Europe can post an example or two).

> I don't know if I made the point clear, sorry for my poor english.

Your english is fine.  Electronics just does not happen to be your
area of expertise ;)

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Lost frames and signal stabilizers...

[Steven M. Schultz]

On Mon, 12 Mar 2007, Andrea Giuliano wrote:

> It sounds as a good idea, but can you explain what a "stepdown 
> transformer" is? I guess a "transformer" is an equipment that converts 
> an alternate current from a voltage to another

Precisely.  

> frequency, and I don't know if that's the same for Europe and USA. Does 
> "stepdown" refer to the frequency or just to the reduction of voltage?

Leaves the frequency the same.  A stepdown transformer would convert
240V 50Hz AC to 120V 50Hz AC.  The power adaptor that came with the
CT2 should be able to go from that to 7.5V DC

Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Lost frames and signal stabilizers...

[Steven M. Schultz]

On Sun, 11 Mar 2007, Andrea Giuliano wrote:

> At last I bought it, brand new, just the model is CT2, not CT200, but 
> many people told me they are actually the same item.

The CT200 is an upgraded CT2.  CT200 has a couple more "enhancement"
modes but the 200 is quite a bit more expensive.

> Now the bad surprise: on one hand it notably reduces lost frames, but on 
> the other hand it produces a rather waving (or wiggling?) picture every ...
...
> mean is that the picture itself is not "stable", like a picture on a 
> sheet of paper that someone moves makeing waves on the surface.

> The seller told me that the problem could be the european frequency (I 

I think he is correct.

> clearly had to buy a universal adapter to get the 7.5 V DC input for the 
> item), but I'm not so familiar with electrical engineering.

Hmmm, that is one approach but perhaps not the best one.

> Could it really be this the cause of the problem? It seems questionable 

Yes - I think it could be the cause.

> Indeed, it could do that not very well, the current may be not so 
> "direct" as CT2 requires, I don't know.

Correct.  What you *may* be seeing the 50Hz ripple - basically means
the converte is not properly regulating/filtering its output.

> Any hint?

Can you try a stepdown transformer?  By that I mean use the power
120V -> 7.5V adaptor that came with the CT2  BUT use a transformer
to go from 240/220 -> 120V.  It could be the quality of the 7.5V
makes a big difference.  

Or get a TBC (Time Base Corrector) but those are about 10x what the
CT2 costs ;(

Cheers,
Steven Schultz

p.s. put "Sima CT2" into a Google search - many reports of success but no
 mention of waves/wiggling/shimmering of the picture.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Failed to build a debian package from 1.9.0rc2

[Steven M. Schultz]

On Wed, 7 Mar 2007, Santiago Vila wrote:

> My machine is a powerpc machine running Debian testing (aka etch).
> 
> 1. dpkg-buildpackage believes the package is version 1.7.0-1 because
> of the first changelog entry in debian/changelog. Please put something
> like 1.9.0-0
> 
> mjpegtools (1.9.0-0) unstable; urgency=low
>   * New upstream release.
>  -- Kawamata/Hitoshi <[EMAIL PROTECTED]>  Wed,  7 Mar 2007 17:03:26 +0100

> 2. Compatibility levels before 4 are deprecated.
> 
> Please use "debhelper (>= 4)" in debian/control (and control.in)
> and use "export DH_COMPAT=4" in debian/rules.

Ok those changes have been made.  I have no way of testing the changes
though.

Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Failed to build a debian package from 1.9.0rc2

[Steven M. Schultz]

On Wed, 7 Mar 2007, Santiago Vila wrote:

> I downloaded mjpegtools-1.9.0rc2 and tried to build a debian package
> using the debian/* files inside the tarball.

> My machine is a powerpc machine running Debian testing (aka etch).
> 
> Suggestions:
> 
> 1. dpkg-buildpackage believes the package is version 1.7.0-1 because
> of the first changelog entry in debian/changelog. Please put something


I have wondered for a long time WHY a project needs to include
and maintain distribution specific information.

Of all the distributions only 'debian' as a directory in the 
project.  Why?  It should be up to the distribution maintainers
to update/maintain/fix their build process - not the project's.

mjpegtools does not maintain SuSE, RedHat, Ubuntu (spelling?), etc.
Is Debian so special (or strange) that it requires a directory and
config files in the cvs tree of a project?

I'm primarily curious - the changes are trivial but my preference would
be to get out of distro specific maintenance.

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Diskussion on Technicolor "2-stripe"...

[Steven M. Schultz]

On Tue, 6 Mar 2007, stefan wrote:

> PS: would there be demand for an "old-film-look-filter" in the Tools?

Not from me - I spend too much effort trying to get rid of color
artifacting/problems ;)

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Request for another ML-JPEG

[Steven M. Schultz]

On Fri, 9 Feb 2007, Bernhard Praschinger wrote:

> I have found another interesting feature request in the tracker, about
> support for ml-jpeg.  where ML-JPEG is Multi-layer JPEG

> Take a look here:
> https://sourceforge.net/tracker/?func=detail&atid=355776&aid=1654963&group_id=5776

I think the person confused mjpegtools with "Codec Central" ;)

Just another "it's easy to make wishes" posting - at least that's how
it looks to me.  No links or pointers to information about ML-JPEG,
so we're not only supposed to design/create the codec but do all
the legwork/research too.

We've got enough problems - fixing y4mdenoise for example - without
adding another (somewhat obscure) codec to the TODO pile.

Cheers,
Steven Schultz


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] 1.9.0rc1 available

[Steven M. Schultz]

On Tue, 6 Feb 2007, stefan wrote:

> could we please wait with the release until I get the updated 
> deinterlacer-core into the cvs? I just ask because I have some very 

We certainly can wait.  Bernhard and I decided to push out a
first release candidate to "get the ball rolling".  It had been
a long time since any changes were made and there have been numerous
requests for an official 1.9.0 release

> pleasing *VBG*). BTW: I think I now know why the sad assembler-functions 
> do not work properly on Altivec-Machines... This would be a nice fix, 

Indeed it would be nice to have that fixed.  When I looked into the
program crashing it appears that BOTH buffer addresses being passed
to sad_00 were aligned on a 8 byte boundary. The Altivec version of 
sad_00 needs at least 1 of the operands to be aligned on a 16 byte
boundary.

Let us know when you're ready to unleash the new code to the world and
we can update to a 1.9.0RC2 

Cheers,
Steven Schultz


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

[Mjpeg-users] 1.9.0rc1 available

[Steven M. Schultz]

Hi -

It hasn't received much publicity outside the -devel mailinglist
but a 1.9.0 release candidate 1.9.0rc1 is available for download
from the Sourceforge download page.

There  are both binary and source rpms as well as a source .tar.gz file

Happy Testing ;)

Cheers,
Steven Schultz

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Compiling mjpegtools on Mac Intel (ppmtoy4m)

[Steven M. Schultz]

On Mon, 22 Jan 2007, Marco Behnke wrote:

Hi -

> > The only things I can think of to try are edit the yuvcorrect/Makefile
> > and delete all the "-mtune" and "-march" options - maybe the mismatch
> > the actual cpu type (I do not think Apple is using pentium3 cpus)
> 
> That worked for me ! Thanks a lot.

Hurrah! 

But I wonder why the "pentium3" values were present.  That is the
wrong cpu type.  Other people have compiled mjpegtools on OSX for
Intel and did not have -mtune/-march problems.

> Stay away as long as you can ;) We had the first horror when we found
> out that we have to switch to gcc 4 as gcc 3.3 isn't allowed to compile
> binaries on mac intel.

Why is that a problem?  All of my compiles have been done with gcc4 for
a long time now - works fine.  gcc4 came with OSX 10.4 - no problems.

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] Compiling mjpegtools on Mac Intel (ppmtoy4m)

[Steven M. Schultz]

On Fri, 19 Jan 2007, Marco Behnke wrote:

> ok, I mastered that step on the ladder this on is a "big & nasty" one...

> Making all in yuvcorrect
...
> if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I/usr/local/include 
> -I../utils   -march=pentium3 -mtune=pentium3 -g -O2 -no-cpp-precomp 
> -D_THREAD_SAFE  -Wall -Wunused -MT yuvcorrect_functions.o -MD -MP -MF 
> ".deps/yuvcorrect_functions.Tpo" -c -o yuvcorrect_functions.o ...

Which model of MacIntel do you have?  I thought Apple was using
recent Intel cpus and not old Pentium3 cpus - I am not sure that
"-march=pentium3 -mtune=pentium3" is correct for a Intel based MAC

> yuvcorrect_functions.c: In function 'yuvcorrect_chrominance_init':
> yuvcorrect_functions.c:704: error: unrecognizable insn:
> (insn:HI 166 165 167 10 yuvcorrect_functions.c:698 (set (reg:V4SI 144)

line 698 is 
 
   *(u_c_p++) = (uint8_t) newU;

if gcc  can not compile something that simple then the compiler
is broken :(

> yuvcorrect_functions.c:704: internal compiler error: in extract_insn, at 

Line  704 is the '}' at the end of the function 
yuvcorrect_chrominance_init.

> Sadly I have to register for money to submit bugs to apple. anyone 

Oh, there is a 'feedback' link that you can submit a complaint or 
report to - but it will be ignored :(

The only things I can think of to try are edit the yuvcorrect/Makefile
and delete all the "-mtune" and "-march" options - maybe the mismatch
the actual cpu type (I do not think Apple is using pentium3 cpus)
and the option is causing the problem.  THe other thing to try is
change all "-O2" to be "-O1" - sometimes the compiler bug is in the
optimizer area.

> had this before? Maybe anyone have a binary for mac intel?

No, no one has seen this before.  BUT, if the compiler is broken how
do you expect anyone to have a binary for mac intel? ;)

All of my Macs are PPC based - I do not have a Intel based Mac (yet).
It is time to update/replace the Powerbok... ;)

Cheers,
Steven Schultz


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users