Re: [Mjpeg-users] yuv toolchain order

2008-05-08 Thread Stefan M. Fendt
Hi,

 Should anything be changed in this order -- set up more by what I
 feel is right than actual knowledge -- like moving yuvdeinterlace
 more up etc.?

Yes, indeed. yuvdeinterlace should (must...) be used at first, then
yuvdenoise (turn the values up to that point where you can see the first
negative effects of the denoiser and then try half the values...) and
then downscale...

Stefan



-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Zig-zag pattern on every frame...

2008-03-08 Thread Stefan M. Fendt

Hi,

 Okay, you and Burkhard suspect radio interference. But you have not seen 
 the full pictures I sent to Bernhard Praschinger.

Yes, and now I am glad, I have seen one. This clearly is _no_
interference. It is something DCT-related. I currently can't tell you
what has happend (to little time, to investigate, currently) to the
image, but all the defects are 8x8 in size and clearly show the same
strong mosaicing-pattern... It looks like one ore more DCT-coefficients
are garbage in those areas. Can't currently tell which one(s).

cu
Stefan




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-
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] Zig-zag pattern on every frame...

2008-03-08 Thread Stefan M. Fendt
Here a very small highpass-filtered cutout... Eventually it helps our
encoder-/decoder-specialists on the list?

Stefan

attachment: Pattern.jpg

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-
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] Zig-zag pattern on every frame...

2008-03-07 Thread Stefan M. Fendt

Hello Burkhard,

 Microwave oven works at 2.45 GHz, S-Video bandwidth is below 10 MHz
 - No interference

Erm,...

... Burkhard, have I offended you somehow ??¿¿??

 Next time somone blames the earth radiation

so why do you offend me?

To make you one thing clear: I do not have won my degree in the lottery.
The radiation inside(!) the microwave-oven hopefully remains inside the
microwave-oven, as otherwise you would have some very big but different
problem... (Typically _this_ radiation *can* *not* come out of the
microwave-oven anyways (if it is halfway-intact). These devices are
typically very well shielded: Faraday Cage...)

Nonetheless, you might come here and take a look: I *have* a microwave
which interferes with TV. I also have a hair-dryer, which interferes
with UHF-Radio (oh, have I forgot to mention that this one (the
Hair-dryer) does use 14 GHz? *LOL*) 

FYI: MicroWaveOvens do not only radiate on 2,4 GHz. And HairDryers
despite not having any RF-Circuit at all, can perfectly radiate
Frequencies up to 500 MHz and above if electrically not well designed
(Remember the first RF-transmitters used sparks to create a very broad
spectrum). There just does not exist any electrical device which will
not radiate any RF. 

I never have stated (or please show me!) that the interference was
caused by 2,4 GHz direct radiation of the microwave. And the
Micro-Controller-Board inside of my MWO has an oscillator-frequency of
near 50 MHz with a broad spectrum above (even and odd multiples). And
well, I can detect that spectrum a few ten meters away.

How do you come to the idea to put a technophile engineer on the same
level as those technophobe gibberish idiots(#) blaming earth radiation
(whatever that may be *Sigh*) for their headaches and lack of
intelligence?

Stefan

(#) If these people would know how much RF-power, broadband, is radiated
by lightnings, they possibly would try to outlaw lightnings...



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-
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] Zig-zag pattern on every frame...

2008-03-07 Thread Stefan M. Fendt

Am Freitag, den 07.03.2008, 15:11 +0100 schrieb Burkhard Plaum:

 I didn't mean to offend you. Someone does not necessarily mean you :)
 It was more a joke.

OK. So, what about outlawing lightnings? SCNR

 TV != S-Video cable (see below)

Yes, of course.

 Ok but even 50 MHz and it's harmonics are still much higher than the
 S-Video bandwidth :)

I totally agree (I didn't want to state that with my initial mail).

 From my experience, one thing can always safely be blamed for any kind of EMC
 problem: Switched power supplies.

I only can second that.

 In the time of CRT monitors, they were also candidates with their multi-khz
 sawtooth voltage.

And mainboards may be a hit, too... *wink*

cu
Stefan


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-
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] Zig-zag pattern on every frame...

2008-03-06 Thread Stefan M. Fendt
Hi,

