2002-01-15 12:27
This might be premature because I will be talking about details, but I think it should be known that it's needed if TVout use will be included at some point. A 'media' OS would need a analog video out, right?
Note please that 'even' on Windows TVout is not working properly BTW (if you use 'mediaplayer' for example).
Although I am not that good a programmer yet and I don't know very much on the inner workings of BeOS or it's API's, I do have gained some knowledge about 'features' that an OS needs somehow for serious video-out use. I gained this knowledge trying to learn and understand how to program on BeOS for drivers, using VGA cards, TVout and VLC.
If the TVout of a VGA card is accessed in the right way, you can get output that (almost) matches stand-alone DVD players picture quality wise.
The basics for good output are these:
1. prevent rescaling whatsoever;
2. make sure the picture only gets updated during vertical retrace time;
3. make sure there's a lock between the video app and the generating of even/odd fields in the TVout chip.
If you don't implement one of these things, you definately will notice performance degrades, both in quality and CPU load.
Some elaboration:
1. rescaling is done in practice in different places:
- the video app rescales to full screen,
- the video app may rescale for aspect ratio,
- the TVout chip rescales for overscan compensation,
- the TVset itself rescales for aspect ratio.
Rescaling will
- increase CPU load (unless hardware overlay scaling is used);
- decrease image sharpness and introduce aliasing if scaling back or scaling in non 200, 300, 400% etc ways.
While rescaling to full screen is needed for standard desktop use, you do not want this for TVout use: A TV set has a fixed vertical resolution: for NTSC 480 and PAL 576 'pixels'. Horizontally 720 pixels are used for both PAL and NTSC DVD (both resolutions are used for both aspect 16:9 and 4:3..), and for MPEG1 768 are there for PAL and 640 for NTSC (aspect 4:3)
If you would rescale, you would need to decrease the picture size. Even if a TVout chip exists that accepts for instance 1024x768 resolution, this chip would need to scale back to above mentioned resolutions.
Any way you do it, you'll loose image sharpness at least.
2. aspect ratio scaling is used on VGA screens because these are used in 4:3 aspect resolutions, while DVD's are (often) coded in 16:9 aspects. Others are coded in 4:3 aspect, but in both (all!) cases the picture is coded in 720x480 (NTSC) or 720x576 (PAL). This means that whatever you do, you just need to output exactly this resolution to the TVset, and let the TV do the rescaling (wide mode, if needed).
There's only one exeption: IF you want to playback 16:9 coded movies on old 4:3 TV's that do not have a 'widescreen' mode. In this case you need to do aspect scaling, but do it for the MPEG1 modes which should be used then, so the TVout chip does not have to rescale again.
In order to get optimal output, the video out card (or the Desktop itself in clone mode) would need to be set to the exact resolution that will be outputted on TV. You can simply forget all aspect and normal scaling because you'll be outputting 1:1.
Nice thing is you won't need hardware overlay or so to get low CPU load: just creating two framebuffers which the video app uses directly (so no copying!) and switching between them is enough. (Note please that probably almost any videocard out there will support this way of working: this function is used in VESA VBE..) Of course this method only works in full screen mode, otherwise your other screen output (windows etc) will 'flicker' a lot.. (switching them in and out all the time) BTW this fullscreen output mode is something that could be used as a intermediate solution in between hardware overlay and Direct Window output I think.
One more thing about scaling not needed: this only goes for DVD playback, MPEG1 needs to be rescaled by an exact factor of 200%. This could even be done in hardware partially because probably all VGA cards outthere can be set to 'double scan' mode (because it's in the official VGA standard).
In double scan vertical upscaling of 200% occurs in fact, so you would only need to do horizontal scaling in software then.
(BTW, MPEG1 could be 288x352 pixels, 200% would be 576x704 pixels (intended for PAL!). This means you would get small vertical black bars at the left and right side of the screen. This is in fact how VLC does it for instance (aspect should not be changed). These small black bars will be (largely) outside of the TVset viewing area, because of the overscanning it does.
2. picture updating needs to be done during vertical retrace. If you don't do this, you'll get horizontal distorting stripes randomly on the screen during playback. If you watch a movie using Be's mediaplayer or Window's mediaplayer on TV, you will definately see this happening.
The strange thing is that you don't see this happening if you watch on VGA with normal (higher) refreshrates. Maybe this has something to do with the human eye properties.. I know for a fact that on low refreshrates, and so on TV you absolutely need to sync to retrace.
While BeOS has a WaitForRetrace() method, it seems that not all videodrivers have this implemented. Also, if you use BBitmap output for updating the screen, you can notice that with the nvidia driver for example this Wait function returns rather late: the BBitmap cannot complete in time before the next screen (field) get's outputted. So the wait function needs to be as fast as possible. (I tested with a sync directly accessing the RIVA chips using a custom driver and then BBitmap is ready in time... Also I verified that the distortions I talked about are gone if I use retrace sync.)
Of course for buffer flipping as described above, or for hardware overlay the speed of the WaitForRetrace() is not that important. After all, you just need to (re)set a hardware bufferpointer then...
3. Because the TV sets used interlaced output, the TV chip in fact re-interlaces (de-interlaced) video from the videoapp. It simply does this by scanning only the even 'lines' in the VGA chip during even field creation, and scanning the other lines for the next (odd) field.
Because MPEG1 video is played back at 200%, the even and odd lines in the VGA memory are identical. So no output problems arise here.
For MPEG2/DVD this is not the case. Even and odd lines are coming from different fields on the DVD (DVD's are coded in fields, not frames because they are intended for playback on interlaced screens!)
The DVD app has a de-interlace method, and a motion compensation method. These methods create one frame out of one even and one odd field from the DVD. Motion compensation takes care of the 'comb' effect you would normally see (on fast movement in a scene) if you just intertwine both fields and look at the resulting frame on (non-interlaced) VGA.
This motion compensation is never perfect. You have to find a compromize between image sharpness and a little visible 'comb' effect. This means that the de-interlaced frame still represents a bit of time-different fields (they are normally output *after* each other on interlaced output devices!)
On VGA you need the motion compensation, because otherwise you'll see the comb effect. In fact, some DVD discs do not (yet) get motion compensated by VLC (4:3 coded music videos often..). If you look at such a disc, on non-interlaced VGA output you'll prominently see the comb effect.
But, if you watch on TV (so interlaced) you will notice (using the discs I talked about just now) that while you definately see the comb effect on VGA, it simply does not exist at all on TV!
The reason is of course that the TVoutput is re-interlaced by just displaying one field after the other, as it was intended in the first place. The non-working motion compensation was not needed anyway on TV...
You can imagine that if you would be able to disable motion compensation completely, you'll get in fact sharper output on TV because the image sharpness decay needed for motion compensation does not happen anymore..
Now I finally can tell you why a sync/lock is needed to the generation of even/odd fields on TV:
You have to make sure you display the first DVD field first on TV; and not first display the second field, and after that the first.
Because there's movement in the movie, you get stronly shaking output on TV if you have the order wrong. If one was to wave with his/her arm in a fluent movement from left to right only once, you would see this arm going back and forth very quickly in the neigbourhoud where the arm really resides at every moment in the fluent movement.
Also, a even DVD field must be outputted on a even TV field. If you don't do that, you'll get slightly jumping output on TV. This can be seen best during de-titling at the end of a movie, if the titles go slowly from bottom to top, or vice versa. You'll think you have something in your eye, because you are not able to read the text sharply (it's a bit blurry).
Try it with VLC. You'll see what I mean..
So, even if the motion compensation is working, you'll notice some of the distortions I described sometimes, though less prominently.
If the field lock would exist, things would get really nice. You could simply forget about motion compensation, thereby lowering (once again) CPU load. (Unless you have hardware motion compensation, which probably works with hardware overlay on some cards.)
Also output sharpness would be better then as I described earlier.
If BeOS/OBOS would have the sync lock, field lock, and intermediate output via buffer flipping (combined with double scan for rescaling to 200%), you would:
- forget about scaling and motion compensation for TV output, so get as low CPU load as possible, and output as sharp as possible;
- this would work on almost every videocard outthere, while hardware scaling, hardware overlay, hardware motion compensation, hardware YUV to RGB 'translation' only exists on some cards, and also is harder (and more card specific) to implement.
Of course for VGA playback and for non-fullscreen playback you would still need scaling and real hardware overlay...
Well that's it for now. I must say I find it very interesting to test these kinds of things and finding them out, though I can only make small, 'ugly' programs for now...
I hope this story, which may be a little hard to read, will influence TVout specifics in a future verion of BeOS/OBOS! I think it's really important if TVout nodes / output will get implemented.
I also think they should be implemented, because I think the PC will get a more and more prominent central role in homes, being the radio, TV, DVD and CD player etc...
Also If BeOS would implement these things, it would certainly be far ahead in this area of any other OS I know of... (Windows and Linux do not support it.)
Best regards,
Rudolf Cornelissen.
(BeTVOut)
----------
https://sourceforge.net/projects/virtualdub/
https://sourceforge.net/projects/heroines/
http://www.schirmacher.de/arne/kino/index_e.html
http://mjpeg.sourceforge.net/
http://philippe.houdoin.free.fr/phil/beos/misc/Virtual%20Be%20Live-0.90.zip
http://www.thegreenboard.com/forum/showflat.php?Cat=&Board=projectideas&Number=8409&page=0&view=collapsed&sb=5&part=
Dear all - (ex)BeOS users/developers,
due to your interests in video software development
I'd like to invite you to join a dedicated mailing-list
that focuses on issues of:
- BeOS video/media software development,
- use of BeOS video/media software and
- media applications on other non-win/mac OS.
Goal is to establish a basic information
channel that could be used to start bigger
and smaller projects, regardless if these
are software, utilisation of software or
knowledgbase. Simple definition would be to
start a lebuzz for video and than go beyond ;)
I know your(and mine also) interest for BeOS goes
sometimes high up and bottom down, but you should
still consider the importance of sharing information
and having access to it in this small community.
Individual efforts should never be lost but we
should all benefit from experiance each of us has from
using/developing for BeOS.
Mailling-list will be hosted on sourceforge.net (you are
free to prupose alternative) and will be most likely very
focused and therefore low volume. Please confirm your interest
for joining mailling list by sendiong a short intro about
yourself and your prefered email account for mailling list
(some people keep this separate).
I apologies to all who recived this email twice (I was probably
not sure which email account you use) or who find it irelevant.
My name is ZeljkoBlace and I am long time BeOS enthusiast
looking into programming (at the very beginning of it),
working for Multimedia Institute in Zagreb as program/project
coordinator in net.culture club "mama". Have interest in
using BeOS for media projects (now mostly for VJing).
Other 2 people that confirmed involvment in this project
are DanielFischer, BeDev of MediaControl and libFMedia,
who is still actively using BeOS for his installations
and performances.
John Wiggins developer of "Jeepers Elvis!" VJing software
which just resurected this summer after a long period of
hibernation, after being inspired by BeDive.
kotobuki@rinc.or.jp, amcpacerx@yahoo.com, Keith.McAfee@GLW.com, amcpacerx@yahoo.com, jaf@lcsaudio.com, kevpatt@hopeint.org,jba03216@nifty.ne.jp, stippi@yellowbites.com, melfina@earthlink.net, sd@benews.ru, tcastley@bemail.org, folivier@cs.sun.ac.za, Satchmoz@softhome.net, marcus@lundblad.net,tebo@grabbo.com, John.Kenneth.Milli.Grytten@idi.ntnu.no, rudolfc@users.sourceforge.net,revol@free.fr, webralf1@powerpulsar.com, gottgeac@linux.zrz.tu-berlin.de, berenger@francenet.fr, axeld@users.sourceforge.net,laplace@users.sourceforge.net, eamoon@meadgroup.com, eamoon@users.sourceforge.net
video software
* François Revol mmu_man revol@free.fr
* Raphael Moll webralf1@powerpulsar.com
**** BeOS_Ji_Elvis Wiggins, John John Wiggins
* gottgeac@linux.zrz.tu-berlin.de Stills2Movie StopMotion
* StamTV,MOSAIC Georges-Edouard Berenger BeTV-OUT
* Axel Dörfler (CAPTURE) axeld axeld@users.sourceforge.net
* Michael Pfeiffer laplace@users.sourceforge.net
* Rudolf Cornelissen rudolfc@users.sourceforge.net
* John Kenneth Milli Grytten
* tebo@grabbo.com
* Jeroen Bakke elcotjbkk@wirehub.nl
About Demo studio:
Always wanted to create very professional animation, not like most commercial (fast calculation is good) applications. this is your opportunity This is a prerelease version of a very precize and accurate animation creator. it uses subpixel and subtexel within 256 bits of color accuracy (we only need the graphic accelerator for this one)
* Marcus Lundblad marcus@lundblad.net mpeg tools
* Satchmoz@softhome.net VCDTools
* folivier@cs.sun.ac.za Frank Olivier
Director: A very featureless video editor
The first bug-filled, pre-alpha alpha beta of Director, a video editing app.
* Tony Castley tcastley@bemail.org VideoLan Client
* Sergei "fyysik" Dolgov sd@benews.ru VCD
* Matt McMinn melfina@earthlink.net BeCR http://home.earthlink.net/~melfina/
* YellowBites stippi@yellowbites.com eXposer
* Jun Suzuki of MediaConverter+
mailto:jba03216@nifty.ne.jp
*********notWORKING:
tcastley@bemail.org, gottgeac@linux.zrz.tu-berlin.de, John.Kenneth.Milli.Grytten@idi.ntnu.no, melfina@earthlink.net
|