On Wed, Dec 10, 2008 at 10:07:35AM +0000, Morfsta wrote:
> Are you selling single eHD cards solely for implementation within Reel
> devices? If so, I believe you should make this clear as I wasn't aware
> of this and other users won't be. Some of the problems I have when
> running eHD with VDR 1.7.0 are: -
Well, they are sold for "hackers". As there is no "official" HDTV-capable
vdr, RMM cannot provide support for any possible patch variant. AFAIK it is
mentioned on the website that it works best with the reelvdr.
> 1) Upgrading the latest testing version SVN often causes problems with
> compilation and you have to try and track down patches from other
> sites, or for bleeding edge SVN there simply aren't any available
> resulting in it not being possible to compile it. Would it be possible
> for Reel to host patches that will apply to vanilla VDR to make this
> operate, or have I missed this already?
I don't think that RMM can make patches for vanilla vdr, because there is no
standard how to handle DVB-S2/HDTV. You have multiproto systems, you have
S2API. Neither one is used in the reelvdr. Currently there is the inofficial
PES-solution for h264, but as Klaus wants to move to TS, it is already
"deprecated". In the end, it would be a reelvdr ported to 1.7 just because
there is an 1.7. That makes no sense when there is already a maintained
1.4-1.7 chimera from RMM which works out of the box. You can download the
reelvdr source and compile it on your own. There are maybe a few
compiler/make issues, but most of them are easy to fix.
> 2) Seeking forward/backward/play/pause/fast forward/fast rewind in
> recordings does not work very well and there is a bad delay and lag
> when using these functions. This is frustrating and irritates my wife!
Hm, what means "bad" delay? The reelvdr IMO has not such issues. The
trickmodes are a bit slower in their reaction than on the latest FF card
firmware, but for me it's Ok when looking at all the buffering stages that
need to be notified and flushed...
> 3) You cannot play MKV files with the xine mediaplayer (although I
> think this also applies to Reel products)
We know. Something is wrong in the AVC-parser that affects some (not all)
MKVs.
> 4) Some channels don't work, e.g. BBC HD (very important for us
> Brits), SVT HD and others. Apparently BBC HD has been fixed in the
> Reel products but it doesn't work for vanilla VDR
This is maybe an issue due to the PES remuxing as you need to differentiate
between AC3 and MPEG during remuxing. As it seems BBC HD makes some strange
things here. The reelvdr doesn't remux HDTV and records dumb TS, so we just
had to fix it in the player detection.
> 5) If the stream is interrupted (i.e. weak signal) on HD channels /
> recordings then the picture does not recover until a channel change.
> This is a serious issue which needs to be addressed.
There are some watchdogs implemented (eg. to large timestamp jumps, internal
buffer overflow, apparent decoder stalls etc.). But the overall handling is
quite fragile, some decoder problems cannot detected. Can you reproduce
these hangs reliably?
--
Georg Acher, acher@xxxxxxxxx
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