Am Mittwoch, den 05.03.2008, 23:14 +0100 schrieb Andrea Giuliano:

For me it looks like it could be radio-interference...

 The cable are the same I've been using without any problem since I 
 bought the DC30+ back in 2006. I use a 35 meters long composite video 

35 meters? *WOW* Could you please try with a shorter cable? It could be
just interference. And yes it could be that the interfering radiation
only exists since Nov 6. Possibly one of your neighbors has a new
Microwave-Oven?

35m is definitely too long... Even if you only consider damping-factors.

BTW: Radio-Interference may also be caused by bad shielding/grounding
components. 

Stefan


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-
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] mpeg2enc is feeling better

2007-11-05 Thread Stefan M. Fendt

Am Montag, den 05.11.2007, 22:45 -0800 schrieb Florin Andrei:

 Oh wait, there's editing. Hm, I've heard that Cinelerra can do that, and 
 perhaps Kdenlive too.

Erm, you won't believe it: blender can do this, too... (And I personally
liked it much more than Cinelerra... it does not crash so often).

cu
Stefan


-
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

2007-11-03 Thread Stefan M. Fendt

Am Freitag, den 02.11.2007, 13:30 +0100 schrieb Andrew Stevens:

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

I have an Canopus ADVC-110 here. There is nothing out there which can
beat it. (Not even the -300). But it is *external*. Just connected to a
PC/Mac with IEEE-1394 and capture with dvgrab.

cu
Stefan


-
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

2007-11-03 Thread Stefan M. Fendt

Am Freitag, den 02.11.2007, 10:22 -0700 schrieb Steven M. Schultz:

   For inexpensive nothing beats a Canopus ADVC-110 (the -300 is good

ah, I did overlook this one... so my response was obsolete... :-)

cu
Stefan


-
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] Standards converter?

2007-05-11 Thread Stefan M. Fendt
Steven M. Schultz schrieb:
 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.
   

:) 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 
topic, you may find that even sparse MV-fields are called 
optical-flow-fields, sometimes... The techniques used are the same than 
in plain MV-search. You just have to apply some additional constraints 
which will allow the field to be more smooth and check for invalid 
vectors a little bit better...

I personaly think it is mainly more Sound(TM) than MV-estimation other 
then that it's mainly synonymous... ;-)

cu
Stefan


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

2007-05-10 Thread Stefan M. Fendt
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? 

 PSS: Why don't you incorporate directly yuvmotionfps in the mjpegtools 
 package?

I tested yuvmotionfps once in a while... It is based on some very old
motion-estimation-code from an old yuvdeinterlace variant. It can work
very good but it also can cause severe image-defects. I allways planned
to extend yuvfps for a motion-compensated processing mode, but... 

I just lack the time. I just am happy if I can do some coding on the
deinterlacer... ;-)

cu
Stefan




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

2007-05-10 Thread Stefan M. Fendt
Am Donnerstag, den 10.05.2007, 20:07 -0700 schrieb Steven M. Schultz:

   mjpegtools does not have a program called yuvmotionfps

yuvmotionfps is an external program, yes. I can not reach the guy who
wrote it (at least he doesn't react). But as I personaly do not have any
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 ...)

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

... which should give worse results, than the posted script, as they
only do motion-adaptive (not compensating) deinterlacing (But their
program should be faster...).

cu
Stefan




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

2007-05-09 Thread Stefan M. Fendt
Am Mittwoch, den 09.05.2007, 16:08 +1000 schrieb Mark Heath:

 By the way, which frame rate converter is considered the *best* at  
 the moment?

Motion compensated is the only one which makes sense:

These are the needed steps (and they allready can be done with the
mjpeg-tools...)

1. deinterlace to native frame-rate (PAL:50 Hz/NTSC 59.9xxHz)
   (with yuvdeinterlace or mplayer -vf tfields=1:1 if you do not need
   too much quality but speed...)
2. change framerate (with yuvmotionfps or yuvfps)
3. scale (with yuvscaler or y4mscaler)
4. reinterlace (with y4minterlace)

OK, here an example which gives very fluent motion (could probably be
better if using yuvmotionfps...):

