Re: [vdr] VDR Development

2008-09-07 Thread Clemens Kirchgatterer
Laz [EMAIL PROTECTED] wrote:

 I have always been impressed with the quality of the source code for
 vdr. It's the first proper C++ application I've had course to look
 through in any detail (many, many years of pure C behind me, though!)
 and I've pretty much learned all of the C++ I know from Klaus's
 well-laid out source code!

i, by no means, want to question klaus' competence as a coder, but to
call VDR proper C++ sounds really strange to me. i can accept the
source formatting as being a thing of personal taste, maybe even
hungarian notation, something i personally find unbearable and wrong
from the ground up, but the refusal to use the STL in a C++ project
leaves me dumbfounded.

i CAN absolutly understand why klaus codes VDR as he does. writing a
string class or a linked list is fun sometimes and as long as VDR stays
a one man show it is only up to him to decide. keeping the closed
development process makes things much easier for him and avoids
long arguments about personal preferences. if i had an GPL project that
size, i would probably do the same. do i like the way VDR is developed?
hell, no! nevertheless it is, what it is. a very usable and stable
program for watching, recording and replaying TV shows with a dvb card.

 If a new feature is needed, a lot can be achieved with plugins, or
 create a patch and forward on to Klaus and the list.

maintaining patches over multiple revisions in a coding style that is
orthogonal to your own, waiting for it to get eventually merged
upstream some day, is not something many peaople like.

just my 2 cents ...
clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-2

2008-09-07 Thread Klaus Schmidinger
VDR maintenance patch 1.6.0-2 is now available at

  ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-2.diff

This is a 'diff' against version 1.6.0-1 (which is the official
version 1.6.0, patched with 
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff).


Small fixes to the officially released VDR versions will be first
made available as maintenance patches in the Developer directory,
so that they can be reviewed and tested before a new official
release is published.

So please apply the above patch(es) and report whether it works (or
if it causes any new problems).


This version is binary compatible to the previous one, so plugins
don't need to be recompiled.


The changes since version 1.6.0-1:

- Updated the Italian OSD texts (thanks to Diego Pierotto).
- The SVDRP signon message now indicates the character encoding in use, as in
   220 video SVDRP VideoDiskRecorder 1.7.1; Fri May  2 16:17:10 2008; 
ISO-8859-1.
   This may be useful for instance for external tools that provide EPG data, so 
that
   they can correctly encode the strings.
- No longer calling FcFini() to avoid problems with older (broken) versions of
   fontconfig (suggested by Edgar Toernig).
- Updated the sources.conf file (thanks to Oleg Roitburd).
- Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander 
Rieger).
- Fixed a problem with calling isyslog() from within the SignalHandler() (thanks
   to Udo Richter).
- Replaced the Finnish language code smi with suo (thanks to Rolf 
Ahrenberg).
- Fixed wrong value for TableIdBAT in libsi/si.h (thanks to Winfried Köhler).
- Removed unneeded include files linux/dvb/dmx.h und time.h from remux.h
   (reported by Tobias Grimm).

Have fun!

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] [ANNOUNCE] VDR developer version 1.7.1

2008-09-07 Thread Klaus Schmidinger
VDR developer version 1.7.1 is now available at

  ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.1.tar.bz2

A 'diff' against the previous version is available at

  ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0-1.7.1.diff



WARNING:


This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.



This version marks the first step towards using TS (Transport Stream) as
recording format. It does this by switching the Transfer Mode to TS and
introducing all the necessary cDevice and cPlayer functions to handle TS.
Actual recording is still done in PES, though.
This should provide a reasonable developing and testing environment for
HDTV device plugins to prepare for replaying TS.

There appears to be a problem with replaying the payload from TS packets
on Full-Featured DVB cards. On some channels this works rather fine (with
only very small glitches from time to time), while on other channels there
are heavy glitches and sometimes even the audio goes mute.
My initial approach to replaying TS on FF cards was to simply strip the
TS header and send the payload to the usual PlayVideo() and PlayAudio()
functions, since the driver itself examines the data and assembles the
2KB PES packets it sends to the hardware. Since the FF cards can replay
the TS data as it comes in from the transponder, my assumption was that
the same should be possible in Transfer Mode.
But maybe there is something wrong with this assumption?
Could this be a driver problem?
I don't think that simply throwing memory at the problem is the solution.
Any thoughts?


The changes since version 1.7.0:

- Adapted the tuning code to the new DVBFE_SET_DELSYS API (thanks to Reinhard 
Nissl).
   VDR now uses the driver from http://jusst.de/hg/multiproto_plus.
- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Removed obsolete $(NCURSESLIB) from the Makefile.
- Implemented handling the standard component descriptor for AC3 (stream=4), as 
it
   will soon be used by the German ARD channels (thanks to Michael Pennewiß for
   advance information about this change). The previously used Premiere pseudo
   standard (stream=2, type=5) still works, but has apparently been wrongfully 
used
   by broadcasters from the beginning.
- Added missing description of the 'S' channel parameter to vdr.5 (reported by
   Reinhard Nissl).
- The SVDRP signon message now indicates the character encoding in use, as in
   220 video SVDRP VideoDiskRecorder 1.7.1; Fri May  2 16:17:10 2008; 
ISO-8859-1.
   This may be useful for instance for external tools that provide EPG data, so 
that
   they can correctly encode the strings.
- No longer calling FcFini() to avoid problems with older (broken) versions of
   fontconfig (suggested by Edgar Toernig).
