notes

= D3D recording =

Taksi seems to hook the Present methods...
  maybe I can borrow some of their code?

There is also a straight "get the D3D front buffer" method...which might not work with aero enabled, apparently?


= =

http://ffmpeg.org/pipermail/ffmpeg-user/2012-January/004147.html discusses fast capture codecs

= encoder 4 =

release build no help, I don't think
removing IAMStreamConfig no help


= broadcasting =


ffmpeg -y -loglevel warning -f dshow -i video="screen-capture-recorder" -vf crop=690:388:136:0 -r 30 -s 962x388 -threads 2 -vcodec libx264 -vpre baseline -vpre my_ffpreset -f flv rtmp://<amazon_wowza_server>/live/myStream.sdp

Here is my ffmpeg preset (libx264-my_ffpreset.ffpreset):
coder=1
flags2=+wpred+dct8x8
level=31
maxrate=1200000
bufsize=200000
wpredp=0
g=60
refs=1
subq=3
trellis=0
bf=0
rc_lookahead=0

I use a web-page with jwplayer to display the video at several sites.
Amazon wowza server doing the copying of 1 input video stream to several
output video streams.

I have also tweaked the Amazon wowza server a little to get little delay/
latency for streaming the video.

there's also a VLC log from somewhere...we really need some helper/GUI for this this is nuts...
also is ffmpeg better at "capturing for ps3ms" than VLC? broadcasting/streaming?

= tearing =

fix tearing in VLC windowed: http://forum.videolan.org/viewtopic.php?f=14&t=60736&start=0 LOL

http://www.mail-archive.com/realbasic-nug@lists.realsoftware.com/msg27760.html saw it
http://www.tomshardware.com/forum/131420-33-vertical-sync-windows “graphics acceleration slider”
take out the mouse snapshot?
gdiflush help?
WindowFromDC cause it/getDC?

http://community.justin.tv/forums/archive/index.php/t-10128.html another instance
 http://nl.justin.tv/alphamalet/b/299341848 (profanity below though)
   those may not actually be directly related, as possibly they're just encountering blips in the capture card.

CAPTUREBLT apparently helps? or just one?

disable the batch limit maybe?

see also http://betterlogic.com/roger/2012/05/using-bitblt-for-screen-capture-causes-tearing

CAPTUREBLT on windows 7 (sans aero) doesn't seem to slow things down a bit.
  also on XP, seems faster even [?]
  even with VLC playing...hmm...
  
  can I reproduce it causing "extra" tearing?
  
= with adjust timestamp etc.=

Seems to *need* --live-caching=3000

http://forum.videolan.org/viewtopic.php?f=4&t=99906 related

12 resets in 40K frames.


= latest way, cool recatch =

avcodec warning: almost fed libavcodec with two frames with the same PTS (697016627077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016660411)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016693744)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016727077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016760411)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016793744)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016827077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016860411)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697016893744)
 frames with the same PTS (697019027077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019060411)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019093744)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019127077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019160411)
access_output_udp debug: packet has been sent too late (433107180)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019193744)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019227077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019260411)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019293744)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019327077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019360411)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019393744)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019427077)
avcodec warning: almost fed libavcodec with two frames with the same PTS (697019460411)
stream_out_transcode debug: drift is too high, resetting master sync
access_output_udp debug: packet has been sent too late (436105288)


@13000


== after 2000 frames ==
28.7 old "bad way" 
29.2 new /1
29.4 with "let it try and catch up"

/10:

[75 fps]