lav2yuv some_PAL.dv |\
yuvdeinterlace -d |\
yuvfps -s 50:1 -r 60:1001 |\
yuvscaler -O SIZE_640x480 |\
y4minterlace -i b |\
your_favorite_encoder...

This can be done from NTSC to PAL, too (But at least I do not like to do
so, as NTSC material generaly looks bad.) You only need to change the
frame-size and -rates...

cu
Stefan


-
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] Reply to lavrec records blank

2007-05-09 Thread Stefan M. Fendt
Erm, just a tip. If you must use a BTTV-card for capturing (you really
should look for some other solution if you do captures on a regular
basis...) you must be aware of an intensional(!) bug inside the driver:

YUV 4:2:0 is broken with BTTV-cards. YUV 4:2:0 doesn't retain correct
interlacing on BTTV-cards. For progressive material (as movies in
PAL-land generaly seem to be) this is no problem. But if it is
interlaced or telecined (very rare in PAL-countries but not impossible!)
then the chroma channels are completly messed up!

*You do not want to record 4:2:0 with these cards.*

You do want 4:2:2 recordings and as far as I know lacrec can not record
4:2:2 with these cards. (A long time ago when I must use such a card, I
always used mencoder for recordings doing them 4:2:2 and then scaling
them to 4:2:0).

cu
Stefan


-
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] Greenish tint with yuvdenoise CVS

2006-04-11 Thread Stefan M. Fendt

Hi,

Nicolas schrieb:

OK. I did my tests. I used various versions of the mjpegtools, and I
confirm the green tint comes from yuvdenoise CVS. The other tools are
not responsible.
  

hmm, this is really strange, as I can not proof any chromatic shifts
when using neutral-gray test-charts as well as colored test-charts, may
they be noisy or not. I have downloaded your green-tint-version and,
well, I personaly wouldn't call that a strong tint... It is nearly not
observable for me. If it is the denoiser (which could be so -- perhaps
my tests to verify that there are no chromatic shifts are not good
enough) it only can be a reincarnation of the old rounding problem...
(and that could have happen even after I was very carefuly coding
arround it... *argh* - I hope it's not.)

The green tint appears even with low values for yuvdenoise, such as:
yuvdenoise_cvs_20060409 -v 0 -m2,6,6 -t2,6,6 -M2,6,6
  

This seems to vote for some rounding problem inside the denosier... oh,
no...

However, I just observe the green tint. I'm not quite sure it's a bug!
  

I hope, it is not a bug. I hope it is your material (which could be the
case also, as if it has a lot red specles these will be removed as being
outliers before denoising). But well, I will check the calculations it
does by hand to see, that it really rounds correctly. I really don't
want to use floats to avoid rounding errors.

Just as an example, what the *old* denoiser did: If the result of the LP
was n.m the output allways was n. It never did proper rounding. For
the luminance channel this was OK, but for the chrominance channels it
ment, that all values drifted towards zero. And as we all know, this is
green... This was a clear bug, but was easy to overlook, as it mainly
was due to the method the negative numbers in Y'Cr'Cb' are stored...

cu
Stefan (who now checks the rounding strategies inside the denoiser...
again... and hopes to find... nothing -- will also check if it's your
material)

I read in a paper magazine video CCD noise is often made of RED pixels.
Wouldn't yuvdenoise remove those red dots, and therefore increasing the
overall green tint? Moreover, even if the encoded green videos are
greener than the version I got with the non-CVS yuvdenoise, I
recognize the picture in the original footage is a bit too red! That's
probably due to those red dots.

Is there a way to reduce the green component in the final video, while
still using the CVS version of yuvdenoise? Because that version is
REALLY efficient in removing the noise. I really like the result
(excepted for the green tint).

Nicolas.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
  



-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Greenish tint with yuvdenoise CVS

2006-04-11 Thread Stefan M. Fendt
Stefan M. Fendt schrieb:

This seems to vote for some rounding problem inside the denosier... oh,
no...
  

Yes, OH NO..

seems to be a real bug somewere inside filter_plane_median(); Using this
one with high values (implemented a split-screen-hack to check for
visable chroma-oddities) clearly exhibits a very(!) green tint. This is
so hefty that it can't be just a rounding problem. There must be
something more than that. Still searching it.

Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Greenish tint with yuvdenoise CVS

2006-04-11 Thread Stefan M. Fendt
should be fixed, now... I hope... Nicolas, pls test...

Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Greenish tint with yuvdenoise CVS

2006-04-10 Thread Stefan M. Fendt
Stefan M. Fendt schrieb:

Some additional tests:
  

This becomes weird...

Now, I did use _exactly_ the same commandline as you for the sequence
you sent me... but, no golfball, no green... ?!? Could you pls. mail me
one example frame (TGA,with framenumber) out of 04.yuv processed by
that commandline on your machine? I repeated the test by using my
neutral gray-chart and still... no green... weired...

cu
Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] I tried 9600 kbps for video and 224 kbps for audio

