Re: [Mjpeg-users] yuvdeinterlace bug?

2007-09-19 Thread Christian Ebert
* Steven M. Schultz on Thursday, September 13, 2007 at 20:49:06 -0700
 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

Are you sure? I still get output like
INFO: [mpeg2enc] Enc1  6 6( 6) P q=68.13 [1% Intra]
with that (MacOS 10.4.10).

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

c
-- 
_B A U S T E L L E N_ lesen! --- http://www.blacktrash.org/baustellen.html

-
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?

2007-09-19 Thread 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] yuvdeinterlace bug?

2007-09-14 Thread Mark Heath

On 14/09/2007, at 3:23 PM, David McNab wrote:


 I am thinking about doing something more intelligent than line
 doubling. (maybe adaptive blending)

 Oh yes, please do! :)

 And making better support for different chroma subsampling, but maybe
 next week.

 Less urgent, since many yuv4mpeg tools seem to be hardwired to 4:2:0.

 But in a perfect world, all the tools would support all the ss modes.

I've written some generic utility functions that handle any chroma  
plane size.
And changed the way I think about processing a video frame, so any  
new filters I write automatically support any chroma size.
I'm re-working my old filters to support these utility functions.

 There are a lot of good deinterlacing algorithms out there but most
 of the implementations are for systems other than mjpegtools.

 mjpegtools absolutely needs a lossless deinterlacer.

Any filter that doesn't touch the original scanlines while  
interpolating the missing ones could be considered lossless.
So it's up to really good interpolation algorithms to make the de- 
interlacer good.


 I've been getting great results with yuvmotionfps, especially when  
 block
 size and search radius are tuned appropriately for the footage.

I guess I don't know enough about the settings to get an acceptable  
result from it.


 What would be brilliant is a tool to convert 4:2:0 to 4:4:4alpha and
 back, and for all the mjpegtools and 3rd party yuv4mpeg tools to  
 support
 4:4:4alpha. Doing the maths to convert 4:2:0 YUV to RGB and back is
 presently a coding pain and a resource waster.

y4mscaler I know can do chroma conversion, though I'm not sure if  
alpha is supported.


 And - would be awesome if ffmpeg had options to output YUV streams  
 with
 any chroma subsampling. It seems hardwired to 4:2:0 at the moment.

Check out my libav2yuv (apart from being annoying to compile, needs  
the ffmpeg libav shared libraries)
It allows any chroma subsampling output and I find it simpler to use  
than ffmpeg.

Mark

-
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?

2007-09-14 Thread Stan Gammons
On Thu, 2007-09-13 at 20:49 -0700, Steven M. Schultz wrote:
   if that doesn't work then I guess just leave the video interlaced

That will work.

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
year. I think it was Ok then. If so, I'll compile that version an go
from there.

Thanks.


Stan




-
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?

2007-09-14 Thread 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


[Mjpeg-users] yuvdeinterlace bug?

2007-09-13 Thread Mark Heath

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.

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  
code updates since then. Or if you are aware of the bug.

this is a stack trace from the crashed executable

EXC_BAD_ACCESS (0x0001)
KERN_PROTECTION_FAILURE (0x0002) at 0x003b1e98

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

Let me know if I can help debug it.
Mark

-
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?

2007-09-13 Thread 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] yuvdeinterlace bug?

2007-09-13 Thread David McNab
There's an alternative implementation of yuvdeinterlace, unfortunately
with the same name, at:

http://silicontrip.net/~mark/lavtools/

This version performs lossless deinterlacing (extracting the fields, and
generating a stream with both fields set to double the frame rate). It
also has a 'reinterlace' option which does the reverse.

Since coming across this alternate version, I've deleted mjpegtools'
'yuvdeinterlace' from my system.

Cheers
David

On Thu, 2007-09-13 at 19:29 -0700, Steven M. Schultz wrote:
 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


-
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?

2007-09-13 Thread Stan Gammons
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.

I'm not a CVS person either, but I couldn't get it to work using the
instructions Christian gave in a previous email.  It just went out into
the la-la land when I tried.


Stan




-
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?

2007-09-13 Thread 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?

2007-09-13 Thread Mark Heath

On 14/09/2007, at 12:50 PM, David McNab wrote:

 There's an alternative implementation of yuvdeinterlace, unfortunately
 with the same name, at:

 http://silicontrip.net/~mark/lavtools/

:-) yeah that's my version.  It was for non interlace aware temporal  
filters, such as my original yuvafps (weighted averaging frame rate  
converter) but it totally screwed up the spacial representation of  
the fields.

I am thinking about doing something more intelligent than line  
doubling. (maybe adaptive blending)
And making better support for different chroma subsampling, but maybe  
next week.

There are a lot of good deinterlacing algorithms out there but most  
of the implementations are for systems other than mjpegtools.

I also improved my weighted average framerate converter after seeing  
that yuvfps was giving incorrect results on converting to very slow  
framerates. (1fps)
It can also be forced into interlace mode where it will convert a  
progressive stream into an interlace stream of a different frame rate.

I've recently added some more tools which you may find useful.

I'm finding the motion compensating de-interlacers a little slow and  
the artefacts it introduces a little annoying.


 This version performs lossless deinterlacing (extracting the  
 fields, and
 generating a stream with both fields set to double the frame rate). It
 also has a 'reinterlace' option which does the reverse.

 Since coming across this alternate version, I've deleted mjpegtools'
 'yuvdeinterlace' from my system.

Thanks for the support, it's good to hear that it is making use  
somewhere, if you need any improvements, let me know.

Mark


-
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?

2007-09-13 Thread David McNab
On Fri, 2007-09-14 at 14:27 +1000, Mark Heath wrote:
 :-) yeah that's my version.

Ohh, oops!

 I am thinking about doing something more intelligent than line  
 doubling. (maybe adaptive blending)

Oh yes, please do! :)

 And making better support for different chroma subsampling, but maybe  
 next week.

Less urgent, since many yuv4mpeg tools seem to be hardwired to 4:2:0.

But in a perfect world, all the tools would support all the ss modes.

 There are a lot of good deinterlacing algorithms out there but most  
 of the implementations are for systems other than mjpegtools.

mjpegtools absolutely needs a lossless deinterlacer.

 I also improved my weighted average framerate converter after seeing  
 that yuvfps was giving incorrect results on converting to very slow  
 framerates. (1fps)

I've been getting great results with yuvmotionfps, especially when block
size and search radius are tuned appropriately for the footage.

 I'm finding the motion compensating de-interlacers a little slow and  
 the artefacts it introduces a little annoying.

Better IMHO to go progressive at double framerate.

 Thanks for the support, it's good to hear that it is making use  
 somewhere, if you need any improvements, let me know.

I've just updated and uploaded my Python yuv4mpeg wrappers, this time
adding a much nicer/leaner/cleaner wrapper built with Pyrex. Performance
is surprisingly good given that Python code is iterating over every
pixel.

What would be brilliant is a tool to convert 4:2:0 to 4:4:4alpha and
back, and for all the mjpegtools and 3rd party yuv4mpeg tools to support
4:4:4alpha. Doing the maths to convert 4:2:0 YUV to RGB and back is
presently a coding pain and a resource waster.

And - would be awesome if ffmpeg had options to output YUV streams with
any chroma subsampling. It seems hardwired to 4:2:0 at the moment.

Cheers
David


 
 Mark
 
 
 -
 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


-
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