avcodec warning: almost fed libavcodec with two frames with the same PTS (695109797791)
main warning: late buffer for mux input (59001)
avcodec warning: almost fed libavcodec with two frames with the same PTS (695109831124)
main warning: late buffer for mux input (48233)
avcodec warning: almost fed libavcodec with two frames with the same PTS (695109864457)
main warning: late buffer for mux input (30142)
avcodec warning: almost fed libavcodec with two frames with the same PTS (695109897791)
main warning: late buffer for mux input (17535)
main warning: late buffer for mux input (11623)
main warning: late buffer for mux input (85)
avcodec warning: almost fed libavcodec with two frames with the same PTS (695109997791)
main warning: late buffer for mux input (20703)
main warning: late buffer for mux input (8251)
main warning: late buffer for mux input (11175)
main warning: late buffer for mux input (13749)
main warning: late buffer for mux input (21396)
main warning: late buffer for mux input (21325)
avcodec warning: almost fed libavcodec with two frames with the same PTS (695111029206)
main warning: late buffer for mux input (59648)
avcodec warning: almost fed libavcodec with two frames with the same PTS (695111062539)
main warning: late buffer for mux input (68080)

/1:

3000 bad messages
3800 reset
4200 bad
4730 reset
5000 bad

+ 1:

117 fps
unresponsive VLC.

= FMLE =

MEDIASUBTYPE_YUY2 did not help

changing the output size scarily did.

= skype friendlier =

UScreenCapture did not work with skype.
Mine did, no preview.

ffmpeg did not show the lower limit [right?] TODO

vscrcap did work, with preview of just that window [weird]
  then grabbed a little left, [also weird, unrelatedly]
  couldn't go low enough. ok weird.

// VLC does seem to reject I420, WFMLE reject's RGB
  
= getdibits speed =


	/*
	  without aero:
      bitblt took 2.10171999999999980000 ms (with aero:  53.8527600000ms)
      getdibits took 2.435400ms
      memcpy took 2.01952000000000000000 # hmm...

	*/

	/*
	int size = pHeader->bmiHeader.biSizeImage; // bytes
	BYTE *local = (BYTE *) malloc(size);
	start = StartCounter();	
	memcpy(local, pData, size);

	
	__int64 now = StartCounter(); 
	LocalOutput("memcpy took %.020Lf ", GetCounterSinceStartMillis(start)); // takes 1.1 versus 3.8ms for getdibits, but that's with 80fps compared to max 251...so may not be the bottleneck
	free(local);*/


= speed 3 =

did see a lot of 'skipping too old of pictures'

avcodec warning: almost fed libavcodec with a frame in the past (current: 478212364815, last: 956171418235)
stream_out_transcode debug: late picture skipped (57085)
stream_out_transcode debug: late picture skipped (62135)
stream_out_transcode debug: late picture skipped (75515)
stream_out_transcode debug: late picture skipped (71363)
stream_out_transcode debug: late picture skipped (75041)
stream_out_transcode debug: late picture skipped (69066)
stream_out_transcode debug: late picture skipped (55001)
stream_out_transcode debug: late picture skipped (66319)
stream_out_transcode debug: late picture skipped (70228)
stream_out_transcode debug: late picture skipped (83418)
stream_out_transcode debug: late picture skipped (25602)
stream_out_transcode debug: late picture skipped (12861)
stream_out_transcode debug: drift is too high, resetting master sync


setting it to "frame number" seemingly resulted in...buffer good buffer good when watching or streaming. So it's probably not streaming's fault...

= speed 2 =

with aero:

"can't seem to get debug above 19 fps or so, even when set to 60/ or set to not wait at all"
  goes down to almost exactly 15 fps after awhile. Man that seems messed up.
  
"benchmarker with aero" 
  no movement:
   avg. 52.8 fps
   min. 19.1 fps
   max: 70.8 fps
 yes movement occurring:
    avg: 30.8
    max: 64.1
    min: 12.9

"benchmarker without aero"

interestingly 'capture from windows 640x480' average goes from 800 to 560 (400?) when there is movement.
  
my prog without aero:
 28.4, seems to work fine, I limited it to 30 fps
  
= speed =

GetDc versus 	//hScrDc = CreateDC(TEXT("DISPLAY"), NULL, NULL, NULL); // SLOW for aero desktop ...

"seem" same speed 170 164 maybe for GetDC but...possibly an honest wash.
(single monitor, non aero)

with aero:

GetDC: 29.87 28.87