2006-04-09 Thread Stefan M. Fendt
Hi Nicolas,

Here it is:
http://www.europephoto.com/info/montage_video/04.yuv.tgz
  

So, I just played a little with your video-data. This is what I got at last:

http://www.sfendt.de/video/test.m2v

I hope this is the quality you expected to get from HI8 *bg*... And this
is the commandline I used:

cat 04.yuv |\
yuvdeinterlace -d |\
yuvdenoise -m6,24,24 -t12,24,24 -M3,24,24 |\
y4mspatialfilter -L 8,0.5,8,0.5 |\
y4minterlace -i b |\
yuvscaler -O SIZE_352x576 |\
mpeg2enc -F3 -a2 -f8 -Kkvcd -E-5 -R2 --cbr -b9200 -r24 -41 -21 -o test.m2v

I hope this helps...

cu
Stefan

BTW: I used all the CVS variants of the tools... At least for the
deinterlacer and for the denoiser I can't recommend to use the user
release anymore...

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] I tried 9600 kbps for video and 224 kbps for audio

2006-04-09 Thread Stefan M. Fendt
Hi Nicolas,

Here are the things I see:
- you use the CVS yuvdenoise, which I'll compile to see the difference
  

it should be better (and perhaps making yuvmedianfilter obsolete...)

- why do you deinterlace and reinterlace? Can't yuvdenoise and
  y4mspatialfilter work on interlaced material?
  

it's some HQ-hack as your material is really, really noisy... This way
the denoiser reacts a little less aggressive.

- you use really different values than I use for y4mspatialfilter. I'll
  test that
  

this is a little more agressive...

- my goal is to produce a DVD. Is that normal to use the SIZE_352x576
  option for a DVD?
  

Well, it's an allowed size and as the HI8 material hasn't got  a lot
more resolution to deliver it should make it possible to better use the
bits available...

- You use the kvcd matrix. I tried it, but the quality was not really
  good. But on yesterday, I tried the tmpgenc matrix, and that REALLY
  reduced the average bit-rate, without deteriorating the quality.
  

This was more like a bad habbit... *g* feel free to use tmpegs matrix.
It's a matter of taste here...

With the previous command line I got almost only qscale 1.3 to 4 for
your footage...

cu
Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] I tried 9600 kbps for video and 224 kbps for audio

2006-04-08 Thread Stefan M. Fendt
Nicolas MAUFRAIS schrieb:

Stefan, I thank you for all the information, but... how could I use an
horizontal lowpass-filter? I read all the things you wrote, and even
if that's probably right, I don't know how to test it.
  

OK, so here comes what I would try with this material:

Since the horizontal resolution is very close to some reduced DVD
resolution, I would most probably use something like this (slow, but
usualy good quality on noisy sources):

lav2yuv my_dv_files.avi |\
y4mspatialfilter -L 4,x,0,1 -C 4,y,4,y |\
yuvdenoise -m y0,u0,v0 -t y1,u1,v1 -M y2,u2,v2 |\   
yuvscaler -O SIZE_352x576 |\
mpeg2enc -K kvcd -E -10 --cbr -b 5000 -R2 -41 -21 -r24 -o file.m2v