- Removed the compile time option VFAT to allow users of precompiled binary
   distributions to have full control over whether or not to use the --vfat 
option
   at runtime (suggested by Michael Nork).
- First step towards switching to TS (Transport Stream) as recording format:
   + The new function cDevice::PlayTs() is used to play TS packets.
   + The new functions cDevice::PlayTsVideo() and cDevice::PlayTsAudio()
 are used to play video and audio TS packets, respectively.
   + The new function cAudio::PlayTs() is used to play audio TS packets.
   + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that 
precedes
 the TS data in Transfer Mode.
   + The new class cPatPmtParser is used by cDevice to parse the PAT/PMT data 
in a
 TS in order to find out which streams it contains.
   + The new class cTsToPes is used to convert TS packets to a PES packet.
   + cTransfer no longer uses cRemux, and doesn't run a separate thread any 
more.
 It just generates a PAT/PMT and sends all received TS packets to the 
primary
 device's PlayTs().
   + Live subtitle display no longer uses a ring buffer and separate thread.
   + cPesAssembler has been removed. Old VDR recordings only contain complete 
PES
 packets.
   + Since a TS needs to have a PAT/PMT, which requires the video stream type to
 be explicitly given, the format of the VPID field in the channels.conf file
 and the SVDRP commands NEWC/MODC/LSTC has been extended. The video stream 
type
 now follows the VPID and optional PPID, separated by an '=' sign.
- Updated the sources.conf file (thanks to Oleg Roitburd).
- Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander 
Rieger).
- Fixed a problem with calling isyslog() from within the SignalHandler() (thanks
   to Udo Richter).
- Replaced the Finnish language code smi with suo (thanks to Rolf 
Ahrenberg).
- Fixed wrong value for TableIdBAT in libsi/si.h (thanks to Winfried Köhler).
- Errors in config files no longer keep VDR from starting.
- Removed unneeded include files linux/dvb/dmx.h und time.h from remux.h
   (reported by Tobias 

Re: [vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-2

2008-09-07 Thread Thomas Creutz
Klaus Schmidinger schrieb:
 VDR maintenance patch 1.6.0-2 is now available at
   
Thanks :-)

Have a nice day!

Thomas

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1

2008-09-07 Thread Gregoire Favre
On Sun, Sep 07, 2008 at 12:11:35PM +0200, Klaus Schmidinger wrote:

 This version marks the first step towards using TS (Transport Stream) as
 recording format. It does this by switching the Transfer Mode to TS and
 introducing all the necessary cDevice and cPlayer functions to handle TS.
 Actual recording is still done in PES, though.
 This should provide a reasonable developing and testing environment for
 HDTV device plugins to prepare for replaying TS.

:-)

Thank you very much !!!

I'll be trying some other ~VDR clone~ because of the lack of TS in
vdr, but for me they are all *censored*...

It's great to have this one, thank you very much for all your great work !!!
-- 
Grégoire FAVRE  http://gregoire.favre.googlepages.com  http://www.gnupg.org
   http://picasaweb.google.com/Gregoire.Favre

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Clemens Kirchgatterer
Lauri Tischler [EMAIL PROTECTED] wrote:

 Switching to MythTV is *not* a solution to anything. MythTV is slow
 huge, kitchen sink where nothing really works.

maybe s/MythTV/XBMC/g ?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development (Number of users)

2008-09-07 Thread Helmut Auer
Hi
 On 09/05/08 18:38, VDR User wrote:
   
 ...  Seeing how
 many people have already left VDR, it's already happening!  :(
 

 I have no idea how many people actually use VDR, but you apparently
 have some solid numbers on how many people dropped VDR.
 Do you mind sharing these numbers?

   
I do not have exact numbers but a rough guess would tell me that about 
5-10 K people are using Gen2VDR.
And thats surely not the main VDR Distribution ;)

-- 
Helmut Auer, [EMAIL PROTECTED] 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1

2008-09-07 Thread Udo Richter
The sky plugin does not compile any more, because it uses PID_MASK_HI 
which got renamed to TS_PID_MASK_HI. Patch is attached. A similar 
problem strikes for streamdev.



Cheers,

Udo

--- vdr-1.7.1-old/PLUGINS/src/sky/sky.c 2008-09-07 13:34:53.0 +0200
+++ vdr-1.7.1/PLUGINS/src/sky/sky.c 2008-09-07 13:38:23.0 +0200
@@ -160,12 +160,12 @@
  Data = tsBuffer-Get();
  if (Data) {
 // insert the actual PIDs:
-int Pid = (((uint16_t)Data[1]  PID_MASK_HI)  8) | Data[2];
+int Pid = (((uint16_t)Data[1]  TS_PID_MASK_HI)  8) | Data[2];
 if (Pid == DUMMYAPID)
Pid = apid;
 else if (Pid == DUMMYVPID)
Pid = vpid;
-Data[1] = ((Pid  8)  0xFF) | (Data[1]  ~PID_MASK_HI);
+Data[1] = ((Pid  8)  0xFF) | (Data[1]  ~TS_PID_MASK_HI);
 Data[2] = Pid  0xFF;
 }
  return true;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1

2008-09-07 Thread Klaus Schmidinger
On 09/07/08 13:48, Udo Richter wrote:
 The sky plugin does not compile any more, because it uses PID_MASK_HI 
 which got renamed to TS_PID_MASK_HI. Patch is attached.