display:

34
22 24 28.58 25.78


seems like a wash, but barely with prefer getDC.
Probably a statistical wash.

= programmuh =

http://www.windows-api.com/microsoft/Win32-DirectX-Video/32647581/wmv-9-dmo-encoderdecoder-usage-with-live-stream.aspx "don't set stop time" for live source?

with a window way outside the visible range, sometimes the mouse still appears in the black. weird.

== broadcast/record ==

perl + mp3 only works well...

perl + screen cast 700x600: -vcodec mpeg4

  dropping buffers like crazy, perl 0% cpu
  dwm, ffmpeg high cpu 50%'ish... (so one core)
  only top line is good, rest is crap.
    huh?
  
  
  ffmpeg -y -f dshow -i video=screen-capture-recorder -vcodec mpeg4  yo.avi
    outputs *zero* packets? huh? no what? seriously.. what?
    
  audio still bad with anything but huffy
    x264 default: 1MB
    qtrle 13MB, no video LOL.
    huffy 115MB
    TODO fix audio bad here LOL.
  
== camtwist windows ==

Yes, you would have to do that since image dimensions are negotiated when the graph is built. There is something called dynamic reconnection that might be of interest to you (msdn.microsoft.com/en-us/library/dd388737(v=vs.85).aspx). It allows for re-negotiation without rebuilding, but the filters in the graph need to support it AFAIR. – Ralf Jul 1 at 4:39
Maybe just AVS and re-connect?
  can I arbitrarily grab from any Webcam this way? easily?

this could be a sweet way to present though :P
  but a bit forky...

http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html
  maybe an ffmpeg source can accept dshow input? It should be able to...
  

== citrix ==

 Win32::Screenshot::BitmapMaker.desktop_window;
irb(main):004:0* 3
=> 3
irb(main):005:0> hwnd
=> 65552
<ure_area(hwnd, 0,0,2000,2000) {|w,h, bmp| File.binwrite('dw.bmp', bmp); 33}

resulted in one that just included the desktop (with transparent edges), however, grabbing a specific window hwnd works a champ...hmm...
  no cheating this one, the easiest way is to...turn on aero and just capture the output of windows, that's it...
  no need to move them off-screen even, for now.
  
  so basically each connection needs some meta...
  java headless with jvlc... [huffyuv?]
  capture clicks, send them through (relay)
  position specified "can be relative to some root parent window"
    include the title bar.
    positions can be set to change.
    size can change...can ffmpeg send through changing sized frames? huh?
      no size changes for now
        miniaturify?
        have local ability to resize that causes resync somehow?
    maybe a "VNC, just track this one window, k?"
      
  
  it needs a "has" changed in the background...
  
  For Vista and newer, GetPixel() might be the right way, but I'm still on XP.
http://www.gamedev.net/topic/327506-forcing-a-hidden-window-to-paint-to-an-arbitrary-dc WM_PAINT
http://stackoverflow.com/questions/242570/copying-content-from-a-hidden-or-clipped-window-in-xp

PrintWindow might still suck...: http://social.msdn.microsoft.com/forums/en-US/winforms/thread/d9a188ae-3503-4c31-aa00-6e7195b5384a (also has a good description of it...)

a fake WDDM looks hard: http://www.osronline.com/showthread.cfm?link=209292

zoneos seems to not have an open source virtual display driver <sniff>.

http://www.codeproject.com/KB/system/driverdev6asp.aspx seems to have an OSS virtual display driver...hmm...
  it's XPDM.
  
maybe a sum of aero-less BitBlt on the main window, plus a call to PrintWindow?

I don't care about the WM_PAINT extra call annoyance/bug: http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/0a86bf38-8c28-4b07-a8ab-6c8c97932477

  metavnc looks good but...includes all windows? multi-server-client maybe?
  
"temporary servers" for menu popups, I guess is the only way...or maybe...can just draw them over the top and that's good enough?
  so I guess...my real question is...how does using PrintWindow work, does it include sub-windows and menu popups et al?
    TODO does it work with visual studio, +- popups?
    if so then I might be good...
      that way makes more sense, anyway
    else XPDM?