Tune x until you can see some little blurring (for your HI8 source this
should happen arround 0.5), then go upwards a little again. Choose y to
be somewere near 0.3 to 0.5 (you wont notice for HI8 as chroma is bad
anyways, but the mpeg2enc will like that...). For the denoiser start
with y0 and leave all other values zero. Turn up y0 until you can see
the effect (it's too much then...) lower the threshold again by 1 or 2.
Choose 2*y0 for u0 and v0 as a starting point and finetune it the same
way as x,y,y0... Then tune the values for -t exactly the same way
(only that these may be magnitudes higher -- it is *not* a threshold
here but a mixing-value(!)) and if really needed do the same with the
values for -M (you can try the values from -m as a starting point
but most likely they are too high here...)

I hope this helps...

cu
Stefan

BTW: I would never go higher than approx 5Mbps... otherwise it *will*
knock some hardware-players out of buissnes...

PPS: feel free to send me a short sequence (or allow me to download it
somewere) of 30sec to 1min of the jpeg/dv data and I will try that
finetuning for you, if you like... let's see how low we can can that
bitrate... :-

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] I tried 9600 kbps for video and 224 kbps for audio

2006-04-07 Thread Stefan M. Fendt

Hi Nicolas,

Nicolas schrieb:

 I don't apply any filter. I spent 2 evenings trying to find good

settings to denoise the video without any success. Each time the result
was blur. There was far less details on the pictures...
  

hmm,...

you could (do you use the CVS version of the denoiser?) use -M 0,0,0 -m
0,0,0 -t 8,16,16...

Blurring only should be visable when using too high thresholds for the
spatial filters (-M and -m). When appropriatly set you shouldn't be able
to see any blurring even with these. The above example, however, turns
the spatial filters off, completely. The temporal filter, however, can
*not* reduce sharpness (it might, if using thresholds above 24 (which is
a really huge setting!) cause visable ghosts.) So, if you want to
denoise without loosing sharpness by all means use only -t...

BTW: if it is any analoge video tape, you should use horizontal
lowpass-filtering, at least *once* in your chain. Here comes why (you
may not like to hear... Warning, long...):

You say it's a recording of a HI8 tape. These have a bandlimit of 3Mhz
(luminance) applied before recording the video signal on tape. Sampling
theory says you'll be needing 6.000.000 samples/sec to get a fully
reconstructable digital recording of such a signal.  Samples is pixels
for  digital images. Asuming you're recording a PAL signal to such a
tape you have 25 frames (= 2 fields) per second. This makes
6.000.000/25=240.000 pixels per frame. PAL has 625 scanlines per frame,
so you get 240.000/625=384 pixels/scanline. This is further reduced by
the horizontal blank-interval. For PAL it has a time-period of 4,7µs.
The complete scanline has a time-period of approximatly (I ignore vsync
here...) 64µs. So approximatly 7,3% of the complete scanline is lost for
image transmission. This makes 384*(1-0,073)=356 pixels of resolution.
Considering the active lines of a PAL-video (and I don't know a
digital-video-system which stores more than that) to be 576, you will
end up with an image of 356x576 active/usable pixels by maximum. For a
standard (that is luma correctly bandlimited to 5Mhz) PAL-signal you
will end up with an image of 593x576 pixels. Everything you record above
these limits is *noise*... That noise however may mask how bad the HI8
recording really is...

Furthermore the maximum vertical resolution of an interlaced image is
reduced by the Kell-factor to approximatly 2/3*nr_of_lines. This is
reflected in the method any good interlaced TV/video-camera will sample
the image off the CCD. Every halfway sane manufacturer will use
double-scanline-readout to

   1. reduce noise (+3dB SNR)
   2. reduce inter-field-flicker
   3. reduce inter-field jumpyness of scanlines
   4. honour the Kell-factor as otherwise fine detail may not recorded
  at all (if it has the correct, critical velocity)

That is, given this is the CCD:

1. line
2. line
3. line
4. line
5. line
.
.
.

For the first field (bottom field first) scanlines (2+3)/2 and (5+4)/2
and so on are read out, for the second field it's (1+2)/2, (3+4)/2, ...
and so on...
Everyone clearly can see this will reduce resolution before recording
anything. To get that lovely crisp images we all like from (cheap)
video-cameras, boosting of mid to high frequencies is applied, which
makes the image even more worse...

minutes long Hi8 cassette 

I fear that could reduce the video quality.

It's HI8... What quality? ;-) (Sorry, could not resist...)

cu
Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] 2 frames extracted from my noisy video

2006-04-07 Thread Stefan M. Fendt
Hi,

Nicolas schrieb:

