Loggytronic Forum

VOMP => Vomp For Windows => Topic started by: MartenR on February 08, 2010, 15:50:20

Title: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on February 08, 2010, 15:50:20
Hi,
maybe you have recognized, that vomp has now HDTV support in current cvs, this is mainly for windows in the moment. (Thanks to Carsten for testing).
I am searching for volunteers, who will test this HDTV feature on their machines using special vomp test builds I will provide the next days in this threads.
I need this to guarantee compatibility with a broad range of decoders and graphicscards.
So far recordings work and live TV may work.

A new vompserver is needed, which is incompatible with older versions.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on February 11, 2010, 03:18:20
First Testversion, I will remove this version when a new testversion is posted here.
Please provide feedback!

Note: The cvs version of vompserver-plugin is needed!
At least vdr with built-in HDTV and TS recording needed. Only TS recording supported for HD playback.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: izeman on February 14, 2010, 20:04:23
hi marten

d'lded, tried out, but i stops at "connected, loading config", and using both cores @100%
could also be some security tool installed at my companies laptop.

i'll try some other pc and report back

regards izeman
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on February 14, 2010, 22:07:08
I think this because you have to update the server to cvs version.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on February 22, 2010, 15:22:07
New version including test for dingo35.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 23, 2010, 14:09:10
Marten, I have done some limited testing. Here are my first findings.

First try didnt work, then set my h264filter to my installed CoreAVC plugin and beautiful picture + sound. I had some crashes of the windows program, server survived, but I couldnt reproduce them.
When it all worked, I noticed the sides fell off this 16:9 broadcast. I went to my settings, they were on 4:3, and changed that to 16:9 . Now I dont lose side of the picture, but it all gets stretched out in vertical position: the 16:9 picture is put in a 4:3 window.
It seems silly to me that a windows application obeys this setting (I suggest to ignore it), but if it does it should do it right.

Then somehow the application crashed, and I couldnt get it working again. Then I remembered I had changed poweron value to OFF, and yes, unbelievable, but the windows application actually obeys this setting and shuts itself down when starting up :-) . Here also: ignore this setting.

After a crash I had to restart the machine, so vompclient and/or CoreAvc can crash nastily; no logs since not reproducable :-( .

Opening EPG window and pressing CTRL-R record results in a reproducable crash. Also playing old vdr-hd-recordings goes wrong, the screen is not cleared properly, only the playing bar is displayed and that's it.

In order to do more structural testing, I would implement new vompserver on my production system, but then I would loose Yaris patching functionality, and that is unwanted on my production system.
Is it somehow possible to:
1)  produce the cvs-patches and take them to Yaris-repository so we get an updated server there?
2)  same for client code needed to use new server version? I am talking about dongle code for mediamvp box, not the windows version.

That way I could integrate alpha windows in my production environment, which would improve testing / error finding...

Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on February 23, 2010, 15:38:24
QuoteFirst try didnt work, then set my h264filter to my installed CoreAVC plugin and beautiful picture + sound. I had some crashes of the windows program, server survived, but I couldnt reproduce them.
When it all worked, I noticed the sides fell off this 16:9 broadcast. I went to my settings, they were on 4:3, and changed that to 16:9 . Now I dont lose side of the picture, but it all gets stretched out in vertical position: the 16:9 picture is put in a 4:3 window.
It seems silly to me that a windows application obeys this setting (I suggest to ignore it), but if it does it should do it right.
Actually, this setting makes sense. In windows it refers to the pixel aspect ratio. If someone connects a beamer or something else in anamorphic mode, the picture will look correctly in 16:9 mode. This with the side is the setting crop, you should change it to letter box.
QuoteThen somehow the application crashed, and I couldnt get it working again. Then I remembered I had changed poweron value to OFF, and yes, unbelievable, but the windows application actually obeys this setting and shuts itself down when starting up :-) . Here also: ignore this setting.
Hmm, You are the first who mentioned this and it is there since first relese. I will change it so it will ignore this setting.

