Re: [vdr] [PATCH] Working PlayTsXXX to PlayXXX wrapper
On 26.01.2009 08:39, Klaus Schmidinger wrote: > On 25.01.2009 23:53, Udo Richter wrote: >> Attached is a new version of cDevice::PlayTsVideo and >> cDevice::PlayTsAudio that properly handles partially accepted buffers of >> the PlayVideo and PlayAudio functions. The original functions would >> discard any partially written data. > > By definition these two functions shall write "all or nothing". > So the higher level functions needn't handle any partially written data. But in fact they write all or nothing or timeout after one second, in which case they return how much was written. And it seems as if these timeouts do happen. If you change that behavior so that they never timeout (like in VDR 1.7.2/1.7.3), then PES playback frequently hangs for fractions of a second for me. And with the timeout and no partial buffer handling (as in VDR 1.7.4), any TS playback frequently drops the remains of a buffer, causing massive picture breakdown. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Working PlayTsXXX to PlayXXX wrapper
On 26.01.2009 12:10, Udo Richter wrote:
> On 26.01.2009 08:39, Klaus Schmidinger wrote:
>> On 25.01.2009 23:53, Udo Richter wrote:
>>> Attached is a new version of cDevice::PlayTsVideo and
>>> cDevice::PlayTsAudio that properly handles partially accepted buffers of
>>> the PlayVideo and PlayAudio functions. The original functions would
>>> discard any partially written data.
>> By definition these two functions shall write "all or nothing".
>> So the higher level functions needn't handle any partially written data.
>
> But in fact they write all or nothing or timeout after one second, in
> which case they return how much was written. And it seems as if these
> timeouts do happen.
I did some more investigating, and things get really strange...
First, there's no evidence for the 1000ms timeout to actually happen.
Data in fact seems to be written 'all or nothing' in reality. Both
cases, all and nothing, do happen.
The PlayTS functions however are still wrong, since they do not handle
the case where -1/EAGAIN is returned immediately. The PES packet was
returned by GetPes and will not be returned again, so this PES packet
will be dropped.
I also experimented with the VDR-1.7.3 solution again:
do {
w = WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
if (w < 0 && errno == EAGAIN) {
cPoller Poller(fd_video, true);
Poller.Poll(200);
}
} while (w != Length);
WriteAllOrNothing returns either Length or -1/EAGAIN. The poller sleeps
for about 0-20ms each time. CPU load isn't too high either. Still I have
an ARD recording that reproducibly hangs at the same point every time
for a fraction of a second, and only if I use the above loop. This
happens 1-2 times per minute, and usually causes heavy audio/video
desyncing.
The VDR-1.7.1/VDR-1.7.4 version does not show this hang:
return WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
Anyone has an idea what really causes this?
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.4
> VDR developer version 1.7.4 is now available at Something made the hvr-4000 to work with this version of driver. With exactly same drivers and channel.conf file and streamdev-plugin and mplayer, the vdr-1.7.3 is not able to tune dvb-s channels but vdr-1.7.4 works :-) Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.4
Am Sonntag 25 Januar 2009 16:08:30 schrieb Gregoire Favre: > On Sun, Jan 25, 2009 at 02:13:25PM +0100, Klaus Schmidinger wrote: > > What do you mean by "native h.264 support"? > > Didn't test vdr-1.7.4 (about to) but since 1.7.3 it works really great > with vdr-xine and xine-lib-1.2 :-) Hello, @ Klaus: many thanks for this great piece of software! I installed vdr 1.7.3 this weekend, with vdr-xine and xine-lib-1.2, it worked out of the box. Just one thing I found: when jumping between cut-marks or moving them the shown picture is not updated - so when pressing "9" to jump to the next mark I still see the last picture which was shown right before pressing "9". Moving the mark does not update either. This makes editing a bit less charming. Maybe it's gone with 1.7.4 ? > (I also use vdpau : http://www.jusst.de/vdpau/files/xine-lib-1.2/ ). I also tried vdpau (r181, same url) but it seems to me as if everything was worse with it: SD was jumpy, some frames were ok and smooth, then a break/stutter, then again smooth. Stuttering every second or so. HD (arte 1280x720) was not shown at all - without vdpau it worked stuttering but I got a picture. It seems to work for you - How did you manage? Cheers, Ulf signature.asc Description: This is a digitally signed message part. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Delaying subtitles
Josce wrote: > My problem is that vdr 1.6.0 with the reelbox plugin > displays the subtitles 6 seconds too early. > > Does anyone know if there is a simple way to add a > 6 seconds delay to the subtitles? > > I tried to look at the old subtitle plugin and how it > was done there but couldn't see how to apply that to > the subtitle handling that vdr does. > > Regards, > > Josce I just noticed that there's a patch for 1.6.0 and 1.7.4... http://www.saunalahti.fi/~rahrenbe/vdr/patches/vdr-1.6.0-dvbsubs-delay.patch.gz http://www.saunalahti.fi/~rahrenbe/vdr/patches/vdr-1.7.4-dvbsubs-delay.patch.gz At least the description says: Allows you to add an additional delay in tenth of seconds for showing the subtitles. The valid range is -20...100. This option is only available if "Display subtitles" is set to 'yes'. I'll try to have some time to test this one. The ttxtsubs delay can be set and I can live with that, but if this one solves the problems with the subtitles, I'm going to freeze the vdr version 1.7.4 for quite a long time ;) ...hanu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] ATSC for VDR 1.7.4
On 25.01.2009 22:07, Alex Lasnier wrote: > Hi all, > > This patch adds ATSC support to VDR 1.7.4. > > Klaus, would you consider adding this to VDR? Am I right in understanding that ATSC is a "subset" of DVB-T? How are ATSC transponders announced in the NIT? Shouldn't there also be some code in cNitFilter::Process() for this? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.7.4 & xineliboutput
I saw some things going on in the xineliboutput CVS. Not sure if TS should work or not. I tryed VDR 1.7.4 with xine-lib-vdpau and xineliboutput CVS. Got the following error : http://pastebin.com/m6691b7a8 cu Edgar (gimli) Hucek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] consistent device removal
Hi,
sometimes it is very useful to create and destroy cDevice based classes
at runtime. Currently it is only possible to create such classes at any
time but destroying causes inconsistency in the 'devices' array which
leads to segmentation faults in various places.
The patch attached keeps the 'device' array consistent on destruction of
any cDevice based class. Please add this patch to current 1.6/1.7
development versions.
The next thing to do is removing the MAXDEVICES constraint which should
make it possible to add any number of cDevice based instances.
Just in case you are interested why I need this feature: I am working on
a native VDR plugin for the NetCeiver hardware. With this box it is
possible to have up to 6 DVB-S2 devices (or DVB-S/C/T) per NetCeiver.
You can attach up to 5 NetCeivers to a gigabit network which makes 30
DVB devices available. Therefore it should be possible to create and
destroy DVB devices at runtime.
Deti
--- ../vdr-1.6.0/device.c 2009-01-26 20:26:49.0 +0100
+++ device.c 2009-01-26 22:09:59.0 +0100
@@ -253,14 +253,19 @@
for (int i = 0; i < MAXRECEIVERS; i++)
receiver[i] = NULL;
- if (numDevices < MAXDEVICES)
- device[numDevices++] = this;
- else
- esyslog("ERROR: too many devices!");
+ for (int i = 0; i < MAXDEVICES; i++)
+ if (!device[i]) {
+ device[i] = this;
+ numDevices++;
+ break;
+ }
+ esyslog("ERROR: too many devices!");
}
cDevice::~cDevice()
{
+ numDevices--;
+ device[DeviceNumber()] = NULL;
Detach(player);
DetachAllReceivers();
delete liveSubtitle;
@@ -272,7 +277,7 @@
{
for (time_t t0 = time(NULL); time(NULL) - t0 < Timeout; ) {
bool ready = true;
- for (int i = 0; i < numDevices; i++) {
+ for (int i = 0; i < MAXDEVICES; i++) {
if (device[i] && !device[i]->Ready()) {
ready = false;
cCondWait::SleepMs(100);
@@ -304,7 +309,7 @@
int cDevice::DeviceNumber(void) const
{
- for (int i = 0; i < numDevices; i++) {
+ for (int i = 0; i < MAXDEVICES; i++) {
if (device[i] == this)
return i;
}
@@ -318,7 +323,7 @@
bool cDevice::SetPrimaryDevice(int n)
{
n--;
- if (0 <= n && n < numDevices && device[n]) {
+ if (0 <= n && n < MAXDEVICES && device[n]) {
isyslog("setting primary device to %d", n + 1);
if (primaryDevice)
primaryDevice->MakePrimaryDevice(false);
@@ -352,7 +357,7 @@
cDevice *cDevice::GetDevice(int Index)
{
- return (0 <= Index && Index < numDevices) ? device[Index] : NULL;
+ return (0 <= Index && Index < MAXDEVICES) ? device[Index] : NULL;
}
cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView)
@@ -388,8 +393,8 @@
for (int j = 0; j < NumCamSlots || !NumUsableSlots; j++) {
if (NumUsableSlots && SlotPriority[j] > MAXPRIORITY)
continue; // there is no CAM available in this slot
- for (int i = 0; i < numDevices; i++) {
- if (device[i] == AvoidDevice)
+ for (int i = 0; i < MAXDEVICES; i++) {
+ if (device[i] == NULL || device[i] == AvoidDevice)
continue; // this device shall be temporarily avoided
if (Channel->Ca() && Channel->Ca() <= CA_DVB_MAX && Channel->Ca() != device[i]->CardIndex() + 1)
continue; // a specific card was requested, but not this one
@@ -463,10 +468,11 @@
void cDevice::Shutdown(void)
{
primaryDevice = NULL;
- for (int i = 0; i < numDevices; i++) {
- delete device[i];
- device[i] = NULL;
+ for (int i = 0; i < MAXDEVICES; i++) {
+ if( device[i]) {
+delete device[i];
}
+}
}
uchar *cDevice::GrabImage(int &Size, bool Jpeg, int Quality, int SizeX, int SizeY)
@@ -703,7 +709,7 @@
bool cDevice::ProvidesTransponderExclusively(const cChannel *Channel) const
{
- for (int i = 0; i < numDevices; i++) {
+ for (int i = 0; i < MAXDEVICES; i++) {
if (device[i] && device[i] != this && device[i]->ProvidesTransponder(Channel))
return false;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] ATSC for VDR 1.7.4
Klaus Schmidinger wrote: > On 25.01.2009 22:07, Alex Lasnier wrote: >> Hi all, >> >> This patch adds ATSC support to VDR 1.7.4. >> >> Klaus, would you consider adding this to VDR? > > Am I right in understanding that ATSC is a "subset" of DVB-T? > > How are ATSC transponders announced in the NIT? > Shouldn't there also be some code in cNitFilter::Process() for this? > > Klaus > Although ATSC and DVB-T share some similarities, they are fundamentally different. For instance, the ATSC standard does not even define a NIT. The patch simply allows VDR to tune and view ATSC channels, the various tables are parsed by a plugin. Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] consistent device removal
uups: change the 'break' by 'return' otherwise you'll get a wrong error message ;-) Deti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] consistent device removal
On 26.01.2009 22:25, Deti Fliegl wrote: > sometimes it is very useful to create and destroy cDevice based classes > at runtime. Currently it is only possible to create such classes at any > time but destroying causes inconsistency in the 'devices' array which > leads to segmentation faults in various places. Definitely something that is worth considering. The patch also brings us one step closer towards hotplug support, a feature that seems very obvious in times of USB DVB devices. However this throws the question at which time and in which context it is safe to kill a device object without risking that any running process gets into trouble because its device is suddenly in bit heaven. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] consistent device removal
Udo Richter wrote: > Definitely something that is worth considering. The patch also brings us > one step closer towards hotplug support, a feature that seems very > obvious in times of USB DVB devices. Yep you are right but IMHO there would be some more work to do: VDR should compile also without direct Linux DVB kernel support. So we could get rid of any specific Linux dependency (and use VDR for BSD based systems like MacOS without patching). Therefore section filtering should make use of a virtual Read() method in the device class. There also needs to be an abstraction for signal information so that plugins like channelscan and femon are not depending on the direct DVB access. Maybe it makes sense to have a Linux DVB device plugin. > However this throws the question at which time and in which context it > is safe to kill a device object without risking that any running process > gets into trouble because its device is suddenly in bit heaven. Well this is nifty but most of the proper device shutdown procedure can be done in the cDevice based class. Deti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] consistent device removal
On 26.01.2009 23:01, Deti Fliegl wrote: > Udo Richter wrote: >> Definitely something that is worth considering. The patch also brings us >> one step closer towards hotplug support, a feature that seems very >> obvious in times of USB DVB devices. > Yep you are right but IMHO there would be some more work to do: > > VDR should compile also without direct Linux DVB kernel support. So we > could get rid of any specific Linux dependency (and use VDR for BSD > based systems like MacOS without patching). Therefore section filtering > should make use of a virtual Read() method in the device class. There > also needs to be an abstraction for signal information so that plugins > like channelscan and femon are not depending on the direct DVB access. > Maybe it makes sense to have a Linux DVB device plugin. Putting cDvbDevice into a plugin is on my agenda, but TS recording and full HDTV support comes first. Don't even send a patch for this - I won't look into it at this time. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] Section Filter Read Abstraction
Hi,
when using cDevice based classes that have no access to kernel based
section filters it makes sense to have an abstract 'ReadFilter'
function. The patch attached adds such a method to the cDevice class and
changes cSectionHandler code to use the new method.
Please add this patch to current 1.6/1.7 development versions.
Deti
--- ../vdr-1.6.0/device.c 2009-01-26 20:26:49.0 +0100
+++ device.c 2009-01-26 23:12:59.0 +0100
@@ -674,6 +680,11 @@
return -1;
}
+int cDevice::ReadFilter(int Handle, void *Buffer, size_t Length)
+{
+ return safe_read(Handle, Buffer, Length);
+}
+
void cDevice::CloseFilter(int Handle)
{
close(Handle);
--- ../vdr-1.6.0/device.h 2009-01-26 20:26:49.0 +0100
+++ device.h 2009-01-26 23:12:41.0 +0100
@@ -317,6 +317,10 @@
///< Opens a file handle for the given filter data.
///< A derived device that provides section data must
///< implement this function.
+ virtual int ReadFilter(int Handle, void *Buffer, size_t Length);
+ ///< Read from a handle for the given filter data.
+ ///< a derived class need not implement this function, because this
+ ///< is done by the default implementation.
virtual void CloseFilter(int Handle);
///< Closes a file handle that has previously been opened
///< by OpenFilter(). If this is as simple as calling close(Handle),
--- ../vdr-1.6.0/sections.c 2007-10-14 14:52:07.0 +0200
+++ sections.c 2009-01-26 23:14:00.0 +0100
@@ -198,7 +198,7 @@
if (fh) {
// Read section data:
unsigned char buf[4096]; // max. allowed size for any EIT section
- int r = safe_read(fh->handle, buf, sizeof(buf));
+ int r = device->ReadFilter(fh->handle, buf, sizeof(buf));
if (!DeviceHasLock)
continue; // we do the read anyway, to flush any data that might have come from a different transponder
if (r > 3) { // minimum number of bytes necessary to get section length
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