or possibly hook DX with aero...nah...

I think I can just use parent processes...

how would this work with linux?

homebrew with ffmpeg or re-factory TightVNC.

or maybe just bring "your desired" fella to the foreground, take his picture, then revert...hmm...that could cause some clicking ambiguity though...

security can just use windows security [?]
  authenticate, then runas /abc [yes!]

simple first pass: edit guts of VNCServer, it can track an HWND.
  it can resize.
  child windows get repositioned to be on top of that fella :P
    child windows are bitblt'ed over the top of the parent...hmm...
      possibly z-order eventually :P
  non mirror mode so that diffs work at all...
    a canvas...hmm...that's always behind...then you could follow z-order...
      a popup menus you could still display, via...PrintWindow and bitblt.

without aero, it has any overlaying window, and cuts off right at the desktop edge.
with aero, hwnd of visual studio just reveals tree

firefox looks great off scren

can't tell with aero+captureblt+specific hwnd, it probably doesn't work so well though, only with desktop hwnd.

so I guess maybe paintwindow is my only hope for visual c off screen?

trap mouse?
own windowing system? hmm...that actually might could work...just window over their whole HWND size, in case they overlap the default too :P

== 16 vs 32 bits ==

both going to 24bit:

32->24:
bitblt took 2.42955999999999990000 ms
getdibits took 2.576960ms
end total frames 26 12.56808000000000000000ms, total since beginning of time 10.288880 fps (theoretical max fps 79.566648)

16->24:
bitblt took 1.26440000000000000000 ms
getdibits took 3.574480ms
end total frames 17 11.00020000000000000000ms, total since beginning of time 10.480888 fps (theoretical max fps 90.907438)

16->32:
bitblt took 1.31244000000000010000 ms
getdibits took 2.995200ms
end total frames 21 10.52176000000000000000ms, total since beginning of time 10.437376 fps (theoretical max fps 95.041134) 

32->32
bitblt took 2.25976000000000000000 ms
getdibits took 2.714160ms
end total frames 23 12.05036000000000000000ms, total since beginning of time 10.379061 fps (theoretical max fps 82.985073) # barely faster than ->32 hmm...but about the same, and possibly better downstream...

# so unfortunately -> 32 bit is a tidge faster, but does it result in...slower encoding downstream, or...large final output files?
  TODO check :P

== broadcast  ==
 streaming anything to TV: wired might work better... :P

I just ran a quick test: a 90 second 720x480 23.976 fps MPEG video compressed in 7 seconds with Divx 
at its fastest settings. Xvid took 17 seconds. HuffYUV took 9 seconds. 
PicVideo MJPEG (v 2.0) 7 seconds. This was on a Q6600 CPU.

maybe I should bounty camstudio codec compressor too?

"Hence DNXHD, libx264, MPEG 1/2, libxvid are good choices for multithreading." hmm...

x264 speeds:
All the encoding settings were tested on a 720x448 @30000/1001 fps video sample, the target bitrate was 900kbps, and the machine was an AMD-64 3400+ at 2400 MHz in 64 bits mode. Each encoding setting features the measured encoding speed (in frames per second) and the PSNR loss (in dB) compared to the "very high quality" setting. Please understand that depending on your source, your machine type and development advancements, you may get very different results.

Description Encoding options	speed (in fps)	Relative PSNR loss (in dB)
Very high quality	subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b	6fps	0dB
High quality	subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b	13fps	-0.89dB
Fast	subq=4:bframes=2:b_pyramid:weight_b	17fps	-1.48dB

maybe should bounty an ffmpeg fraps encoder

The most balanced and flexible codec is FFV1: relatively good speed and high compression for various presets."

MPEG-2 and Windows Media are great for real time recording even on slow computers.