QuoteOpening EPG window and pressing CTRL-R record results in a reproducable crash.
Since I have no live TV I cannot test this, logs around this crash would be good.
QuoteAlso playing old vdr-hd-recordings goes wrong, the screen is not cleared properly, only the playing bar is displayed and that's it.
Actually the old HD recording were never supported by the plain vanilla vdr I think. Anyway they lack information in the recording format, so that I cannot identify them as HD so vomp tries to play them back as mpeg2 and this causes the lock up.
So they are just unsupported.

For the yaris version, it should be enough, if the protocoll changes in vdr.cc are proted back to the yaris client, then it should work with the new server. For the server side you can just genearte the diff from the cvs webpage and apply it to the yaris version then it should work.

Regarding the crash with CoreAvc, I need more information what happens(so may be a log or description what you see or what you have doone), you may also want to try  the decoder from the standalone filters from mediaplayer hc.




Thanks for testiing.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 23, 2010, 21:47:24
I hadnt noticed sourceforge CVS browse access, I will surely apply the changes of last weeks to Yaris so larger audience can join.

Good to know you have no live stream access, I will gather logs where possible !
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 24, 2010, 13:16:47
Pressing CTRL-R = record in epg menu results in windows error report with dialog box that ask whether to send the report to Microsoft or not. The application keeps running until you select "not send", then it ends gracefully (no remaining vomp-process).

The signature of the error is:
AppName: vomp on windows.exe AppVer: 0.0.0.0 ModName: msvcr90.dll
ModVer: 9.0.30729.1 Offset: 000518a8


The file that would be send to Microsoft contains:
<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="Vomp on Windows.exe" FILTER="GRABMI_FILTER_PRIVACY">
   <MATCHING_FILE NAME="Vomp on Windows.exe" SIZE="962560" CHECKSUM="0x22F8E96F" MODULE_TYPE="WIN32" PE_CHECKSUM="0xED0F5" LINKER_VERSION="0x0" LINK_DATE="02/22/2010 15:18:24" UPTO_LINK_DATE="02/22/2010 15:18:24" />
</EXE>
<EXE NAME="MSVCR90.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
   <MATCHING_FILE NAME="msvcr90.dll" SIZE="655872" CHECKSUM="0xA8551049" BIN_FILE_VERSION="9.0.30729.1" BIN_PRODUCT_VERSION="9.0.30729.1" PRODUCT_VERSION="9.00.30729.1" FILE_DESCRIPTION="Microsoft® C Runtime Library" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Visual Studio® 2008" FILE_VERSION="9.00.30729.1" ORIGINAL_FILENAME="MSVCR90.DLL" INTERNAL_NAME="MSVCR90.DLL" LEGAL_COPYRIGHT="© Microsoft Corporation.  All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA6621" LINKER_VERSION="0x90000" UPTO_BIN_FILE_VERSION="9.0.30729.1" UPTO_BIN_PRODUCT_VERSION="9.0.30729.1" LINK_DATE="07/29/2008 10:53:57" UPTO_LINK_DATE="07/29/2008 10:53:57" VER_LANGUAGE="Engels (Verenigde Staten) [0x409]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
   <MATCHING_FILE NAME="kernel32.dll" SIZE="1030656" CHECKSUM="0x1B46B288" BIN_FILE_VERSION="5.1.2600.5781" BIN_PRODUCT_VERSION="5.1.2600.5781" PRODUCT_VERSION="5.1.2600.5781" FILE_DESCRIPTION="DLL-bestand voor Windows NT BASE API-client" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Besturingssysteem Microsoft® Windows®" FILE_VERSION="5.1.2600.5781 (xpsp_sp3_gdr.090321-1317)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Alle rechten voorbehouden." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x101480" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5781" UPTO_BIN_PRODUCT_VERSION="5.1.2600.5781" LINK_DATE="03/21/2009 14:09:59" UPTO_LINK_DATE="03/21/2009 14:09:59" VER_LANGUAGE="Nederlands (Nederland) [0x413]" />
