Hello
here http://www.reel-multimedia.de/shop/product_info.php?products_id=223 there's info about of selling this hardware h264 decoder in August.
and here there's first test's result http://www.vdr-portal.de/board/thread.php?postid=631271#post631271
Igor
On 4 Aug 2007, at 14:25, Igor wrote:
Hello
here http://www.reel-multimedia.de/shop/product_info.php? products_id=223 there's info about of selling this hardware h264 decoder in August.
This page says
Videooutputs: » HDMI-port/output » YUV-port/output (DIN)
I assume the DIN port means S-Video output? Is that then the same output down scaled to 576i, with correct field parity?
and here there's first test's result http://www.vdr-portal.de/board/thread.php?postid=631271#post631271
On Sun, Aug 05, 2007 at 09:59:01PM +0100, Torgeir Veimo wrote:
Videooutputs: » HDMI-port/output » YUV-port/output (DIN)
I assume the DIN port means S-Video output? Is that then the same output down scaled to 576i, with correct field parity?
DIN is a bit misleading, it's a 9pin Mini-DIN plug, similar to some graphics cards. There's YUV on it and for SDTV-modes optionally YC instead. HDMI and YUV have identical timings for now, so except it's not possible to have simultaneously 1080i on HDMI and PAL-YC on the Mini-DIN, 576p on HDMI is the exception.
and here there's first test's result http://www.vdr-portal.de/board/thread.php?postid=631271#post631271
...describing a very early stage of the SW... It's getting better day by day ;-)
On 5 Aug 2007, at 22:34, Georg Acher wrote:
DIN is a bit misleading, it's a 9pin Mini-DIN plug, similar to some graphics cards. There's YUV on it and for SDTV-modes optionally YC instead. HDMI and YUV have identical timings for now, so except it's not possible to have simultaneously 1080i on HDMI and PAL-YC on the Mini-DIN, 576p on HDMI is the exception.
Hmm, a bit confusing.. Your saying that it's a component signal, not composite nor s-video? And you can only have output on both if the driver is set to output 576p? Or are you saying you can have output on both, but only as 576i if the driver sets a mode for 576p on the HDMI output?
How is the driver support done? As a dvb driver similar to the drivers for full featured cards? The german vdr forum postings didn't translate very well with google translate.
On Sun, Aug 05, 2007 at 10:59:21PM +0100, Torgeir Veimo wrote:
Hmm, a bit confusing.. Your saying that it's a component signal, not composite nor s-video? And you can only have output on both if the
You can have it all for 576i, for other resolutions it's only YUV. The DAC is a Focus FS453 with 4 analog outputs. Usually 3 of them are YUV and the remaining is composite. But you can switch the YUV to YC.
driver is set to output 576p? Or are you saying you can have output on both, but only as 576i if the driver sets a mode for 576p on the HDMI output?
There's always output on HDMI and YUV with the same resolution, except 576p. There you can also have 576i on YUV/YC/CVBS.
How is the driver support done? As a dvb driver similar to the drivers for full featured cards? The german vdr forum postings didn't translate very well with google translate.
There was a discussion on that in this list a while ago which ended in fruitless anoyance about one binary only module in the Linux kernel on the HD card. Look for "future VDR and NetCeiver OEM from Reelmultimedia" and "issues about binary only code...".
For the moment, we have only a plugin for vdr and some demo programs to transfer TS/ES data. There's no plan for a DVB adapter-like integration, but there's no obstacle in writing one...
The current scheme works quite fine, also it requires only a small DVB-independent kernel driver for establishing the shared memory communication. BTW, when reading the DVB-ML, I don't get the impression that the DVB subsystem is in a good shape for the near future :-(
Georg Acher wrote:
There was a discussion on that in this list a while ago which ended in fruitless anoyance about one binary only module in the Linux kernel on the HD card. Look for "future VDR and NetCeiver OEM from Reelmultimedia" and "issues about binary only code...".
its not really about the binary if its working its mote the fact that future kernel wont support this binary stuff and its supposed to be a future proof solution
For the moment, we have only a plugin for vdr and some demo programs to transfer TS/ES data. There's no plan for a DVB adapter-like integration, but there's no obstacle in writing one...
"only a plugin for vdr"? does that mean a output plugin like the one for the dxr3? does it work with other plugins like the dvd-plugin? what about the h.264, vdr does not support that (yet)?
The current scheme works quite fine, also it requires only a small DVB-independent kernel driver for establishing the shared memory communication. BTW, when reading the DVB-ML, I don't get the impression that the DVB subsystem is in a good shape for the near future :-(
anything better to offer? the problem is that this is the only solution for linux with vdr
On Mon, Aug 06, 2007 at 08:44:49PM +0200, Lars Bläser wrote:
For the moment, we have only a plugin for vdr and some demo programs to transfer TS/ES data. There's no plan for a DVB adapter-like integration, but there's no obstacle in writing one...
"only a plugin for vdr"? does that mean a output plugin like the one for the dxr3?
Haven't seen that yet, but I guess it's similar. It has methods for playing ES and TS (see below) and uses the transfer mode.
does it work with other plugins like the dvd-plugin?
Yes. It also provides the OSD-stuff.
what about the h.264, vdr does not support that (yet)?
"Our" vdr does already. Due to performance constraints with the Geode, remux.c was replaced in the RMM-vdr with a more optimized one from the beginning (but it's still API compatible). That allows some really nasty extensions...
Now there's a simple h264 detection added. It's maybe not formally correct (I'm sure that I've missed some obscure packing scenarios), but it works with the few h264 channels on air... After the h264 detection, the remux output is no longer PES, but raw TS. So the CPU load SDTV vs. HDTV is about the same, no complex repacking is done for h264. The TS recordings have a synthetic PMT now and then, so they are correctly detected by mplayer/vlc. The frame index is also stored, ie. go-to and jumps work. The playback section detects the TS format and forwards it directly via the TS-play-methods to the card, as the TS demux runs on the DeCypher (load sharing, quite important with a 300MHz turtle ;-) ).
The current scheme works quite fine, also it requires only a small DVB-independent kernel driver for establishing the shared memory communication. BTW, when reading the DVB-ML, I don't get the impression that the DVB subsystem is in a good shape for the near future :-(
anything better to offer?
No (enough other things to do...), but the idea of putting the tuner parts into user space is IMO the future.
the problem is that this is the only solution for linux with vdr
The old API itself is OK for most aplications. But I don't want to write a device driver now. I've lost track during all the PLL refactoring and the totally new API for S2 support is IMO a bit oversized and too preliminary to rely on for a "product".
The RMM S2 stuff on the RB Lite uses the old 2.6.11 and packs the few additional S2 parameters in the upper FEC bits. It is a hack, no question, but it's compatible and an easy patch on "proven" kernels.
On 08/06/07 21:57, Georg Acher wrote:
... "Our" vdr does already. Due to performance constraints with the Geode, remux.c was replaced in the RMM-vdr with a more optimized one from the beginning (but it's still API compatible). That allows some really nasty extensions...
Now there's a simple h264 detection added. It's maybe not formally correct (I'm sure that I've missed some obscure packing scenarios), but it works with the few h264 channels on air... After the h264 detection, the remux output is no longer PES, but raw TS. So the CPU load SDTV vs. HDTV is about the same, no complex repacking is done for h264. The TS recordings have a synthetic PMT now and then, so they are correctly detected by mplayer/vlc. The frame index is also stored, ie. go-to and jumps work. The playback section detects the TS format and forwards it directly via the TS-play-methods to the card, as the TS demux runs on the DeCypher (load sharing, quite important with a 300MHz turtle ;-) ).
How do you handle different audio tracks (German, English, etc) and subitles in a TS stream? (Not that the core VDR supports subtitles, yet, but it will at some point, and I don't see that happening with TS).
Klaus
On Mon, Aug 06, 2007 at 10:19:50PM +0200, Klaus Schmidinger wrote:
How do you handle different audio tracks (German, English, etc) and
Then there is more than one audio PID in the TS. But I don't know if the current PMT generation can handle that. But it doesn't look impossible, in the beginning everything was TS anyway ;-)
subitles in a TS stream? (Not that the core VDR supports subtitles, yet, but it will at some point, and I don't see that happening with TS).
No subtitles for h264 for now... But AFAIK they are encoded in a separate PID, so recording should be easy.
On 08/06/07 22:38, Georg Acher wrote:
On Mon, Aug 06, 2007 at 10:19:50PM +0200, Klaus Schmidinger wrote:
How do you handle different audio tracks (German, English, etc) and
Then there is more than one audio PID in the TS. But I don't know if the current PMT generation can handle that. But it doesn't look impossible, in the beginning everything was TS anyway ;-)
subitles in a TS stream? (Not that the core VDR supports subtitles, yet, but it will at some point, and I don't see that happening with TS).
No subtitles for h264 for now... But AFAIK they are encoded in a separate PID, so recording should be easy.
The way VDR currently handles different tracks is to identify them through their PES ids, and I'd like to keep it that way when going to HDTV.
But if TS works for you, that's fine, of course.
What I am wondering about, though, is: how do you detect the frame borders in order to generate the index file? Don't you have to unpack the TS to "see" the actual payload, anyway?
Klaus
On Mon, Aug 06, 2007 at 10:55:56PM +0200, Klaus Schmidinger wrote:
The way VDR currently handles different tracks is to identify them through their PES ids, and I'd like to keep it that way when going to HDTV.
In the end, it's an ID...
But if TS works for you, that's fine, of course.
If vdr can handle both formats I can't see any disadvantage. Most TV h264 recordings "in the wild" are TS with PAT/PMT anyway... So I don't see the need for repacking it in a non-standard way. A lot of RB customers with Windows on the PC have problems with that format. A lot of popular editing tools do not and will not support it, so they need to fiddle with ProjectX first etc...
What I am wondering about, though, is: how do you detect the frame borders in order to generate the index file? Don't you have to unpack the TS to "see" the actual payload, anyway?
All current h264 channels start a frame with the beginning of a new PES packet. So when the PES-flag is set, the first two TS packets after that are searched for the access unit delimiter. This optimization reduces the CPU load considerably. For MPEG2, the RMM-remux already works similar when it detects this behavior (new frame at the beginning of new PES). Surprisingly, almost all "usefull" channels can benefit from this optimization. The ones where it does not work have low data rate anyway...
Lars Bläser wrote:
Georg Acher wrote:
There was a discussion on that in this list a while ago which ended in fruitless anoyance about one binary only module in the Linux kernel on the HD card. Look for "future VDR and NetCeiver OEM from Reelmultimedia" and "issues about binary only code...".
its not really about the binary if its working its mote the fact that future kernel wont support this binary stuff and its supposed to be a future proof solution
As Georg said, this binary module is *inside* the *card*. It may "only" limit your ability to update/modify the kernel which is running *in* the card. I don't see much of a problem in that (note that the firmware of current DVB full-featured cards is completely closed!), while some others do.
On Mon, Aug 06, 2007 at 12:24:14AM +0200, Georg Acher wrote:
On Sun, Aug 05, 2007 at 10:59:21PM +0100, Torgeir Veimo wrote:
Hmm, a bit confusing.. Your saying that it's a component signal, not composite nor s-video? And you can only have output on both if the
You can have it all for 576i, for other resolutions it's only YUV. The DAC is a Focus FS453 with 4 analog outputs. Usually 3 of them are YUV and the remaining is composite. But you can switch the YUV to YC.
driver is set to output 576p? Or are you saying you can have output on both, but only as 576i if the driver sets a mode for 576p on the HDMI output?
There's always output on HDMI and YUV with the same resolution, except 576p. There you can also have 576i on YUV/YC/CVBS.
Just to make it absolutely clear and sum it up..
Available outputs:
576i: HDMI, Component (YUV), Svideo, Composite 576p: HDMI, Component (YUV) both 576p/i, Svideo (576i), Composite (576i) 720p: HDMI and Component (YUV) 1080i: HDMI and Component (YUV) 1080p: Not supported?
And for 576i/p you can have both component and composite at the same time, or then only svideo from the analog output?
What kind of scaling is supported by the card?
Also, is MPEG1 decoding supported? I guess that's the easiest format to encode to if wanting to play videos encoded with non-supported codecs..
Next I was about to ask for OSD support, but I guess it was already answered on another mail.. so this card has OSD support? How many colors or other limitations?
Thanks a lot! This card looks like really interesting..
-- Pasi
On Fri, Aug 10, 2007 at 02:40:57PM +0300, Pasi Kärkkäinen wrote:
On Mon, Aug 06, 2007 at 12:24:14AM +0200, Georg Acher wrote:
On Sun, Aug 05, 2007 at 10:59:21PM +0100, Torgeir Veimo wrote:
Hmm, a bit confusing.. Your saying that it's a component signal, not composite nor s-video? And you can only have output on both if the
You can have it all for 576i, for other resolutions it's only YUV. The DAC is a Focus FS453 with 4 analog outputs. Usually 3 of them are YUV and the remaining is composite. But you can switch the YUV to YC.
driver is set to output 576p? Or are you saying you can have output on both, but only as 576i if the driver sets a mode for 576p on the HDMI output?
There's always output on HDMI and YUV with the same resolution, except 576p. There you can also have 576i on YUV/YC/CVBS.
Just to make it absolutely clear and sum it up..
Available outputs:
576i: HDMI, Component (YUV), Svideo, Composite 576p: HDMI, Component (YUV) both 576p/i, Svideo (576i), Composite (576i) 720p: HDMI and Component (YUV) 1080i: HDMI and Component (YUV) 1080p: Not supported?
And for 576i/p you can have both component and composite at the same time, or then only svideo from the analog output?
What kind of scaling is supported by the card?
Also, is MPEG1 decoding supported? I guess that's the easiest format to encode to if wanting to play videos encoded with non-supported codecs..
.. and one more thing in addition to the earlier questions..
Should this card be able to play other types of MPEG4 than h.264? XVID, Divx 3/4/5/6 ?
Thanks!
-- Pasi
Pasi Kärkkäinen schrieb:
Just to make it absolutely clear and sum it up..
Available outputs:
576i: HDMI, Component (YUV), Svideo, Composite 576p: HDMI, Component (YUV) both 576p/i, Svideo (576i), Composite (576i) 720p: HDMI and Component (YUV) 1080i: HDMI and Component (YUV) 1080p: Not supported?
from my understanding of happened discussions: 1080p: HDMI supported, YUV Not supported (the decoderchip should be able to handle it , the Focus(? - Chip for analog output) can not handle it according to spec. *unofficially only from my understanding
And for 576i/p you can have both component and composite at the same time, or then only svideo from the analog output?
What kind of scaling is supported by the card?
Also, is MPEG1 decoding supported? I guess that's the easiest format to encode to if wanting to play videos encoded with non-supported codecs..
Easiest would be , if there would be a framebuffer you just could use for it, shouldn't it ?
Next I was about to ask for OSD support, but I guess it was already answered on another mail.. so this card has OSD support? How many colors or other limitations?
Thanks a lot! This card looks like really interesting..
Yes the same i think - looks like NG FF card ;) - so who is starting to buy one ? ;)
On Fri, Aug 10, 2007 at 02:12:22PM +0200, Steffen Barszus wrote:
Pasi Kärkkäinen schrieb:
Next I was about to ask for OSD support, but I guess it was already answered on another mail.. so this card has OSD support? How many colors or other limitations?
Thanks a lot! This card looks like really interesting..
Yes the same i think - looks like NG FF card ;) - so who is starting to buy one ? ;)
I did ;)
Got reply on 23.7. from Reel: New status: Versandfreigabe
I was really waiting for the card, but after the Acher's reply "No subtitles for h264 for now...", there's no hurry to start to tests after the card (hopefully someday) arrives...
br.
...hanu
On 8/10/07, Hannu Tirkkonen vdr@hanu.com wrote:
I did ;)
Got reply on 23.7. from Reel: New status: Versandfreigabe
I was really waiting for the card, but after the Acher's reply "No subtitles for h264 for now...", there's no hurry to start to tests after the card (hopefully someday) arrives...
Does this mean RMM has actually shipped you the card ? I want to order this card but when I created an account on the RMM shopping website it would not allow me to see the prices of any of the products. I suspect because I'm in the USA it will not show me prices in USD. I have e-mailed RMM about pricing/availability of the card but have not gotten any response.
Thank You, Jeremy
On Tue, Aug 14, 2007 at 09:28:40AM -0700, Jeremy Jones wrote:
On 8/10/07, Hannu Tirkkonen vdr@hanu.com wrote:
I did ;)
Got reply on 23.7. from Reel: New status: Versandfreigabe
Does this mean RMM has actually shipped you the card ? I want to order this card but when I created an account on the RMM shopping website it would not allow me to see the prices of any of the products. I suspect because I'm in the USA it will not show me prices in USD. I have e-mailed RMM about pricing/availability of the card but have not gotten any response.
Even though the status of the order says, that the card has been shipped, I'm not going to hold by breath while waiting for the card ;)
Stefan Acher said that the card is still in pre-production, so I'm guessing the card to arrive in the end of September.
The prices seems to be shown only in euros, but just fill the price to google and it will show it in USD ;) For example fill 200 EUR and the google will show: 200 Euros = 273.34 U.S. dollars
Of course you could always call them ;) There's contact information : http://www.reel-multimedia.de/shop/shop_content.php?coID=4
...hanu
On Fri, Aug 10, 2007 at 02:12:22PM +0200, Steffen Barszus wrote:
from my understanding of happened discussions: 1080p: HDMI supported, YUV Not supported (the decoderchip should be able to handle it , the Focus(? - Chip for analog output) can not handle it according to spec. *unofficially only from my understanding
Correct.
Easiest would be , if there would be a framebuffer you just could use for it, shouldn't it ?
There is a memory mapped framebuffer visible over PCI, we just have to write a driver for it. Then also X should be possible (@800*600, 32bit RGBA), but until then, consider this as a "maybe" and not a promised feature. The vdr-osd is currently done by message passing to a drawing daemon on the card itself.
But for playing back "unsupported" formats, recoding to MPEG1 should be do-able, I haven't tried it. Also note that some "unsupported" or not mentioned formats may actually be supported by the chip and we just currently have no SW support for that (container parsing, etc.). There are people working on the "universal media player part". But that's not my area, I can't comment on other supported formats than h.264 and MPEG2 (SD/HD) for now.
Yes the same i think - looks like NG FF card ;) - so who is starting to buy one ? ;)
For the "full" it's missing the tuner. But given the TV programming nowadays, it's not a real drawback ;-)
Georg Acher wrote:
But for playing back "unsupported" formats, recoding to MPEG1 should be do-able, I haven't tried it. Also note that some "unsupported" or not mentioned formats may actually be supported by the chip and we just currently have no SW support for that (container parsing, etc.). There are people working on the "universal media player part". But that's not my area, I can't comment on other supported formats than h.264 and MPEG2 (SD/HD) for now.
Just one comment on another format: VC-1? Do you know if the board supports it? I know that VC-1 is not common on DVB, but I would prefer a hw acceleration solution that supports all the HDDVD/Bluray codecs.
And one general question: Does the HDMI output support 24p?
Thanx in advance
Joerg
Dear Georg
which minimal requiremnts (CPU, memory) should has computer during watching h264 satellites channels or playing back of 1080i-files, if this card will be install in the VDR-computer ?
BTW, what variant is better - to buy this card or to upgrade CPU and video-card?
Igor
For the price of that card you can almost build a pc that can handle hdtv. No thanks.
On Mon, Aug 06, 2007 at 08:30:26AM +0400, Igor wrote:
Dear Georg
which minimal requiremnts (CPU, memory) should has computer during watching h264 satellites channels or playing back of 1080i-files, if this card will be install in the VDR-computer ?
Almoste the same HW (but with different form factor) is used in the Reelbox Lite. It has a 300MHz Geode (128MB) which is much slower than any EPIA CPU you can get. But it's enough to watch and record HDTV at the same time. The raw playback needs about 20-30%CPU time, but that's only because the Geode can't do any bursts on the PCI bus as a master and therefore the PCI bandwidth is limited to about 12MB/s.
BTW, what variant is better - to buy this card or to upgrade CPU and video-card?
Depends ;-) The power consumption of the card is less than 8W, might be useful in some applications...
-
Anssi Hannula -
Georg Acher -
Hannu Tirkkonen -
Igor -
Jeremy Jones -
Joerg Knitter -
Klaus Schmidinger -
Lars Bläser -
Pasi Kärkkäinen -
Steffen Barszus -
Torgeir Veimo -
VDR User