Thanks.
At some point I guess I should just drop the sky plugin, since it's
of no real use any more...

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1

2008-09-07 Thread Klaus Schmidinger
On 09/07/08 13:55, Jelle De Loecker wrote:
 Multiproto_plus is quite outdated, Manu (the maintainer) has done a 
 bunch of updates on the original multiproto tree 
 (http://jusst.de/hg/multiproto)
 He even added support for the old API (yay) and merged the latest V4L 
 tree with it.
 
 Basically, it compiles and it just works with everything :)

Thanks. I forgot to update and verify that - I'm still using the one
from http://jusst.de/hg/multiproto_plus, dated 2008-04-13 (was just too
lazy to recompile a newer one).

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] DVB API Wrapper for VDR-1.7.1

2008-09-07 Thread Udo Richter
Hi list,


A minimal update to the DVB API wrapper for VDR 1.7.1 is available on my 
web site.

http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper
http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1

2008-09-07 Thread Jelle De Loecker
Multiproto_plus is quite outdated, Manu (the maintainer) has done a 
bunch of updates on the original multiproto tree 
(http://jusst.de/hg/multiproto)
He even added support for the old API (yay) and merged the latest V4L 
tree with it.


Basically, it compiles and it just works with everything :)

/Met vriendelijke groeten,/

*Jelle De Loecker*
Kipdola Studios - Tomberg


Klaus Schmidinger schreef:

VDR developer version 1.7.1 is now available at

  ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.1.tar.bz2

A 'diff' against the previous version is available at

  ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0-1.7.1.diff



WARNING:


This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.



This version marks the first step towards using TS (Transport Stream) as
recording format. It does this by switching the Transfer Mode to TS and
introducing all the necessary cDevice and cPlayer functions to handle TS.
Actual recording is still done in PES, though.
This should provide a reasonable developing and testing environment for
HDTV device plugins to prepare for replaying TS.

There appears to be a problem with replaying the payload from TS packets
on Full-Featured DVB cards. On some channels this works rather fine (with
only very small glitches from time to time), while on other channels there
are heavy glitches and sometimes even the audio goes mute.
My initial approach to replaying TS on FF cards was to simply strip the
TS header and send the payload to the usual PlayVideo() and PlayAudio()
functions, since the driver itself examines the data and assembles the
2KB PES packets it sends to the hardware. Since the FF cards can replay
the TS data as it comes in from the transponder, my assumption was that
the same should be possible in Transfer Mode.
But maybe there is something wrong with this assumption?
Could this be a driver problem?
I don't think that simply throwing memory at the problem is the solution.
Any thoughts?


The changes since version 1.7.0:

- Adapted the tuning code to the new DVBFE_SET_DELSYS API (thanks to Reinhard 
Nissl).
   VDR now uses the driver from http://jusst.de/hg/multiproto_plus.
- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Removed obsolete $(NCURSESLIB) from the Makefile.
- Implemented handling the standard component descriptor for AC3 (stream=4), as 
it
   will soon be used by the German ARD channels (thanks to Michael Pennewiß for
   advance information about this change). The previously used Premiere pseudo
   standard (stream=2, type=5) still works, but has apparently been wrongfully 
used
   by broadcasters from the beginning.
- Added missing description of the 'S' channel parameter to vdr.5 (reported by
   Reinhard Nissl).
- The SVDRP signon message now indicates the character encoding in use, as in
   220 video SVDRP VideoDiskRecorder 1.7.1; Fri May  2 16:17:10 2008; 
ISO-8859-1.
   This may be useful for instance for external tools that provide EPG data, so 
that
   they can correctly encode the strings.
- No longer calling FcFini() to avoid problems with older (broken) versions of
   fontconfig (suggested by Edgar Toernig).
- Removed the compile time option VFAT to allow users of precompiled binary
   distributions to have full control over whether or not to use the --vfat 
option
   at runtime (suggested by Michael Nork).
- First step towards switching to TS (Transport Stream) as recording format:
   + The new function cDevice::PlayTs() is used to play TS packets.
   + The new functions cDevice::PlayTsVideo() and cDevice::PlayTsAudio()
 are used to play video and audio TS packets, respectively.
   + The new function cAudio::PlayTs() is used to play audio TS packets.
   + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that 
precedes
 the TS data in Transfer Mode.
   + The new class cPatPmtParser is used by cDevice to parse the PAT/PMT data 
in a
 TS in order to find out which streams it contains.
   + The new class cTsToPes is used to convert TS packets to a PES packet.
   + cTransfer no longer uses cRemux, and doesn't run a separate thread any 
more.
 It just generates a PAT/PMT and sends all received TS packets to the 
primary
 device's PlayTs().
   + Live subtitle display no longer uses a ring buffer and separate thread.
   + cPesAssembler has been removed. Old VDR recordings only contain complete 
PES
 packets.
   + Since a TS needs to have a PAT/PMT, which requires the video stream type to
 be explicitly given, the format of the VPID field in the channels.conf file
 and the SVDRP commands NEWC/MODC/LSTC has been extended. The video stream 
type
 now follows the VPID and optional PPID, separated by an '=' sign.
- Updated the sources.conf file (thanks to Oleg Roitburd).
- Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander 
Rieger).
- Fixed a 

Re: [vdr] VDR Development (Number of users)