</EXE>
</DATABASE>



Log:
14:08:06.000437 [debug]  VDR - Have added a channel to list. 4751 1 Das Erste HD
14:08:06.000437 [debug]  VDR - Have added a channel to list. 4752 1 ZDF HD
14:08:06.000453 [debug]  VDR - RR sleep - opcode 10
14:08:06.000484 [debug]  VDR - Rxd a response packet, requestID=83, len=581
14:08:06.000484 [debug]  VDR - RR unsleep
14:08:06.000484 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000484 [debug]  VDR - RR sleep - opcode 10
14:08:06.000531 [debug]  VDR - Rxd a response packet, requestID=84, len=4215
14:08:06.000531 [debug]  VDR - RR unsleep
14:08:06.000531 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000531 [debug]  VDR - RR sleep - opcode 10
14:08:06.000562 [debug]  VDR - Rxd a response packet, requestID=85, len=2810
14:08:06.000562 [debug]  VDR - RR unsleep
14:08:06.000562 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000562 [debug]  VDR - RR sleep - opcode 10
14:08:06.000593 [debug]  VDR - Rxd a response packet, requestID=86, len=1418
14:08:06.000593 [debug]  VDR - RR unsleep
14:08:06.000593 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000593 [debug]  VDR - RR sleep - opcode 10
14:08:06.000640 [debug]  VDR - Rxd a response packet, requestID=87, len=621
14:08:06.000640 [debug]  VDR - RR unsleep
14:08:06.000640 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000640 [debug]  VDR - RR sleep - opcode 10
14:08:06.000687 [debug]  VDR - Rxd a response packet, requestID=88, len=1265
14:08:06.000687 [debug]  VDR - RR unsleep
14:08:06.000687 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000687 [debug]  VDR - RR sleep - opcode 10
14:08:06.000703 [debug]  VDR - Rxd a response packet, requestID=89, len=171
14:08:06.000703 [debug]  VDR - RR unsleep
14:08:06.000703 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000703 [debug]  Boxx - Construct, now 34
14:08:07.000312 [debug]  VDR - RR sleep - opcode 10
14:08:07.000312 [debug]  VDR - Rxd a response packet, requestID=90, len=2539
14:08:07.000312 [debug]  VDR - RR unsleep
14:08:07.000312 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000312 [debug]  VDR - RR sleep - opcode 10
14:08:07.000343 [debug]  VDR - Rxd a response packet, requestID=91, len=37
14:08:07.000343 [debug]  VDR - RR unsleep
14:08:07.000343 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000343 [debug]  VDR - RR sleep - opcode 10
14:08:07.000390 [debug]  VDR - Rxd a response packet, requestID=92, len=32
14:08:07.000390 [debug]  VDR - RR unsleep
14:08:07.000390 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000390 [debug]  VDR - RR sleep - opcode 10
14:08:07.000406 [debug]  VDR - Rxd a response packet, requestID=93, len=581
14:08:07.000406 [debug]  VDR - RR unsleep
14:08:07.000406 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000406 [debug]  VDR - RR sleep - opcode 10
14:08:07.000453 [debug]  VDR - Rxd a response packet, requestID=94, len=2810
14:08:07.000453 [debug]  VDR - RR unsleep
14:08:07.000453 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000453 [debug]  VDR - RR sleep - opcode 10
14:08:07.000500 [debug]  VDR - Rxd a response packet, requestID=95, len=1460
14:08:07.000500 [debug]  VDR - RR unsleep
14:08:07.000500 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000500 [debug]  VDR - RR sleep - opcode 10
14:08:07.000546 [debug]  VDR - Rxd a response packet, requestID=96, len=523
14:08:07.000546 [debug]  VDR - RR unsleep
14:08:07.000546 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000609 [debug]  Timers - Starting set timer 1
14:08:07.000609 [debug]  Timers - Timer set for 015B93D0 ref 1
14:08:07.000609 [debug]  Boxx - Destruct, now 33
14:08:07.000609 [debug]  BoxStack - add called
14:08:07.000609 [debug]  BoxStack - Locked for add
14:08:07.000609 [debug]  BoxStack - Unlocked for add
14:08:07.000609 [debug]  BoxStack - Update called
14:08:07.000609 [debug]  BoxStack - Locked for update
14:08:07.000609 [debug]  BoxStack - Unlocked for update
14:08:10.000093 [debug]  VDR - Sending KA packet
14:08:10.000109 [debug]  VDR - Rxd correct KA reply
14:08:16.000125 [debug]  VDR - Sending KA packet
14:08:16.000203 [debug]  VDR - Rxd correct KA reply
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 24, 2010, 13:54:51
For people who also want to test Martens HD version for vomp for windows, but dont want to say goodbye to Yaris functionality, I have made some new sources.