Here are 2 frames of my noisy video:
http://www.europephoto.com/info/montage_video/frame.jpg
http://www.europephoto.com/info/montage_video/frame2.jpg
  

I have taken frame.jpg scaled it (cubic) to 356x576 and afterwards up
again to 720x576. There was no loss in horizontal resolution. The only
bad thing the scaling-kernel (GIMP) did, was a slight phase-shift (1/2
pixel) and some ringing-artefacts-removement (which was easy to
identicaly add again with a horizontal highpass-filter -- but this
process does not add spatial resolution, it only enhances what is
there... And you don't want that type of enhancement anyway... So
everything I wrote previously can be savely applied to your images.).

cu
Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] I tried 9600 kbps for video and 224 kbps for audio

2006-04-07 Thread Stefan M. Fendt
Just in case someone might ask/wonder... I did not try to explain, why
we have (601) 720x576 or 720x480 pixels per frame (which mainly is
related to 2,25 MHz and some factor of six...) .. I just wanted to
derive the resolution a HI8-camcorder can have.

cu
Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] black bands with yuvdeinterlace?

2006-03-17 Thread Stefan M. Fendt
Alec Robertson schrieb:

Hi,

I'm using cinelerra, rendering dv video to a yuv4mpeg stream and piping 
through yuvdeinterlace. After this, there are black bands at the top and 
bottom of my movie. Is there any way to avoid this?
  

Ahh, so you are using the CVS-version... :-) ... no, there isn't. This
is because of the algorithm used which can't deinterlace that lines (and
will be changed, as I will change internal processing to a more clever
aproach.
Please wait a few days until this gets fixed in the CVS I am working on
that one currently (as I do for the bug in the denoiser, too...)

Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Pinnacle MovieBox DV

2006-01-01 Thread Stefan M. Fendt
Steven M. Schultz schrieb:

 Not that specific one but Pinnacle products were reported as having
 some issues in the past with A/V sync (they left me with the
 impression of a 'cheap'er unit). Probably fixed by now but while I was
 working with the DV format I stayed with the Canopus products.

I must say Steven is absolutely right here. I tested DataVideos DV Box
and a friend of mine one (I forgot wich one) of the pinnacle boxes...
Both useless because of massive frame-drops and audio/video-sync
problems. I now use an ADVC-110 and all the problems went away...

 You get what you pay for - or put another way Du bekomst was du
 bezahlt hast ;)

Yapp, absolutely correct and testing something other than the ADVC was
causing a lot of trouble and loosing money this way... so it made the
Canopus a little more expensive...

   the conversion unit.  The Canopus ADVC-300 has both a TBC and a
  

Since I have the ADVC-110 I never needed a TBC anymore... :)

   commented (hi Stan! ;)) the Canopus ADVC110 is a very good unit
  

It is... (Steven: I allways thought that I were the one reporting the
quality of the ADVC-110 to you ;-) )

   (replacement for the -100, one nice feature of the -110 is that it is
   bus powered and doesn't need a power-brick).

Yapp, works perfectly without.

   If you're planning on editing then the presence of the 'locked audio'

allways use locked-audio on capturings with the ADVC-110

   I think if you do a search on the mailinglist archives you'll find
   a number of folks that have switched to the Canopus units and been
   very happy with them.
  

:-) I'd like to recommend anything else but I can't anymore...

Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Latest yuvdenoise

2005-12-22 Thread Stefan M. Fendt
Ray Cole schrieb:

 Works :-)

 Not sure if you wanted feedback on results or not, but if so things
 look pretty good to me.

That's fine...

   I've been in the habit of having all the filters off except for the
 temporal filter with yuvdenoise because adding the other filters
 generally caused my bitrate to go up rather than down and it would
 'dull' the image a bit 

this was true for rather noisefree images. It shouldn't be true anymore...

 yuvdenoise has been my favorite filter for some time - I really like
 its results.

8-)

   Anyway with the latest in the repository I ran it on some material
 and I didn't notice it blurring the image.  I did, however, notice a
 little bit of 'blockiness' in a scene that was mostly blue sky
 [...]There were clearly little squares blurred in the middle breaking
 up at the edges [...]

hmm, strange... as the new 3D filter (which is a 2D filter since last
commit -- I should change the usage()...) is not block-based, this
puzzels me a little bit. But as I encountered something simmilar (but in
my case the blocks beeing green :) ), I would like you to:

