subject:"Re\: \[Mjpeg\-users\] yuvdenoise"

Re: [Mjpeg-users] yuvdenoise

2010-11-14 Thread Herve Flores


Le 14 nov. 2010 à 21:04, E Chalaron a écrit :

 Hello Bernhard
 Thanks for the reply.
 That is a normal behaviour both programms use only one CPU/Core and are 
 not multithreaded.
 
 
 Ok so if I understand properly does it mean that y4munsharp will get 1
 core and the yuvdenoise the oher one ? or both on 1 core that will
 alternate from time to time ?
 If so is there a chance that both (and maybe the other mjpegtools) can
 be multithreaded ?

(hello, sorry I'm not english native)

If I well readed your mail: you only have 2 core and you want some speedup
but you have 4 processes : decoder, yuvdenoise, y4munsharp, ffmpeg
The good hardware for this process will be to have 4 core (one for each process)

Theorically, if you had more core/proc (than 4), you could add some threads 
more to the most consumming processes parts (aka yuvdenoise and ffmpeg enc) and 
to obtain some speed / optimizations
But you don't have ;-)

The most efficient way for me (empiric way) is not to distribute processes 
between so few cores, but to limit threads to the exact number of your 
processors. 
(was my 2 cents ;))

bye

Hervé
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdenoise

2010-11-14 Thread Mark Heath


The simple solution to worrying about the need to optimise the code  
for your cpu is to look at the output from top.
(I am actually interested in seeing the %CPU each of your processes  
take up.)

Are both your CPUs fully loaded?

Yes - multi threading is not needed but you could always optimise the  
heaviest hitting process to increase FPS. And then the next heaviest  
etc etc.

No - The heaviest hitting process is causing the bottle neck.  Look at  
optimising this process to better utilise your machine, multithreading  
may help.   There is no point optimising the low %CPU processes if  
this is the case.

Mark

On 14/11/2010, at 11:15 AM, E Chalaron wrote:

 Hello all
 Just a quick question : using mjpegtools through ffmpeg piping.
 are they (or not) multi threaded ?

 ffmpeg -threads 2 -y -i - -f yuv4mpegpipe - | \
 yuvdenoise -t 2,8,8 -m 2,8,8 |
 y4munsharp |\
 ffmpeg -y -threads 2 -i - -b 22k -vcodec dnxhd -threads 2 $fichier

 On (for say) a dual core (AMD or Intel) the gkrellm histogram shows a
 smaller activity on 1 core then alternates to the other core from time
 to time.


 Thanks a lot
 Edouard

 --
 Centralized Desktop Delivery: Dell and VMware Reference Architecture
 Simplifying enterprise desktop deployment and management using
 Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
 client virtualization framework. Read more!
 http://p.sf.net/sfu/dell-eql-dev2dev
 ___
 Mjpeg-users mailing list
 Mjpeg-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mjpeg-users


--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdenoise

2010-11-14 Thread E Chalaron

Thanks Mark

 No - The heaviest hitting process is causing the bottle neck.  Look at  
 optimising this process to better utilise your machine, multithreading  
 may help.   There is no point optimising the low %CPU processes if  
 this is the case.
   

This is the case.
It seems to be yuvdenoise but I may be wrong.
As for optimising/recoding : in another life, I have not a clue about that.
Cheers
E

--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdenoise

2010-11-14 Thread E Chalaron



 Are both your CPU cores loaded?
   
Well one is 20 % the other  65 % (or so) and then swap from time to time.

cheers
E

--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdenoise Was: Video is green if i use yuvdeinterlace

2006-08-11 Thread Michael Hanke

Am Mittwoch, 12. Juli 2006 10:18 schrieb stefan:
 stefan schrieb:
  Steven M. Schultz schrieb:

  On Wed, 5 Jul 2006, Michael Hanke wrote:
  
  Hmmm... Please excuse my dumb question. Here are you puzzling me a 
little bit.
[snip]

Hi Steven and Stefan,

being back from my vacations I found your long explanations. Thanks a lot for 
them!

Michael

-
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=lnkkid=120709bid=263057dat=121642
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] yuvdenoise Was: Video is green if i use yuvdeinterlace

2006-07-12 Thread stefan