vompserver: the source code for vompserver, this is the Yaris version, to which I have added the cvs-changes of the last 6 months; also I added my patch for PIN-plugin awareness, when USE_PINPLUGIN is not set this code is ignored.
client: the source code for the dongle, this is the Yaris version, to which I have added the cvs-changes of the last 6 months, and also the hdtv2.patch of Marten.
vomp-dongle: the dongle object code; too large for this board, so here: http://rapidshare.com/files/355178923/vomp-dongle-0.3.1-2-Yaris-HD.gz (http://rapidshare.com/files/355178923/vomp-dongle-0.3.1-2-Yaris-HD.gz)

Enjoy!
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on February 24, 2010, 15:52:35
@dingo35
Thanks for the logs, unfortunetely there is no hint for me in it.
Since I have no liveTV, I will look at the source code, if I get an idea what is going wrong.

Just a question was this bug also present in older vomp for windows versions. (I am asking since I have switched to a newer C++ version for the new builds).

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 24, 2010, 15:59:26
I dont recall it was present in older windows version, I will check but need to downgrade then (cannot do that right now, TV clients are active now :-) ).
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: rdoac on February 24, 2010, 18:25:50
@dingo35

Can you create a binary dongle for hardware mvp's from this code?

I can't get a dev env. to compile anymore..
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 24, 2010, 18:31:25
The rapidshare link points to the dongle binary. Object code = binary.
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: rdoac on February 24, 2010, 18:47:23
Been trying to download it for the last half hour... They're busy and I'm not allowed to download it unless I pay up..

Still not working after two hours of continuous tries..

Can we upload this somewhere else?
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 25, 2010, 11:18:11
The client code I posted has not processed hdtv2.patch from Marten correctly. I applied it and mode two modifications:
-changed abs function call to floating point to fabs, as code wont compile when trying to apply abs to floating point
-added countPictureHeaders definition in Pespacket class definition.

New client source code attached, dongle binary uploaded:
http://rapidshare.com/files/355624021/vomp-dongle-0.3.1-2-Yaris-HD2.bz2 (http://rapidshare.com/files/355624021/vomp-dongle-0.3.1-2-Yaris-HD2.bz2)