2008-09-07 Thread Hans Werner

 Original-Nachricht 
 Datum: Sun, 07 Sep 2008 13:31:22 +0200
 Von: Helmut Auer [EMAIL PROTECTED]
 An: VDR Mailing List vdr@linuxtv.org
 Betreff: Re: [vdr] VDR Development (Number of users)

 Hi
  On 09/05/08 18:38, VDR User wrote:

  ...  Seeing how
  many people have already left VDR, it's already happening!  :(
  
 
  I have no idea how many people actually use VDR, but you apparently
  have some solid numbers on how many people dropped VDR.
  Do you mind sharing these numbers?
 

 I do not have exact numbers but a rough guess would tell me that about 
 5-10 K people are using Gen2VDR.
 And thats surely not the main VDR Distribution ;)

How did you calculate that number?

-- 
Release early, release often.

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development (Number of users)

2008-09-07 Thread Helmut Auer
Hi Hans

 How did you calculate that number?

   
By counting the downloads of fixes (which are only made once with the 
internal update script).
And I guess that some users will never update a running system ...

-- 
Helmut Auer, [EMAIL PROTECTED] 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread VDR User
Glad to see some discussion taking place here..  It's quite funny some
people think hdtv, h264, and other standard or
quickly-becoming-standard things are bleeding edge.  You've got to
be kidding!  Also, to put it simply, it's ignorant to think there's
nothing wrong.  When many VDR users are abandoning the software for
other more capable options, why do you think that is?  Because it
lacks support for -current needs-, and for that matter lacks support
for even some of the most basic stuff!  You can bash MythTV all you
want but it doesn't change the fact that people are leaving VDR in
favor of it.  I agree that MythTV is big, poorly designed in some
respects, and generally a pain to get running...but that obviously
isn't stopping people.

Stability is a great thing to have, but so is support for basic needs.
 And where is the rule that says you can't have both?  Just like code
is improved, so can the processes which generate the code and bring it
together.  It seems like some are taking this discussion as an attack
on Klaus and that is NOT the case.  It's absurd this has to be pointed
out -again- but the intentions are only to improve VDR's development,
features (even some of the most basic), and ensure that VDR will not
become obsolete because it isn't keeping pace with the rest of the
world.  Ignoring basic needs simply because they don't apply to you
isn't exactly the picture of great design or development now is it?
The 'as long as it works here, everyone else can stay in the cold'
attitude has never resulted in anything positive.  Nobody should ever
say sorry for the idea of taking a good product and making it better!

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1

2008-09-07 Thread Klaus Schmidinger
On 09/07/08 16:48, Luca Olivetti wrote:
 El Sun, 07 Sep 2008 12:11:35 +0200
 Klaus Schmidinger [EMAIL PROTECTED] escribió:
 t.
+ cTransfer no longer uses cRemux, and doesn't run a separate
 thread any more. It just generates a PAT/PMT and sends all received
 TS packets to the primary device's PlayTs().
 
 Just asking before I try to recompile everything, but does it mean that
 output plugins (xine, dxr3, etc.) have to be rewritten?

They can implement cDevice::PlayTs() if they need to handle the TS
packets by themselves. Otherwise the TS payload will be extracted from
the TS, assembled to complete PES packets and delivered via the existing
PlayVideo() and PlayAudio() functions.

I assume HDTV output plugins will want to handle the TS by themselves - that's
the whole point in switching to TS.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Halim Sahin
FULLACK Oliver,
You have forgotten the point:

* help to add dvb-s2 support into main kernel!!

Danke 
Gruß
Halim


On So, Sep 07, 2008 at 05:08:37 +0200, Oliver Endriss wrote:
 Guys, I can't stand this blabla any longer.
 
 Klaus stated clearly how he wants to do VDR development, and he has the
 right to do it his way! No matter whether you like it or not!
 
 My suggestion for those who are unhappy with the current situation:
 0. Stop this discussion.
 1. Read the GPL.
 2. Understand the GPL.
 2. Clone the existing VDR code.
 3. Give it a new name to make clear, that it is not VDR.
 4. Make it better (if you can).
 5. Last but not least: Maintain it for 8 years or longer.
 
 Oliver
 
 -- 
 
 VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
 
 
 ___
 vdr mailing list
 vdr@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

-- 
Halim Sahin
E-Mail: 
halim.sahin (at) t-online.de

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Bruno

 Just a couple of observations on this discussion.. I see that some advocates 
of VDR repository are calling Myth project 'bloated','kitchen sink', 'not 
alternative to VDR'…, but, at the same time, they are pushing VDR project the 
same way, which will virtually transform VDR into sort of Myth-2, because the 
most important advantages of VDR can persist only as long as Klaus has fun, 
hence motivation to continue development of his great project. And he clearly 
stated that collective development way is not appropriate to his own 
development style and his view on how VDR project should be managed.   Well 
ok, we all expect open source development to be driven by personal need, but 
it is the combination of code created by many people who each had their own 
needs which is where the magic lies. Again, why do we need Myth-2 if we already 
have Myth-1 incorporating all the mentioned magic..   A well maintained 
bazaar-style project is generally thought to produce much higher quality code. 
Look at the Linux kernel and compare it to any other operating system. Linux 
kernel development is a good example of the fact that greatness of a project is 
dependant in the first place on the person who leads the project. Importance of 
the chosen tool (community tree, or something else) is in the  second place. 
Collective development via repository, or single coder ruling - this is just a 
tool that the project leaders have fun and convenience to use for their 
projects. A lot of projects use community tree as their tool of development, 
but it doesn’t necessarily guarantee to them so high level of appreciation that 
Linux kernel has, for example..   
_
Invite your mail contacts to join your friends list with Windows Live Spaces. 
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] Subtitles not shown after language change