1) wmv9 cant beat even xvid clearly on 1cd backup bitrates, so it [xvid] has no chance against a good h.264 implementation, like x264 or ateme
  wmv9 has poorer quality I guess...might be fast still, but...hmm...

x264 plugin for video over shoutcast also shows that h264 is better in streaming quality

http://forum.videolan.org/viewtopic.php?f=4&t=60947
  some guy streaming something something 

there may be no mencoder rtsp [?]

vp8/webm?

shoutcast, icecast, or streamcast or darwin?
  red5 looks strong.

sopcast
  is out

also should I do a TODO for "enable uPnP locally so you can give out real IP addresses?" for local streaming?


http live streaming looks quite suh-weet...not sure how to actually upload the thing in realtime, though...scp I guess is the only way...

ffmpeg can stream to rtp (and uh guess to ffserver to...)
 If what you want is send the file little by little, so someone can connect to the stream after you start the stream, you can try this command
  ffmpeg -i conference.mp3 -acodec copy -f rtp rtp://239.8.8.8:5000  -re
  With -re you read the input at native frame rate, so you will be sending it as long as the file duration.

gstreamer rtsp + DSS/linux got good reviews...hmm...https://www.ridgerun.com/developer/wiki/index.php/Using_GStreamer_with_Darwin_Streaming_Server_as_RTSP_server

make it like ustream?  is ustream free? 

quicktime broadcaster supports isight, DV video, normal audio mic [!], camtwist which has a desktop capture...hmm... 

  suggested ustream live codec/width: http://www.livestream.com/userguide/?title=Stream_With_Quicktime_Broadcaster#Suggested_Video_Settins

This is non-trivial...
you might be able to come up with some freaky way of doing things, like this gets video, that audio, this combines the two into rtsp [yikes].

Also note that it seems from QT broadcaster that you just do keyframes every so often and...umm...lose realtime aspect
but what are you going to do?

encoding should probably "best" be done on the capture recorder side...

camtwist would work for desktop qtcapture device...not open source though :P but free, and probably rocks! sweet!
  don't know how I would distribute for mac...or if it would even be helpful LOL.

== propaganda ==


  mehs:
  screenshot capture 800K meh
  screenshot screen capture 800K meh
  capture software 450K meh
  screen grab 450K meh
  free screen 1.2M meh
  capture screenshots 1.6M meh
  capture software 450K meh

  windows screen capture 110,000
  window screen capture 135,000
  screen capture directshow 590
  screen capture vlc 5,400
  screen capture device 1,300
  desktop capture 40K
  desktop stream 18K
  record desktop 90K

  free screen capture 135K
  record screen capture 135K
  screencast 135K
  capture streaming video 135K meh
  windows screen capture 110K meh too low
  screen capturing 110K
  record streaming video 110K
  screen capture record 135K
  software/program 135K
  
  video screen capture 160K
  free recording software 165K # software is just plain too tacky...
  record screen 300K
  screen recorder 450K
  screen capture 550K
  screen recording 380K
  windows capture 240K
  camstudio 240K  
  
  recorder screen 450K
  record screen 300K
  screen capture recorder 246K
  
  capture screen 1.8M
  on screen capture 1.8M

  sum:
  
  on-screen-capture-recorder-to-video-windows-free
  
    was screen capture recorder program
  
notes:
 1024x1024:
   15% one cpu used by the capture utility (0.013ms per capture)
   good for now I guess (no transparency visible...)
   12 fps <sigh>

VBLE in my anime encoding .... the normal size for my huffyuv avi for the show was 5-6 gigs and with vble i got 4.4 gig
  appears abandoned

1680x1050 was 20 MB/s huffyuv

utvideo is the "best" lossless they say...http://www.videohelp.com/tools/Ut_Video_Codec_Suite
  or is that just for playback though?
  
MSU lossless codec is abandoned and not developed nor supported anymore. It was never even close to realtime
  except it appears to be hmm...
Xvid with search options at 0, no B frames, and constant quality 1 or 2 is very fast, even with one core. You can specify it use just