Please dont complain to me about rapidshare, downloading in off-peek hours just works fine for free users. Better ask the admin of this board to increase the upload limit from 2000K to 2500K, since compressed dongle is slightly over 2000k ....:-(
Also dont ask me to function als your personal upload center...

Hondans, perhaps you could upload these versions to your ftp server for all's convenience?
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on February 25, 2010, 11:26:31
Marten, at testing some strange behaviour of the "normal" client (MVP, not windows):

Selecting Main menu option TV gives channels list, some HD channels do not appear in the list (wouldnt expect that that had already been taken care of), and some do ?!?

My channels.conf:
:HDTV
NederlandHD;Canaldigitaal:11856:vC56M2O35S1:S23.5E:27500:517=27:90=dut:36:100:7035:3:3208:0
Nederland 3 HD;Canaldigitaal:12129:vC56M2O35S1:S23.5E:27500:520=27:96:40:100:20950:3:3222:0
RTL4 HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:514=27:84=dut:34:D03,D70,100:7020:3:3208:0
een HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:516=27:88=dut:37:100:7030:3:3208:0
Discovery HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:512=27:0;80=dut:43:D03,D70,100:7010:3:3208:0
NGC HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:513=27:0;82=dut:0:100:7015:3:3208:0
BBC HD;BSkyB:10847:vC56M2O0S1:S28.2E:22000:5500=2:5502=NAR;5501=eng:5503:0:6940:2:2050:0
History Channel HD;skylink:12110:hC910M2O20S1:S23.5E:27500:4002=2:4322=hun;4162=cze,4242=eng:0:D70,D03,100:5042:3:3221:0
Eurosport HD;skylink:12110:hC910M2O20S1:S23.5E:27500:4001=2:4161=cze,4321=hun,4641=dut;4241=eng:0:D70,D03,100:5041:3:3221:0
Einsfestival HD;ARD:12421:hC34M2O0S0:S19.2E:27500:1601=27:1602=deu;1606=deu:0:0:28396:1:1201:0
ANIXE HD;BetaDigital:11303:hC23M5O35S1:S19.2E:22000:255=2:0;259=deu:0:0:4900:1:1007:0
arte HD;ZDFvision:11361:hC23M5O35S1:S19.2E:22000:6210=27:6221=deu,6222=fra;6220=deu:6230:0:11120:1:1011:0
ORF1 HD;ORF:11303:hC23M5O35S1:S19.2E:22000:1920=27:1921=deu,1922=eng;1923=deu:1925:D05,1702,1833,648,D95,9C4:4911:1:1007:0
BravaHDTV;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:515=27:0;86=dut:0:D03,D70,100:7025:3:3208:0
MTVNHD;MTV Networks Europe:11778:vC34M2O0S0:S19.2E:27500:2000=27:2001=eng;2002=eng:0:D00,100,500,1811:28601:1:1068:0
MTVNHD;MTV Networks Europe:11778:vC34M2O0S0:S19.2E:27500:2000=27:2001;2002=eng:0:D00,100,500,1810,1811:28600:1:1068:0
ASTRA HD Demo;DVL.TV:10862:hC56M2O0S0:S23.5E:22000:1011=2:1013=eng:0:0:5000:3:3111:0
ASTRA HD+;BetaDigital:11303:hC23M5O35S1:S19.2E:22000:511=2:0;515=deu:0:0:4901:1:1007:0
Film 1 HD;CANALDIGITAAL:12129:vC56M2O35S1:S23.5E:27500:521=27:98;111=dut:0:100:20955:3:3222:0
Sport 1 HD;Canaldigitaal:12129:vC56M2O35S1:S23.5E:27500:522=27:100:42:100:20960:3:3222:0
HD-Test ARD ZDF;IRT:11361:hC23M5O35S1:S19.2E:22000:6410=2:6420=deu;6421=deu,6422=Ori:6430:0:11140:1:1011:0


Displayed in the list are:
BBC HD, History Channel HD, Eurosport HD, ANIXE HD, ASTRA HD Demo, ASTRA HD+, HD_Test ARD ZDF . The other ones are blanked (expected behaviour, since HD on SD device will go wrong).
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on February 25, 2010, 15:31:52
Well the current code detects =27 in  the channels.conf, which means h264 is used as codec. mpeg2 HD (=2 same as SD), which I did not know that is still used has no feature in the channels conf, that distigish it from SD, so I am unable to detect it.
Sorry.... The only way would be to scan inside incoming data, but for that you have to already tune into the channel.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: hondansx on February 25, 2010, 20:17:43
Quote from: dingo35 on February 25, 2010, 11:18:11
The client code I posted has not processed hdtv2.patch from Marten correctly. I applied it and mode two modifications:
-changed abs function call to floating point to fabs, as code wont compile when trying to apply abs to floating point
-added countPictureHeaders definition in Pespacket class definition.

New client source code attached, dongle binary uploaded:
http://rapidshare.com/files/355624021/vomp-dongle-0.3.1-2-Yaris-HD2.bz2 (http://rapidshare.com/files/355624021/vomp-dongle-0.3.1-2-Yaris-HD2.bz2)

Please dont complain to me about rapidshare, downloading in off-peek hours just works fine for free users. Better ask the admin of this board to increase the upload limit from 2000K to 2500K, since compressed dongle is slightly over 2000k ....:-(
Also dont ask me to function als your personal upload center...

Hondans, perhaps you could upload these versions to your ftp server for all's convenience?


Hi Dingo,

the attachment is broken and rapidshare is very busy.
Could you send both to HondaNSX@Gmx.de. I will upload it to my ftp.

THK,
Walter
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: dingo35 on March 21, 2010, 11:22:11
I tried to install the "hdtest2" version of vomp for windows on my old laptop. The vompwin 0.3.0 starts ok at this laptop (not sure about sound and picture because I have no compatible vompserver running at the moment).

At first I got the message "This application is not configured correctly; reinstall" (not the literal version since my local language is installed), this could be solved by installing the C++ 2008 redistributable .

Now, when I start the exe, you can see a window is drawn, but then immediately it is deleted and vomp exits. Redirecting output gives an empty file. Disabling audio and video acceleration does not help. Changing video/audio codec does not help (of course, it doesnt even get to draw the main menu).

Perhaps my directX is not entirely up to par, I did my standard "D3DXDLLFebruary29\D3DX9_29_dll_update"  routine, but perhaps new HD version has higher requirements to directX? Or is something else going wrong? Dxdiag gives good results on directdraw and direct3d ...

Thanks!
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on March 21, 2010, 16:57:47
Hi,
yes this are probably the Visual C++ 2008 runtime libs. They can be somewhere downloaded from Microsoft.
I am using now the DirectX SDK from November 2008, so the runtime has to be newer.
The reason for this is that I am now developping on a newer computer with newer software.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on April 26, 2010, 01:15:07
Hi,
I hope some reads this.
I need one information about 720p recordings at 50 fps.
Is the navigation working correctly?
I am not sure if I have interpreted vdrs frame counting correctly.
So can anyone comment on this?

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on April 26, 2010, 01:57:12
Ok I tested it myself on a one minute sample it was wrong!
new test version for windows is attached.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: carsten on April 26, 2010, 06:58:01
Hi Marten,

I will have a look on it this evening. BTW: any changes lately on the plugin? Where could I get the latest source of it? In this thread?
Or can I still use that one you once mailed me...

Thanks,
Carsten.
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on April 26, 2010, 15:24:23
Quote. BTW: any changes lately on the plugin? Where could I get the latest source of it? In this thread?
Or can I still use that one you once mailed me...
Not really, I can not remember any changes since then, but may be it needs to be recompiled against newer servers. Anyway the cvs is uptodate in the server side.

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: carsten on April 29, 2010, 07:25:24
Hi,

didn't have a lot of time to test. I think I have mixed versions of servers on different machines that I first have to
sort, maybe tonight. But it did work. By navigation you mean jump/spool?

BR,
Carsten.
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: MartenR on April 29, 2010, 15:09:33
Yes, I mean jumping inside the recording, the function for deteriming the current position after some minutes of playback was wrong for 720p

Marten
Title: Re: Volunteers for pre-alpha test of HDTV playback needed
Post by: carsten on April 30, 2010, 18:33:19
Well, it didn't work very well. But it does with no version of the client I have here from you. I guess, I have to
check the server plugin. I use vdr 1.7.14 currently.

I sent you some infos by mail.

BR,
Carsten.