2008-09-07 Thread Tero Siironen
Hi,

I noticed a problem with multi-language broadcast with subtitles or  
actually playback of recording of that (I didn't watch it in live).  
The clip is mainly having swedish audio, but during the interviews  
audio is finnish. However audio track seems to marked as swedish only.  
During the swedish audio the clip has finnish subtitles and vice  
versa. But during the playback when finnish subtitles should be shown  
again after swedish, they will not appear. Only way to fix that is to  
stop the playback and press play again and then the finnish subtitles  
are shown again.

I noticed that subtitle menu shows that actually finnish subtitles  
might be in swedish track for a while. But still, if I stop and then  
continue the playback, VDR shows the subtitles, so I'm not sure where  
the problem is.

I uploaded the 100MB sample clip to here: 
http://rapidshare.com/files/143391850/Sportmagasinet.tgz.html

My system consists from VDR 1.6.0-1 on FC4, TechnoTrend DVB-C FF  
2.1+Satelco DVB-C budget. Default languages are set as Finnish,  
Swedish and English in that order for subtitles and Finnish, English,  
Swedish for audio.


-- 
Tero

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Clemens Kirchgatterer
Oliver Endriss [EMAIL PROTECTED] wrote:

 Guys, I can't stand this blabla any longer.

why do you read the blabla then and even bother feeding the thread?
please be so tolerant and let people discuss VDR related topics on the
vdr mailing list. thank you.

 Klaus stated clearly how he wants to do VDR development, and he has
 the right to do it his way! No matter whether you like it or not!

so what?

 My suggestion for those who are unhappy with the current situation:
 0. Stop this discussion.
 1. Read the GPL.
 2. Understand the GPL.
 2. Clone the existing VDR code.
 3. Give it a new name to make clear, that it is not VDR.
 4. Make it better (if you can).
 5. Last but not least: Maintain it for 8 years or longer.

thank you for aducating us in forking a GPL project.

SCNR ...
clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Georg Acher
On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote:
 FULLACK Oliver,
 You have forgotten the point:
 
 * help to add dvb-s2 support into main kernel!!

Which one?

SCNR :-)

I also don't think that a vdr-repository would help in the development
speed. Either the whole development procedure needs to be changed (more
maintainer with KLS's approval) or it has no advantage compared to the
.tgz-distribution.

But I think the repository stuff is only marginal. The design itself
matters. When looking at the experiences at Reel, there are some things to
be considered in the (far) future of vdr 2.0:

- vdr has grown/evolved since 2000, but is still based in its design on the FF
card and its capabilities. There are now different signal source setups
(LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the
NetCeiver, and not forgetting the IPTV variants), various output types and
devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a
PC-based STB should be able to do (playback of other media, home
automatisation, etc.).

- It allows no real server/client distinction. It is quite common to have a
real file server somewhere in the house, but it's hard to get a vdr running
on it and viewing on other clients. Even the recordings sharing of two vdrs
is not that easy (touch update here and there...). One of the main
advantages of Unix was resource sharing and distribution in heterogenous
networks (like X over network), but vdr is currently focused only on its
platform.

- The current plugin concept allows only a very limited access or
modfications in the core behaviour. At least without core patches...

- Based on the long evolution history, vdr IMO also has some design
problems. Every object interacts with each other, I'm personally lost in the
inheritance-graph of dozens of identically named
Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is
a bit fat ;-) This makes it hard for newcomers and potential contributors. I
guess that there are only very few people that actually know what is going
on in the device/devbdevice/remux/libsi-core.

I still favour vdr over mythTV or MCE, because their neglect the TV side.
But we have to face it: Radio is dying already. Old fashioned TV over
antenna is also getting more and more unimportant and is merged with other
data sources (IPTV, internet radio, podcasts, ...). Full convergence is no
if, it's a when.

So, the main discussion topic should be: What is needed for a future-proof
design? It is not about XML or SQL or other hype buzzwords, it's about the
overall design and how individual modules/plugins interact with each other.

Just my EUR0.01...

-- 
 Georg Acher, [EMAIL PROTECTED] 
 http://www.lrr.in.tum.de/~acher
 Oh no, not again ! The bowl of petunias  

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread VDR User
On Sun, Sep 7, 2008 at 8:08 AM, Oliver Endriss [EMAIL PROTECTED] wrote:
 Guys, I can't stand this blabla any longer.

Then don't read this thread.

 Klaus stated clearly how he wants to do VDR development, and he has the
 right to do it his way! No matter whether you like it or not!

What's your point?  At one point he also said he didn't intend to
support HDTV because he doesn't use it, as well as said he had no
intention to move away from mpeg-pes.  Thanks to the discussions 
input on this mailing list by the users, he has changed his mind.

 My suggestion for those who are unhappy with the current situation:
 0. Stop this discussion.

I will NEVER suggest to prohibit or censor discussion, especially at a
place where open discussion should be promoted.  We all have the right
to our opinions and I see no crime in voicing them.  Judging by the
number of responses, many people have strong opinions on the subject
regardless of which side of the fence they stand on, and I'm glad to
read them all.  Your idea that we should just shut up and if we don't
like it, then make a fork, maintain it for 8 years bla bla bla, is a
bit childish at best.  Sorry, but nobody here needs your permission or
approval to discuss VDR related topics on the VDR mailing list.