stefan schrieb:
 Steven M. Schultz schrieb:
   
 On Wed, 5 Jul 2006, Michael Hanke wrote:
 
 Hmmm... Please excuse my dumb question. Here are you puzzling me a little 
 bit.
 
   
 It is not dumb at all!  You raise some very interesting points that
 people should be aware of.
   
 
 Yes, indeed.
   
 My model of thinking with respect to interlacing/deinterlacing is as 
 follows:
 - If the material is tv life (say a football match with very fast motion) 
 then
 I think that is is a good idea to let the material interlaced because of 
 the 
 kammeffekt (Sorry, I don't know the correct english word).
 
   
 Well, I was quite satisfied with such an answer for a long time, too,
 but nowadays, I'm not.

 1. Deinterlacing has nothing to do with destroying temporal resolution.
 yuvdeinterlace has (as any other good deinterlacer, I know) the option
 to deliver 50 frames interpolated from 50 fields. As it does *not* alter
 the original scanlines in this case, the quality is higher than what any
 other, freely available deinterlaciner does do in this case. This is OK,
 even for fast moving sport-events. You get 50 frames out of 50 fields.
 Subjective Quality in this case is a lot *better* than before. You can
 use this for nice slow-motion-effects, too...

 2. Most people can not distinguish temporaly decimated material from
 50(60) to 25(30) fps, if it is progressive. Yes, if it is interlaced,
 they can. But this is because of the *defects* of interlaced images.
 Yes, I agree that 50 fps progressive material would even be a little
 better than 25 fps progressive material, but this is somewhat like the
 discussion if we really need 24 Bit 96 kHz audio (which we clearly do
 *not* really need... as we are no bats) to get a more analog listening
 expirience. The physiological limit of visual temporal resolution which
 leads to the impression of fluent motion is about 12-15 fps depending on
 the individual. 25 fps is so much above this that (for most people) we
 can forget about 50 fps. 50 fields/s just remains an excuse for 1920s
 technology in this context.

   
 temporal resolution is the appropriate phrase.  And 60 (or 50)
 fields/sec will give better motion than 25 (30) frames/sec. 
   
 
 Correct.
   
 Of course 60 (or 50 for Europe) _frame_/second progressive would
 be fantastic for sporting (high action) events - and in the US some
 stations do indeed broadcast 1280x720p HDTV at 60 frames/sec.
   
 
 I do agree, too.

   
 direction. The critical thing happens if I use my Canopus to digitize to dv 
 which has 420 subsampling. If I would deinterlace in that case, the 
 vertical 
 chroma resolution becomes wrong. Am I wrong here?
 
   
  You are CORRECT.  Deinterlacing 4:2:0 is TRICKY and complicated by
  the fact there are 3 variants of 4:2:0
   
 
 No, not completely. For 2 of that 3 variants the result will be correct.
 The 3rd variant is caused by a bug in the kernel-implementation of
 interlaced 4:2:0 with the BTTV-chipsets. The 4:2:0 subsampling of the
 canopus is correct and does not cause problems. The BTTV-driver (the
 chipset can do it correctly...) is wrong here. This is known for ages,
 now. But as it seems that no-one notices it...

   
 See 
  http://www.mir.com/DMG/chroma.html

 for a good explanation of the 420 layouts.
   
 
 This does not refer to the problem he discribes. This does refer to the
 different spatial positions of the chroma-samples relative to the
 luminance-samples-position. The relative spatial position of
 chrominace-samples is irrelevant to a deinterlacer. The relative
 *temporal* position however is not (and this gets severely damaged with
 a BTTV in 4:2:0 mode...).
   
 BTW. Sometimes I have the feeling that the fields are shifted by one frame 
 in 
 the dv capturing. Can this happen?
 
   
 Only if it's a VHS-deck, you record from. Signal quality is bad then.
 This is true for the sync impulses, too. In any other cases I would
 agree with Steven and say no.

   
 often used commercial VHS tape for my archive.
   
 I hope it has more than 240 lines of horizontal resolution...

   
  It had an unusual high noise 
 
   
 does not surprise me...
   
 level. Playing around with the different denoiser settings my test audience 
 had a very strange view: The best impression made the noisy tape because of 
 its sharpness! When using yuvdenoise (without any tuning) the picture was 
 considered blurred, unsharp, unviewable
 
   
 Hmm, do you use the current CVS version? I guess, not, as the current
 CVS version is preset to not filter at all. The old version had some
 default values set, mainly to let people see the filtering happen and
 then finetune it to their needs, but this quickly came out as a bad
 idea: People allways tried to use the default-settings to filter
 everything with the result of blurred, flat images... So I set all
 defaults to zero. The user is forced to choose values

Re: [Mjpeg-users] yuvdenoise Was: Video is green if i use yuvdeinterlace

2006-07-10 Thread Steven M. Schultz

On Wed, 5 Jul 2006, Michael Hanke wrote:

Hmmm... Please excuse my dumb question. Here are you puzzling me a little bit.

It is not dumb at all! You raise some very interesting points that
people should be aware of.

My model of thinking with respect to interlacing/deinterlacing is as follows:
- If the material is tv life (say a football match with very fast motion) then
I think that is is a good idea to let the material interlaced because of the
kammeffekt (Sorry, I don't know the correct english word).

temporal resolution is the appropriate phrase. And 60 (or 50)
fields/sec will give better motion than 25 (30) frames/sec.

Of course 60 (or 50 for Europe) _frame_/second progressive would
be fantastic for sporting (high action) events - and in the US some
stations do indeed broadcast 1280x720p HDTV at 60 frames/sec.

- If the source is a movie, then it depends. If I have recorded with lavrec
from my bt787, I have 422 subsampling. So there is no loss in the vertical

Is that the same as a Bt878? I knew the chipset was capable of
4:2:2 but I have not heard of anyone actually using 4:2:2. That is
probably because at some point there needs to be a quality
4:2:2 - 4:2:0 conversion done and that is not trivial to do properly.

direction. The critical thing happens if I use my Canopus to digitize to dv
which has 420 subsampling. If I would deinterlace in that case, the vertical
chroma resolution becomes wrong. Am I wrong here?

You are CORRECT. Deinterlacing 4:2:0 is TRICKY and complicated by
the fact there are 3 variants of 4:2:0

See

http://www.mir.com/DMG/chroma.html

for a good explanation of the 420 layouts.

BTW. Sometimes I have the feeling that the fields are shifted by one frame in
the dv capturing. Can this happen?

I would say no.

BUT DV is bottom field first while other capture
cards are top field first (TFF). I do not know if the the field order
is TFF for the Bt878 but it could be. For MJPEG cards (DC30, etc)
the field order is TFF. For AJA equipment (www.aja.com) everything
is bottom field first.

I am away from the references at the moment BUT I do remember that
DV is defined to be digitized 1 line offset/different from
standard video. For NTSC (525 line video system) the active area
being digitized for DV does NOT start at the same line as
SD (8bit uncompressed 4:2:2 720x486 video. It's a long
story - recommended reading is Charles Poynton's book Digital
Video and HDTV Algorithms and Interfaces:

http://www.amazon.com/gp/product/1558607927/sr=8-1/qid=1152590390/ref=pd_bbs_1/103-9617851-7557445?ie=UTF8

often used commercial VHS tape for my archive. It had an unusual high noise
level. Playing around with the different denoiser settings my test audience
had a very strange view: The best impression made the noisy tape because of
its sharpness! When using yuvdenoise (without any tuning) the picture was
considered blurred, unsharp, unviewable

If I read that correctly you're saying that the NOT-denoised video
was preferred to the 'denoised' version.

Correct?

If so then I have come to the same conclusion. In many cases I will
omit the *denoise processing _or_ using more conservative settings
(with yuvdenoise that means omit/not-use -g, use -t 2,6,6 instead of
-t 4,8,8).

But then I pre-condition the data with the plugins/filters available
with (or added to) FinalCutPro ;)

This seems to be a psychological question: Better noisy than unsharp.

It depends on the person of course. But yes, excessive denoising
seems to blur / soften the image too much.

Do you have an idea about a good compromise? It should allow for low bit rate
encoding, too.

Yes. It is, as you have mentioned, often preferable to not denoise
the data. But that means using many bits to encode the noise - which
means fewer bits for the image.

The solution is to either 1) use higher capacity media (dual layer)
or 2) use half D1 (that is a misnomer but the term has become common
usage) frame size - for PAL that's 352x576 (for NTSC it is
352x480) and a high bitrate.

Believe it or not you probably will NOT notice the difference,
ESPECIALLY if you're using a (noisy/old) VHS tape! VHS doesn't have
700+ lines of resolution anyhow - rarely gets much over 240 or so
(with a good tape, good deck, etc). So 352xN is a good choice
for encoding (noisy) VHS tapes.

As it happens 352xN is also known as CVD (or China Video Disc)
and 'y4mscaler' has a preset for CVD. -O preset=CVD and y4mscaler
will do the right thing when

47 matches

Mail list logo