a) verify that these blocks are not introduced by mpeg2enc (which was it
in my case)

and

b) if they are really introduced by the denoiser send me a ca. 50 frames
y4mstream (please use bzip2...), as well as the used thresholds, so I
can investigate (and possibly remove) that behavior of the denoiser, as
it clearly should not add unwanted blocks...

cu
Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Latest yuvdenoise

2005-12-21 Thread Stefan M. Fendt
Ray Cole schrieb:

 I grabbed the latest yuvdenoise from the repository and noticed it
 core dumps.


Should be fixed...

Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] Latest yuvdenoise

2005-12-20 Thread Stefan M. Fendt
Ray Cole schrieb:

 I grabbed the latest yuvdenoise from the repository and noticed it
 core dumps.

japp, need to fix the memory handling (and some other things...). I hope
I can do so tomorow...

Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


[Mjpeg-users] B ... [WAS: y4mscaler: Upsampling to widescreen]

2005-12-07 Thread Stefan M. Fendt
Michael Hanke schrieb:

Ok. Now that you have said A I would ask that you should also say B: Would 
it be possible to get a copy of your filter for experimenting, ideally with 
adescription of the theory behind it since you said it's non-standard.

OK, here we go...

This is a much simplified and a lot faster variant of that scaler. It
took me some minutes to make it useful and understandable... (I hope)...

void
upscale (uint8_t * dst, uint8_t * src, int w, int h)
{
  // triangulation scaler
  // this scaler works by analysing the correlations between neighboring
pixels
  // it is a rather simple super-resolution-approach but as TV is
lowpassfiltered
  // in front of transmission we can't recover resolution with a
multi-image approach
  // so if upscaling is needed at all, we try to do it visually correct...
  //
  // the results are quite similar to what modern plasma-screens do with
SD-signals

  int x, y;
  int dx, dy;
  int m;
  int a, b, c, d;
  int ae, be, ce, de, me;

  for (y = 0; y = h; y++)
for (x = 0; x = w; x++)
  {
*(dst + (x * 2) + (y * 2) * (w * 2)) = *(src + x + y * w);
  }

  w *= 2;
  h *= 2;

  for (y = 1; y = h; y += 2)
for (x = 1; x = w; x += 2)
  {
// fill in the four neighbor-pixels
a = *(dst + (x - 1) + (y - 1) * w);
b = *(dst + (x + 1) + (y - 1) * w);
c = *(dst + (x - 1) + (y + 1) * w);
d = *(dst + (x + 1) + (y + 1) * w);

// calculate the mean of the neighbors
m = (a + b + c + d) / 4;

// calculate the error for every neighbor-pixel
ae = (m - a) * (m - a);
be = (m - b) * (m - b);
ce = (m - c) * (m - c);
de = (m - d) * (m - d);

// find the maximum error-value
me = ae;
me = (me  be) ? be : me;
me = (me  ce) ? ce : me;
me = (me  de) ? de : me;


// generate mixing coefficients
ae = me - ae;
be = me - be;
ce = me - ce;
de = me - de;
me = ae + be + ce + de;

if (me != 0)
  m = (a * ae + b * be + c * ce + d * de) / me;

*(dst + x + y * w) = m;
  }

  for (y = 0; y = h; y += 2)
for (x = 1; x = w; x += 2)
  {
// fill in the four neighbor-pixels
a = *(dst + (x - 1) + y * w);
b = *(dst + (x + 1) + y * w);
c = *(dst + x + (y - 1) * w);
d = *(dst + x + (y + 1) * w);

// calculate the mean of the neighbors
m = (a + b + c + d) / 4;

// calculate the error for every neighbor-pixel
ae = (m - a) * (m - a);
be = (m - b) * (m - b);
ce = (m - c) * (m - c);
de = (m - d) * (m - d);

// find the maximum error-value
me = ae;
me = (me  be) ? be : me;
me = (me  ce) ? ce : me;
me = (me  de) ? de : me;


// generate mixing coefficients
ae = me - ae;
be = me - be;
ce = me - ce;
de = me - de;
me = ae + be + ce + de;

if (me != 0)
  m = (a * ae + b * be + c * ce + d * de) / me;

*(dst + x + y * w) = m;
  }

  for (y = 1; y = h; y += 2)
for (x = 0; x = w; x += 2)
  {
// fill in the four neighbor-pixels
a = *(dst + (x - 1) + y * w);
b = *(dst + (x + 1) + y * w);
c = *(dst + x + (y - 1) * w);
d = *(dst + x + (y + 1) * w);

// calculate the mean of the neighbors
m = (a + b + c + d) / 4;

// calculate the error for every neighbor-pixel
ae = (m - a) * (m - a);
be = (m - b) * (m - b);
ce = (m - c) * (m - c);
de = (m - d) * (m - d);

// find the maximum error-value
me = ae;
me = (me  be) ? be : me;
me = (me  ce) ? ce : me;
me = (me  de) ? de : me;


// generate mixing coefficients
ae = me - ae;
be = me - be;
ce = me - ce;
de = me - de;
me = ae + be + ce + de;

if (me != 0)
  m = (a * ae + b * be + c * ce + d * de) / me;

*(dst + x + y * w) = m;
  }

  // only very little lowpass-filtering (sometimes looks better
sometimes not...)...
#if 0
  for (y = 0; y = h; y++)