Again, my suggestion is to do what I do  Don't read threads that
don't interest me.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] new rolloff paramemter in channels.conf for vdr 1.7.0

2008-09-07 Thread Goga777
  As Manu explained me it's not possible to set manually rolloff/FEC for 
  stb0899.
  that's why I'm wondering - what for need the new roll off (parameter O) 
  parameter in channels.conf ? Only for reading
  the current state of roll off in demod ? (0,35% is default for dvb-s/s2 
  BPSK, QPSK, 8PSK) Is work really ?
 
 It's a transponder parameter that is broadcast in the NIT and can be set
 in the DVB-API. VDR simply hands it over and doesn't care if a particular
 device uses it or not.

thanks for your answer. It's clear for me now

 
 Or did I misunderstand your question?


you understood me correctly :)

Goga


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Halim Sahin
Hi,
On So, Sep 07, 2008 at 06:44:46 +0200, Georg Acher wrote:
 On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote:
  FULLACK Oliver,
  You have forgotten the point:
  
  * help to add dvb-s2 support into main kernel!!
 
 Which one?

I don't know.

But I have forgotten another important point:

Help to develope an fullfeatured, h264 capable card, or hw accelerated
video driver for radeon/nvidia/intel cards.
(greener VDR?)
Nice stuff h264, HDTV.
We need hdtv capable hardware!!!

regards
Halim


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Clemens Kirchgatterer
Georg Acher [EMAIL PROTECTED] wrote:

 I also don't think that a vdr-repository would help in the development
 speed. Either the whole development procedure needs to be changed
 (more maintainer with KLS's approval) or it has no advantage compared
 to the .tgz-distribution.

maybe using git, where you can pull into your own repository for privat
vdr hacking and let other people check it out may be worth a thought.
 
 But I think the repository stuff is only marginal. The design itself
 matters. When looking at the experiences at Reel, there are some
 things to be considered in the (far) future of vdr 2.0:

full ack.
 
 - vdr has grown/evolved since 2000, but is still based in its design
 on the FF card and its capabilities. There are now different signal
 source setups (LNBs, rotor, multiproto, mixed tuners or shared
 tuners/CAMs like in the NetCeiver, and not forgetting the IPTV
 variants), various output types and devices (FF, DXR3, HDE, X11, ...)
 and especially more expectations what a PC-based STB should be able
 to do (playback of other media, home automatisation, etc.).

i always wondered why dvb support was directly compiled in while other
back and frontends were supposed to be plugins. this clearly leaves a
sign that dvb is the preferd plattform.

 - It allows no real server/client distinction. It is quite common to
 have a real file server somewhere in the house, but it's hard to get
 a vdr running on it and viewing on other clients. Even the recordings
 sharing of two vdrs is not that easy (touch update here and
 there...). One of the main advantages of Unix was resource sharing
 and distribution in heterogenous networks (like X over network), but
 vdr is currently focused only on its platform.

for me the biggest obstacle so far in many years of vdr usage. i have
already layed down CAT5 into the living room, why do i still have to
connect directly to the satelite dish to get flawless live viewing? 

 - Based on the long evolution history, vdr IMO also has some design
 problems. Every object interacts with each other, I'm personally lost
 in the inheritance-graph of dozens of identically named
 Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost
 1500LOC) is a bit fat ;-) This makes it hard for newcomers and
 potential contributors. I guess that there are only very few people
 that actually know what is going on in the
 device/devbdevice/remux/libsi-core.

not only that, but also are many standard containers reimplemented in
the core source that increase LOC count for no good, at least i can't
see it.

 I still favour vdr over mythTV or MCE, because their neglect the TV
 side. But we have to face it: Radio is dying already. Old fashioned
 TV over antenna is also getting more and more unimportant and is
 merged with other data sources (IPTV, internet radio, podcasts, ...).
 Full convergence is no if, it's a when.

yes, there is currently no better software for watching, recording and
replaying TV if one uses vdr with a FF card.

best regards ...
clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] Build plugin with different headers then in VDR distribution

2008-09-07 Thread Michael Stepanov
Hi,

I need to have a possibility to build VDR plugins using headers which are
different then in VDR distribution. Does somebody knows
how to do it?

Thanks in advance.

-- 
Cheers,
Michael
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Goga777
  VDR does need some of its core functionality upgraded - for example
  something like the Reel channel scan is badly missing, you should be
  able to easily scan for transponders from within VDR, just like most
  satellite receivers. 

+1


 Hmmm. My VDR automatically updates its channel list by itself, and adds 
 all channels and transponders I ever needed. (which is far from what 
 other receivers I know do.)
 The only thing I miss is a built-in way to get rid of channels that are 
 gone. (I do have my own solution though.)

ah, you are watching the Astra 19.2 E , yes ? Astra has corrected service 
tables (nit, sdt,...) due to this vdr can update
and add new channels. Please, try to delete your channels.conf and start to 
scan Astra with reelchannelscan, Will you find
dvb-s2 channels ??

Goga


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread VDR User
With regards to dvb cards that include mpeg4 hardware decoders...
There aren't many even in development and the ones that do actually
(if they do) make it to production will be very expensive.  At the
cost of the card you can build a pc capable of the same and a lot more
for your money.  In conversations I've had with dvb devs, the demand
for such a card just isn't big enough to bring the price down to
something the average user will pay.  For this reason I don't think
it's wise to continue treating VDR in a way that assumes most users
dusted off the old piece of crap pc in their closet and put a
full-featured card in it.

