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
Here a very small highpass-filtered cutout... Eventually it helps our
encoder-/decoder-specialists on the list?
Stefan
<>
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-
This SF.net email is spon
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
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 harmoni
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 deg
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
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 oft
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
-
T
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
Am Montag, den 23.07.2007, 10:49 -0400 schrieb sean:
> Ah. No OSX here.
nor here...
> ffmpeg seems the only alternative on linux. I'll go try to
> find out how to do it with ffmpeg. Without docs, it's not
> always easy. And they're such a friendly bunch :(
Yeah, but despite that it is quite g
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
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,
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
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 BT
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. deinterla
Hi,
just a nice deinterlacing trick I found out a few days ago. It only
works, if some criterias concerning the recorded material are met
(otherwise it will look very ugly) and has more motion-blurr than a real
film-camera, but I like it's appearance and it is very fast to get:
1. set your camcor
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 a
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 ch
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 we
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"
Some additional tests:
1. using Nicolas material "04.yuv" with -m24,24,24 -t24,24,24
-M24,24,24. Result: OK, no tint (at least no other than that
already in the frames - can see this on the "white" window
decoration...).
2. using Nicolas material "04.yuv" with -m6,24,24 -t1
Hi people,
as the question came up, I did some tests with the current CVS version
of the denoiser to check if it might cause green offsets (like it did a
long time ago)... Here is what I did (if you want to check yourself, no
problem, I can send you the gray.ppm I used...)
1. Test:
feed
Nicolas schrieb:
>The noise reduction seems to be more effective than in the last version.
>However I observe a STRONG greenish tint on my encoded video...
>
>
hmm, thats strange... I can't say that I noticed this with the new
denoiser. The old denoiser once suffered from a rounding problem whic
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 materia
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
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
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: callt
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 horizont
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
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
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.
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 ca
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 sp
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
---
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 simplifi
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 transmitte
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
Joe Friedrichsen schrieb:
>>
>> 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...
>>
> Ok. My file will probably work f
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'
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, download
40 matches
Mail list logo
