At 08:19 14.04.2005 +0200, you wrote:
but why should it be impossible to record the stream with a FF card?
what i forgot: if you use streamdev-server, you can do a "suspend live tv"; this disables the video decoding stuff and then it is possible to record and stream hdtv.
Wouldn't it be possible then to add "suspend live tv" to vdr so it turns the FF decoder off as soon as HDTV is detected (and maybe display a message instead if this is possible - probably not anyway)?
Cheers, Bernd
On Wednesday 20 April 2005 11:46, bernd_muc@gmx.de wrote:
At 08:19 14.04.2005 +0200, you wrote:
but why should it be impossible to record the stream with a FF card?
what i forgot: if you use streamdev-server, you can do a "suspend live tv"; this disables the video decoding stuff and then it is possible to record and stream hdtv.
Wouldn't it be possible then to add "suspend live tv" to vdr so it turns the FF decoder off as soon as HDTV is detected (and maybe display a message instead if this is possible - probably not anyway)?
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
Matthias
On Wednesday 20 April 2005 19:39, Matthias Schwarzott wrote:
On Wednesday 20 April 2005 11:46, bernd_muc@gmx.de wrote:
At 08:19 14.04.2005 +0200, you wrote:
but why should it be impossible to record the stream with a FF card?
what i forgot: if you use streamdev-server, you can do a "suspend live tv"; this disables the video decoding stuff and then it is possible to record and stream hdtv.
Wouldn't it be possible then to add "suspend live tv" to vdr so it turns the FF decoder off as soon as HDTV is detected (and maybe display a message instead if this is possible - probably not anyway)?
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
or doing a software-playback (using mplayer) instead?
or going into transfer mode and doing a software-scale-down playing back a modified stream?
Matthias Schwarzott wrote: ...
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
I would like that much better than a crash. :-)
The current behaviour (HDTV channels get into channels.conf automatically, if you happen to zap to such a channel innocently, the driver crashes) is not very user-friendly.
Carsten.
Carsten Koch wrote:
Matthias Schwarzott wrote: ...
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
I would like that much better than a crash. :-)
The current behaviour (HDTV channels get into channels.conf automatically, if you happen to zap to such a channel innocently, the driver crashes) is not very user-friendly.
The main question is: how do you detect a "HDTV channel" just from the SI data?
Klaus
On Wednesday 20 April 2005 20:08, Guido Fiala wrote:
On Wednesday 20 April 2005 19:39, Matthias Schwarzott wrote:
On Wednesday 20 April 2005 11:46, bernd_muc@gmx.de wrote:
At 08:19 14.04.2005 +0200, you wrote:
but why should it be impossible to record the stream with a FF card?
what i forgot: if you use streamdev-server, you can do a "suspend live tv"; this disables the video decoding stuff and then it is possible to record and stream hdtv.
Wouldn't it be possible then to add "suspend live tv" to vdr so it turns the FF decoder off as soon as HDTV is detected (and maybe display a message instead if this is possible - probably not anyway)?
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
or doing a software-playback (using mplayer) instead?
Yes, I also think you have to use software-playback, but in first place you have to prevent the mpeg-decoder of the ff-card to get in touch with the hdtv content and crash. And cause this is not possible in the firmware and in vdr on the fly without slowing down channel switches it must be stored either in the channels.conf or additionally and connected to channel-ids or similar.
Matthias
Klaus Schmidinger wrote:
Carsten Koch wrote:
Matthias Schwarzott wrote: ...
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
I would like that much better than a crash. :-)
The current behaviour (HDTV channels get into channels.conf automatically, if you happen to zap to such a channel innocently, the driver crashes) is not very user-friendly.
The main question is: how do you detect a "HDTV channel" just from the SI data?
I do not know. But the femon plugin is able to display the resolution of the current stream, so that information is obviously available to vdr. Would it not be possible to show a black screen and some OSD message whenever the resolution of the current stream is > 720x576?
Carsten.
On Wednesday 20 April 2005 21:22, Carsten Koch wrote:
Klaus Schmidinger wrote:
Carsten Koch wrote:
Matthias Schwarzott wrote: ...
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
I would like that much better than a crash. :-)
The current behaviour (HDTV channels get into channels.conf automatically, if you happen to zap to such a channel innocently, the driver crashes) is not very user-friendly.
The main question is: how do you detect a "HDTV channel" just from the SI data?
I do not know. But the femon plugin is able to display the resolution of the current stream, so that information is obviously available to vdr. Would it not be possible to show a black screen and some OSD message whenever the resolution of the current stream is > 720x576?
The simplest method I can think of is:
Every channel gets an additional value used to store one of the following values:
UNKNOWN: need to test the channel HDTV: not playable by FF-card NOHDTV: playable by FF-card
If not present or channel gets added new, this value is initialized with UNKNOWN.
When switching to this channel for viewing it depends on the value what to do: HDTV: if output-device not capable of HDTV: block this attempt (or play sound and show error-stillframe) NOHDTV: continue as usual UNKNOWN: Do not set Video-PID for decoding, but for pass to userspace; Analyse it like femon does and decide between HDTV and NOHDTV, write value and continue switching as above.
The only visible effect for the user is, that the first switch to a channel is delayed.
But up to now I have no idea how this could be implemented.
Matthias
Carsten Koch wrote:
Klaus Schmidinger wrote:
Carsten Koch wrote:
Matthias Schwarzott wrote:
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
I would like that much better than a crash. :-)
The current behaviour (HDTV channels get into channels.conf automatically, if you happen to zap to such a channel innocently, the driver crashes) is not very user-friendly.
The main question is: how do you detect a "HDTV channel" just from the SI data?
I do not know. But the femon plugin is able to display the resolution of the current stream, so that information is obviously available to vdr. Would it not be possible to show a black screen and some OSD message whenever the resolution of the current stream is > 720x576?
The femon plugin gets this information directly from the video elementary stream. So the problem remains to get that high bandwidth stream from the FF-card. May be a solution would be to request a single PES paket with the PES_OTHER flag instead of PES_VIDEO so that it won't get routed through mpeg decoder. This would slow down the tuning process though.
Carsten.
Christian
Zitat von Christian Schuld chris@sonnengesicht.de:
Carsten Koch wrote:
Klaus Schmidinger wrote:
Carsten Koch wrote:
Matthias Schwarzott wrote:
Or another posibility to get HDTV. How about marking a channel not be displayable with ff-card and then showing only a black screen if such a channel is detected.
I would like that much better than a crash. :-)
The current behaviour (HDTV channels get into channels.conf automatically, if you happen to zap to such a channel innocently, the driver crashes) is not very user-friendly.
The main question is: how do you detect a "HDTV channel" just from the SI data?
I do not know. But the femon plugin is able to display the resolution of the current stream, so that information is obviously available to vdr. Would it not be possible to show a black screen and some OSD message whenever the resolution of the current stream is > 720x576?
The femon plugin gets this information directly from the video elementary stream. So the problem remains to get that high bandwidth stream from the FF-card. May be a solution would be to request a single PES paket with the PES_OTHER flag instead of PES_VIDEO so that it won't get routed through mpeg
decoder. This would slow down the tuning process though.
Instead: How's the chance the firmware is being fixed not to crash but to gracefully ignore data it can't handle? Some configurable plausibility checks on header data would certainly do (This would obviously also help on the subject off ARM crashes upon loss of signal or garbage received)
On Thu, Apr 21, 2005 at 09:19:15AM +0200, gfiala@s.netic.de wrote:
Instead: How's the chance the firmware is being fixed not to crash but to gracefully ignore data it can't handle? Some configurable plausibility checks on header data would certainly do (This would obviously also help on the subject off ARM crashes upon loss of signal or garbage received)
Does not work due to the fact that the firmware uses the onboard PROM and is build with help of a binary only library ... even the firmware hackers do not know much what is in the library and on the PROM.
Werner
Zitat von "Dr. Werner Fink" werner@suse.de:
On Thu, Apr 21, 2005 at 09:19:15AM +0200, gfiala@s.netic.de wrote:
Instead: How's the chance the firmware is being fixed not to crash but to
gracefully
ignore data it can't handle? Some configurable plausibility checks on
header
data would certainly do (This would obviously also help on the subject off
ARM
crashes upon loss of signal or garbage received)
Does not work due to the fact that the firmware uses the onboard PROM and is build with help of a binary only library ... even the firmware hackers do not know much what is in the library and on the PROM.
OS on closed binary on top of closed binary? Hope someone responsible does see an advantage in fixing it. Or is there some new FF-hardware in sight that may be better fitted for the job?
Dr. Werner Fink wrote:
On Thu, Apr 21, 2005 at 09:19:15AM +0200, gfiala@s.netic.de wrote:
Instead: How's the chance the firmware is being fixed not to crash but to gracefully ignore data it can't handle? Some configurable plausibility checks on header data would certainly do (This would obviously also help on the subject off ARM crashes upon loss of signal or garbage received)
Does not work due to the fact that the firmware uses the onboard PROM and is build with help of a binary only library ... even the firmware hackers do not know much what is in the library and on the PROM.
Gee, back 5 years ago when I bought my first FF card to build a VDR system out of an old 150MHz PentiumPro PC, it seemed like a nice idea to have the MPEG decoder on the card. Today, given the facts that
* a FF card costs as much as 3 or more budget cards * a FF card has smaller bandwidth that a budget card and thus can record less streams in parallel * a FF card contains closed source firmware that crases on various perfectly legitimate occasions (such as distorted signal due to bad weather or HDTV signals)
I am wondering how well the alternative solutions which do not require a FF card work.
Is a FF card still the most stable solution (except for bad weather or HDTV of course)? How reliable is the latest xine plugin? How reliable is the latest framebuffer plugin? Are there more solutions that work with a budget card alone?
Carsten.
On Thu, Apr 21, 2005 at 01:24:36PM +0200, Carsten Koch wrote:
Gee, back 5 years ago when I bought my first FF card to build a VDR system out of an old 150MHz PentiumPro PC, it seemed like a nice idea to have the MPEG decoder on the card. Today, given the facts that
- a FF card costs as much as 3 or more budget cards
- a FF card has smaller bandwidth that a budget card and thus can record less streams in parallel
- a FF card contains closed source firmware that crases on various perfectly legitimate occasions (such as distorted signal due to bad weather or HDTV signals)
I am wondering how well the alternative solutions which do not require a FF card work.
I'd like to see a HW decoder (Mpeg 1/2/4), S-Video and DVI out for 720p and 1080i on a graphic card with an open source driver supporting this decoder.
The question is: will this ever happen?
Is a FF card still the most stable solution (except for bad weather or HDTV of course)? How reliable is the latest xine plugin? How reliable is the latest framebuffer plugin? Are there more solutions that work with a budget card alone?
The main problem is: you need CPU power and therefore you'll get a system which can not passive cooled and even a low noise cooling is a big problem.
Werner
On Thu, 2005-04-21 at 13:33 +0200, Dr. Werner Fink wrote:
I'd like to see a HW decoder (Mpeg 1/2/4), S-Video and DVI out for 720p and 1080i on a graphic card with an open source driver supporting this decoder.
The X-card fits the bill. There's docs available on the net, there's a binary proprietary driver that works with linux, and the driver could build upon the already existing dxr3 driver.
I am wondering how well the alternative solutions which do not require a FF card work.
I'd like to see a HW decoder (Mpeg 1/2/4), S-Video and DVI out for 720p and 1080i on a graphic card with an open source driver supporting this decoder.
The question is: will this ever happen?
Is a FF card still the most stable solution (except for bad weather or HDTV of course)? How reliable is the latest xine plugin? How reliable is the latest framebuffer plugin? Are there more solutions that work with a budget card alone?
The main problem is: you need CPU power and therefore you'll get a system which can not passive cooled and even a low noise cooling is a big problem.
Exactly, that and the cost of electricity - it is already much more than a decent DVD-player and with such requirements one needs the fastest CPU out there, especially when the system is doing more things at once like mine (it is my vdr+workstation in parallel with anything i need a computer for). If you compare fast (software decoding) systems with "suitable fast"(TM) systems you will certainly see a factor 2, 3 or more in power dissipation. And many vdr's run all day...
Also: despite all the fine multitasking - so long we have no KURT-like realtime capabilities in linux kernel you will always see drop outs and lack of response when something else is running in the background causing momentarily heavy load, very annoying. (That is, what was keeping me away from using the xine-plugin so far).
So a hardware decoder at least would be really great. Somewhere i read XOSD library, would it be possible to use that to draw in front of the hardware decoded video-overlay?
On Thu, Apr 21, 2005 at 12:53:32PM +0100, Torgeir Veimo wrote:
On Thu, 2005-04-21 at 13:33 +0200, Dr. Werner Fink wrote:
I'd like to see a HW decoder (Mpeg 1/2/4), S-Video and DVI out for 720p and 1080i on a graphic card with an open source driver supporting this decoder.
The X-card fits the bill. There's docs available on the net, there's a binary proprietary driver that works with linux, and the driver could build upon the already existing dxr3 driver.
Does the REALmagice X-Card from Sigma really support more than pixles 720 x 576 for PAL? And does this card really include an DVI out?
Werner
Zitat von Torgeir Veimo torgeir@pobox.com:
On Thu, 2005-04-21 at 13:33 +0200, Dr. Werner Fink wrote:
I'd like to see a HW decoder (Mpeg 1/2/4), S-Video and DVI out for 720p and 1080i on a graphic card with an open source driver supporting this decoder.
The X-card fits the bill. There's docs available on the net, there's a binary proprietary driver that works with linux, and the driver could build upon the already existing dxr3 driver.
Really? Seems to have no OSD, only supports Loop-through output. Would at least like DVI for HDTV and with loop-through only, one can never have an OSD.
Despite one might assume similar problems because of the "binary driver" will soon appear...sorry for being sarcastic.
On Thu, 2005-04-21 at 14:26 +0200, Dr. Werner Fink wrote:
On Thu, Apr 21, 2005 at 12:53:32PM +0100, Torgeir Veimo wrote:
On Thu, 2005-04-21 at 13:33 +0200, Dr. Werner Fink wrote:
I'd like to see a HW decoder (Mpeg 1/2/4), S-Video and DVI out for 720p and 1080i on a graphic card with an open source driver supporting this decoder.
The X-card fits the bill. There's docs available on the net, there's a binary proprietary driver that works with linux, and the driver could build upon the already existing dxr3 driver.
Does the REALmagice X-Card from Sigma really support more than pixles 720 x 576 for PAL? And does this card really include an DVI out?
True, it lacks 1080i support and DVI output.
Dr. Werner Fink a écrit :
On Thu, Apr 21, 2005 at 12:53:32PM +0100, Torgeir Veimo wrote:
On Thu, 2005-04-21 at 13:33 +0200, Dr. Werner Fink wrote:
I'd like to see a HW decoder (Mpeg 1/2/4), S-Video and DVI out for 720p and 1080i on a graphic card with an open source driver supporting this decoder.
The X-card fits the bill. There's docs available on the net, there's a binary proprietary driver that works with linux, and the driver could build upon the already existing dxr3 driver.
Does the REALmagice X-Card from Sigma really support more than pixles 720 x 576 for PAL? And does this card really include an DVI out?
From http://www.sigmadesigns.com/products/xcard_reviews/techtv070802.pdf * composite + s-video + component out (YPbPr) * output up to 1080i * max source resolution 720x576 This one does not fit the bill...
The CLE266 on the Via EPIA motherboards goes in the right way. The next chipset CN400 adds MPEG4 decoding. The open-source MPEG2 driver is quite usable. Output is VGA (not DVI), but composite/s-video output is crap (but who cares, if the goal is HDTV). Certainly does not handle HDTV, but the newer could do that.
On Thu, 2005-04-21 at 15:06 +0200, Nicolas Huillard wrote:
The CLE266 on the Via EPIA motherboards goes in the right way. The next chipset CN400 adds MPEG4 decoding. The open-source MPEG2 driver is quite usable. Output is VGA (not DVI), but composite/s-video output is crap (but who cares, if the goal is HDTV). Certainly does not handle HDTV, but the newer could do that.
Let's hope that David Airlie manages to get around implementing open source XvMC support for radeons. That would bring cpu usage for hdtv playback down a bit.
http://www.livejournal.com/users/airlied/
-
bernd_muc＠gmx.de -
Carsten Koch -
Christian Schuld -
Dr. Werner Fink -
gfiala＠s.netic.de -
Guido Fiala
-
Klaus Schmidinger -
Matthias Schwarzott -
Nicolas Huillard -
Torgeir Veimo