There is no way to ignore the fact that home entertainment is moving
to htpc-based setups, especially now that hardware is cheap enough
that you can build a powerful pc for little expense.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] h264 patch for vdr 171 (was -[ANNOUNCE] VDR developer version 1.7.1)

2008-09-07 Thread Goga777
Hi, Klaus

thanks for your work.
what about h264 patch ? will it update ?

Goga
 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Georg Acher
On Sun, Sep 07, 2008 at 07:21:04PM +0200, Halim Sahin wrote:
 
   * help to add dvb-s2 support into main kernel!!
  
  Which one?
 
 I don't know.

:-) I guess nobody does...
 
 But I have forgotten another important point:
 
 Help to develope an fullfeatured, h264 capable card, or hw accelerated

Been there, done that already :-) The HDE from Reel decodes h264, I wrote a
lot of the driver stuff for it. So there is (at least one) h264-decoder
card, and btw, vdr is the main platform for the HDE.

 video driver for radeon/nvidia/intel cards.

There are rumours that Ati is planning such drivers... In the long term
special decoder cards will vanish, but I think it will still take some time.

-- 
 Georg Acher, [EMAIL PROTECTED] 
 http://www.lrr.in.tum.de/~acher
 Oh no, not again ! The bowl of petunias  

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Build plugin with different headers then in VDR distribution

2008-09-07 Thread Clemens Kirchgatterer
Michael Stepanov [EMAIL PROTECTED] wrote:

 I need to have a possibility to build VDR plugins using headers which
 are different then in VDR distribution.

what does VDR distribution mean? the vdr source code? what are you
trying to achieve? i guess you have to download the desired vdr
version, copy your plugins into its PLUGINS/src directory and compile
them as usual.

clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Oliver Endriss
Georg Acher wrote:
 I also don't think that a vdr-repository would help in the development
 speed. Either the whole development procedure needs to be changed (more
 maintainer with KLS's approval) or it has no advantage compared to the
 .tgz-distribution.
 
 But I think the repository stuff is only marginal. The design itself
 matters. When looking at the experiences at Reel, there are some things to
 be considered in the (far) future of vdr 2.0:
 
 - vdr has grown/evolved since 2000, but is still based in its design on the FF
 card and its capabilities. There are now different signal source setups
 (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the
 NetCeiver, and not forgetting the IPTV variants), various output types and
 devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a
 PC-based STB should be able to do (playback of other media, home
 automatisation, etc.).
 
 - It allows no real server/client distinction. It is quite common to have a
 real file server somewhere in the house, but it's hard to get a vdr running
 on it and viewing on other clients. Even the recordings sharing of two vdrs
 is not that easy (touch update here and there...). One of the main
 advantages of Unix was resource sharing and distribution in heterogenous
 networks (like X over network), but vdr is currently focused only on its
 platform.
 
 - The current plugin concept allows only a very limited access or
 modfications in the core behaviour. At least without core patches...
 
 - Based on the long evolution history, vdr IMO also has some design
 problems. Every object interacts with each other, I'm personally lost in the
 inheritance-graph of dozens of identically named
 Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is
 a bit fat ;-) This makes it hard for newcomers and potential contributors. I
 guess that there are only very few people that actually know what is going
 on in the device/devbdevice/remux/libsi-core.
 
 I still favour vdr over mythTV or MCE, because their neglect the TV side.
 But we have to face it: Radio is dying already. Old fashioned TV over
 antenna is also getting more and more unimportant and is merged with other
 data sources (IPTV, internet radio, podcasts, ...). Full convergence is no
 if, it's a when.
 
 So, the main discussion topic should be: What is needed for a future-proof
 design? It is not about XML or SQL or other hype buzzwords, it's about the
 overall design and how individual modules/plugins interact with each other.
 
 Just my EUR0.01...

Indeed this would be a very interesting discussion.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Build plugin with different headers then in VDR distribution

2008-09-07 Thread Michael Stepanov
On Sun, Sep 7, 2008 at 9:26 PM, Clemens Kirchgatterer [EMAIL PROTECTED]wrote:

 Michael Stepanov [EMAIL PROTECTED] wrote:

  I need to have a possibility to build VDR plugins using headers which
  are different then in VDR distribution.

 what does VDR distribution mean? the vdr source code? what are you
 trying to achieve? i guess you have to download the desired vdr
 version, copy your plugins into its PLUGINS/src directory and compile
 them as usual.


Yes, I mean VDR sources. I understand how to build plugins using headers
from the VDR's sources. But in my case I have patched headers only (source
is not available yet - headers only).




 clemens

 ___
 vdr mailing list
 vdr@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




-- 
Cheers,
Michael
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] vdr channels.conf compatibility

2008-09-07 Thread David Hláčik
Hello, my question is?

Does dvb-apps 1.1.1 and their utility scan support vdr 1.6 format?

dvb-apps 1.1.1 is official tarball on dvb-apps website.

Thanks!

David
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Halim Sahin
Hello,
On So, Sep 07, 2008 at 08:25:56 +0200, Georg Acher wrote:
 Been there, done that already :-) The HDE from Reel decodes h264, I wrote a
 lot of the driver stuff for it. So there is (at least one) h264-decoder
 card, and btw, vdr is the main platform for the HDE.

Yes right that might be an option for short time.
Micronas stopped the support of the used chips I think.
How many boards can be equipped with the available chips
How many boards are available for vdr users?

