main hall
==========
1.a/v receiver
2.lcd tv
3.dvd player
4.pc
5.netgear wg ap client mode
6.cable tv tuner
7.cable tv splitter/booster
8.optional dv camcoder
9.optional usb cam
10.optional vcr
11.optional network drive
12.ir tx/receiver
14.wireless keyboard/mouse
15.high VA apc ups
16.optional gaming consoles
17.optional wii
18.optional wifi drones
19.optional gps receivers
20.optional pstn sip converters
21.fax/printer
connection
==========
pc's hdmi,dvd hdmi connected to hdmi in1,in2 of a/v receiver
pc ethernet port connected to router
cable tv tuner/booster connected to pc
ir connected to pc
ups connected to a/v receiver
room1
=====
1.netgear dg router
2.broadband modem
3.pc
4.lcd
5.optional dv camcoder
6.optional usb cam
7.optional vcr
8.optional network drive
9.ir tx/receiver
10.wireless keyboard/mouse
connection
==========
pc hdmi out connected to lcd
bb modem connected to dg
pc connected to dg wireless
dg connected to wg wireless
Sunday, November 21, 2010
google tv in short
mythtv plugin to a webbrowser
box needs a cable tv and broadband input
the browser should be able to search on cable and on broadband
the cable should respond to http queries
browser should have to display web and cable content
in the context of tv,web operations should be possible
It falls back to software copybit which is slow as hell, because each line of an image must be copied by the CPU (with memcpy), not even talking about software scaling. That's why copybit and 2D hardware are so important.
box needs a cable tv and broadband input
the browser should be able to search on cable and on broadband
the cable should respond to http queries
browser should have to display web and cable content
in the context of tv,web operations should be possible
It falls back to software copybit which is slow as hell, because each line of an image must be copied by the CPU (with memcpy), not even talking about software scaling. That's why copybit and 2D hardware are so important.
android flingers
1.learning has a wavy pattern
upper crest starts with abstraction
lower crest is concrete
upper(starts with some names)---lower(processes,dlls)--upper(associations)----lower(interface functions)---upper(categories,channels)----lower(context,binary modules)
mediaserver-->omx-->codec
omx buffer is sent with input buffer and offset,and returns output buffer
audio
======
af-->libaudio.so
af-->libaudio.so (alsa)
video
=====
uses EGL as interface
sf-->libhgl.so
sf-->libagl.so
codec
=====
uses OMX as interface
mediaserver-->omxnnn.so
pixelflinger/libhgl for an activity makes all defined surfaces and passes to sf
sf layers and composes them and renders using fb0
libhgl has inputs and outputs,inputs are surface data and surfaces
output is composed buffer
if this output buffer memory can be fed to fb0 the its efficient
but if it cannot be then a memcpy is required before pushing to fb0
eglbuffertypes
native
pushbuffer
fb0
All these are parallel
cpu
gpu multiple layer composer
display renderer hw
codec hw
an activity indirectly calls the eglswapbuffer,this will send data to gpu to compose,till its
completed activity waits,then the composed buffer is given to fb0
copybit.so can export any /dev/nnn,it has to define interface copybit.h,its used for 2d blit
android code assumes gpu/display to be same hw device /dev/graphics/fb0, different ioctls for operations
maybe before writing to gpu,clipping and other operations are done on figures ,a
nd later one by is rendered
upper crest starts with abstraction
lower crest is concrete
upper(starts with some names)---lower(processes,dlls)--upper(associations)----lower(interface functions)---upper(categories,channels)----lower(context,binary modules)
mediaserver-->omx-->codec
omx buffer is sent with input buffer and offset,and returns output buffer
audio
======
af-->libaudio.so
af-->libaudio.so (alsa)
video
=====
uses EGL as interface
sf-->libhgl.so
sf-->libagl.so
codec
=====
uses OMX as interface
mediaserver-->omxnnn.so
pixelflinger/libhgl for an activity makes all defined surfaces and passes to sf
sf layers and composes them and renders using fb0
libhgl has inputs and outputs,inputs are surface data and surfaces
output is composed buffer
if this output buffer memory can be fed to fb0 the its efficient
but if it cannot be then a memcpy is required before pushing to fb0
eglbuffertypes
native
pushbuffer
fb0
All these are parallel
cpu
gpu multiple layer composer
display renderer hw
codec hw
an activity indirectly calls the eglswapbuffer,this will send data to gpu to compose,till its
completed activity waits,then the composed buffer is given to fb0
copybit.so can export any /dev/nnn,it has to define interface copybit.h,its used for 2d blit
android code assumes gpu/display to be same hw device /dev/graphics/fb0, different ioctls for operations
maybe before writing to gpu,clipping and other operations are done on figures ,a
nd later one by is rendered
android surface flinger
1.libhgl.so and libagl.so are loaded into sf.
2.every activity can have one or more surfaces
3.these surfaces may be of different types
4.some of these surfaces will use hw accel some are software
5.before pushing to fb0 surfaces will be composited
6.a combination of libEGL.so and libGLESv2.so will route gl calls to libhgl or libagl.
7.can an activity have hw surface and sw surface parallelly.can these two surfaces be composited together into fb0.
8.maybe both libhgl and libagl will be loaded parallelly and activity will decide if its using libagl or libhgl.
libagl and libhgl calls have one to one correspondence,so partial use of libagl and libhgl is not possible.
8.hardware codec support can be given in android by 2 ways.within a framework or outside
1.within framework --- get the working codec driver in openmax,modify it
take a template code from framework node,change it to work like above
this will work with standard android player.openmax can be adapted to fit into android framework
2.implement a player,within the player code interface with sf and af
if gstreamer already has the codec integrated,use it with a new player engine.
9.in a accelerated codec scenario application pushes a frame desciptor to driver to hardware,descriptor has source buff addr and destination buff addr.on decoding the frame the
frame is pushed to destination buffer.from here application takes it and send to fb0.
10.video acceleration === hardware codec
display acceleration === hadware gl(compositing)
audio accel ===
audio mixing === hadware level
2.every activity can have one or more surfaces
3.these surfaces may be of different types
4.some of these surfaces will use hw accel some are software
5.before pushing to fb0 surfaces will be composited
6.a combination of libEGL.so and libGLESv2.so will route gl calls to libhgl or libagl.
7.can an activity have hw surface and sw surface parallelly.can these two surfaces be composited together into fb0.
8.maybe both libhgl and libagl will be loaded parallelly and activity will decide if its using libagl or libhgl.
libagl and libhgl calls have one to one correspondence,so partial use of libagl and libhgl is not possible.
8.hardware codec support can be given in android by 2 ways.within a framework or outside
1.within framework --- get the working codec driver in openmax,modify it
take a template code from framework node,change it to work like above
this will work with standard android player.openmax can be adapted to fit into android framework
2.implement a player,within the player code interface with sf and af
if gstreamer already has the codec integrated,use it with a new player engine.
9.in a accelerated codec scenario application pushes a frame desciptor to driver to hardware,descriptor has source buff addr and destination buff addr.on decoding the frame the
frame is pushed to destination buffer.from here application takes it and send to fb0.
10.video acceleration === hardware codec
display acceleration === hadware gl(compositing)
audio accel ===
audio mixing === hadware level
Subscribe to:
Posts (Atom)