for (x = 0; x = w; x++)
  {
a = *(dst + (x - 1) + (y - 1) * w);
b = *(dst + (x + 1) + (y - 1) * w);
c = *(dst + (x - 1) + (y + 1) * w);
d = *(dst + (x + 1) + (y + 1) * w);

m = (a + b + c + d) / 4;
m += *(dst + x + y * w) * 3;
m /= 4;

*(dst + x + y * w) = m;
  }
#endif
}

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mscaler: Upsampling to widescreen

2005-12-05 Thread Stefan M. Fendt
Steven M. Schultz schrieb:

 I do NOT think it's a good idea. Upscaling ~20-30% (depending if you're

in a NTSC or PAL area) degrades the quality so much I couldn't watch 
it (yes - I've done it and didn't like the results ;)).

  

Well, I think this heavily depends on the used scaler (and on the one
watching the result :)... I know an upscaling method which is
(extremely!) slow but yields to really good (my opinion -- at least)
results for 2x upscaling... It is not noticable most of the time. I have
invented that because I thought I would need it for the deinterlacer
(but I do not...)... it does not fit a LP-Surface (cubic or sinc or...)
to the data but image-structures, so it really adds resolution which is
belivable (but not neccesarily realy...)...

If downscaled to an effective upscaling of 50% it gives a nice
antialias-effect, too :) Not sure if I will release that...

Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mscaler: Upsampling to widescreen

2005-12-05 Thread Stefan M. Fendt

dread... I missed that one...

Steven M. Schultz schrieb:

   The data is already 'broadcast legal' (well, it _should_ be if the
  

I *never* have seen a TV-Station (at least here in PAL-Land...)
transmitting a fully broadcast legal signal. Nearly everything I know
is at least transmitted with a too high vertical(!) resolution (stations
on the other hand tend to reduce horizontal resolution too much,
however...), leading to flicker and chroma-artefacts. PAL says the
vertical resolution may not exceed 2/3 of the maximum resolution. This
is badly needed because TV is interlaced. If you do otherwise (you could
do so, as the lines technicaly are independend from each other...) you
will at least see strange flickery and up'n down jumping lines/images...
And this is what I see nearly in any broadcasted signal ...

cu
Stefan

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/[EMAIL PROTECTED]
ICQ: 131490319



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


[Mjpeg-users] DV avi in NTSC

2005-10-17 Thread Stefan M. Fendt
Hi,

does anyone have a NTSC-DV (interlaced) snipplet (something arround
200-400 frames) for me to test the new deinterlacer against it?

cu
Stefan


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] DV avi in NTSC

2005-10-17 Thread Stefan M. Fendt
Joe Friedrichsen schrieb:

 I've got some captured on my NTSC DV camera. If you want it, I'll send
 it to you. Tell me what information you'd like to know.

Any NTSC-DV-file with moving objects in it will be fine. It's just to
test the deinterlacers response to NTSC-chrominance (411) data. I don't
expect it to fail, but who knows. I only have some PAL-DV material at
hand...

Stefan


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users