I like to have a more general solution!
Regards
Halim


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] Fw: about eHD from Reelmultimedia (was - VDR Development)

2008-09-07 Thread Goga777
I have resent with more correct subject :)  

Дата: Sun, 7 Sep 2008 21:51:54 +0200
От: Halim Sahin [EMAIL PROTECTED]
Кому: vdr@linuxtv.org
Тема: Re: [vdr] VDR Development


Hello,
On So, Sep 07, 2008 at 08:25:56 +0200, Georg Acher wrote:
 Been there, done that already :-) The HDE from Reel decodes h264, I wrote a
 lot of the driver stuff for it. So there is (at least one) h264-decoder
 card, and btw, vdr is the main platform for the HDE.

Yes right that might be an option for short time.
Micronas stopped the support of the used chips I think.
How many boards can be equipped with the available chips
How many boards are available for vdr users?

I like to have a more general solution!
Regards
Halim



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Fw: about eHD from Reelmultimedia (was - VDR Development)

2008-09-07 Thread Georg Acher
On Mon, Sep 08, 2008 at 12:09:11AM +0400, Goga777 wrote:
 
 Yes right that might be an option for short time.
 Micronas stopped the support of the used chips I think.

Support!=availability

 How many boards can be equipped with the available chips

AFAIK we have received no last order date yet. I don't know of any
sourcing problems.

 How many boards are available for vdr users?

Enough... ;)

-- 
 Georg Acher, [EMAIL PROTECTED] 
 http://www.lrr.in.tum.de/~acher
 Oh no, not again ! The bowl of petunias  

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Recommended xine settings for Arte HD ?

2008-09-07 Thread Artem Makhutov
Hi,

Gregoire Favre schrieb:
 On Mon, Sep 01, 2008 at 01:14:51PM +0200, Gregoire Favre wrote:
 On Thu, Aug 21, 2008 at 01:14:23PM +0200, Gregoire Favre wrote:
 On Thu, Aug 21, 2008 at 12:18:02PM +0400, Goga777 wrote:

 yes, but for me it's not errors, it's only information messages, nothing 
 special. May be I wrong... 
 I guess so.

 how ?
 Edit the source, recompil, install.
 I changed this :
 grep BUFSIZE *|grep MEGABYTE
 dvbplayer.c:#define PLAYERBUFSIZE  MEGABYTE(4)
 recorder.c:#define RECORDERBUFSIZE  MEGABYTE(20)
 transfer.c:#define TRANSFERBUFSIZE  MEGABYTE(8)

 My computer has 4Gb of ram so I can be large...
 
 I rarely used VDR for quiete a long time, and I wanted to try some other
 way : I compiled ffmpeg with icc using -O3 -xT -gcc -mtune=core2 and
 that make a difference : now my CPU is almost enough for ARTE HD which
 wasn't the case with gcc ;-)
 
 If the weather stay so bad, I shall use VDR again a lots (not for
 recording as for that I'll wait vdr-1.7.1 but anyway) :-)

What CPU do you have (MHz)?

Have you tried compiling it with gcc -O3 ?

I would like to know, if there is a performance increase, when compiling 
ffmpeg with gcc -O3 instead of -O2.

Maybe some other applications, like the X-Server should also be compiled 
  with -O3 to get a better performance with h264 decoding...

Regards, Artem


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-07 Thread Klaus Schmidinger
On 09/07/08 19:42, Clemens Kirchgatterer wrote:
 ...
 i always wondered why dvb support was directly compiled in while other
 back and frontends were supposed to be plugins. this clearly leaves a
 sign that dvb is the preferd plattform.

Well, it was the first one - long before there even was a plugin interface.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Recommended xine settings for Arte HD ?

2008-09-07 Thread Gregoire Favre
On Sun, Sep 07, 2008 at 11:03:46PM +0200, Artem Makhutov wrote:

 What CPU do you have (MHz)?

Intel Core 2 Duo @ 2.4GHz.

 Have you tried compiling it with gcc -O3 ?

Yes.

 I would like to know, if there is a performance increase, when compiling 
 ffmpeg with gcc -O3 instead of -O2.

Not for everything, AFAIK it's sometimes slower ???

 Maybe some other applications, like the X-Server should also be compiled  
 with -O3 to get a better performance with h264 decoding...

My xorg-server-1.5 is also compiled with icc :-)
-- 
Grégoire FAVRE  http://gregoire.favre.googlepages.com  http://www.gnupg.org
   http://picasaweb.google.com/Gregoire.Favre

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Build plugin with different headers then in VDR distribution

2008-09-07 Thread Clemens Kirchgatterer
Michael Stepanov [EMAIL PROTECTED] wrote:

  what does VDR distribution mean? the vdr source code? what are you
  trying to achieve? i guess you have to download the desired vdr
  version, copy your plugins into its PLUGINS/src directory and
  compile them as usual.
 
 Yes, I mean VDR sources. I understand how to build plugins using
 headers from the VDR's sources. But in my case I have patched headers
 only (source is not available yet - headers only).

i don't see the point. if the header files are different in respect to
ABI compatibillity (for example class member order, number of members
or object size) then your plugins will not work anyway. if the headers
are compatible, it does not matter which one you used to compile them.

anyway, vdr and plugins must be compiled with compatible header
files. this is what the APIVERSION is for. you could try to copy your
patched headers over a fresh vdr source tree and compile it including
your plugins.

hope this helps ...
clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr