Re: [vdr] DVB (usb) device hotswapping?
Am 04.04.2010 03:37, schrieb Georg Acher: It is now solved by the mcli plugin by allocating all (16) devices at startup. When the various Provides*-methods are called for tuning, the plugin searches in its internal resource database for an appropriate tuner and assigns it to the vdr-device. If there is no appropriate tuner for the request the Provides-methods return simply false, so the device is skipped. That is virtualizing of already virtual tuners :-O This means also that every tuner has initially no type like DVB-S/C/T. The type is allocated on demand during tuning and reset when the device has no active PIDs (for short, actually it's a bit more complicated since there is no reliable resource usage tracking in vdr...). Very impressive! Doing all that as a plugin is some smart plugin interface usage! For a VDR internal method things would get easier, no need to pre-allocate dummies. Cleaning up the mess however is not as easy. How did you solve the case that a device disappears while being used? If this happens for a recording, then VDR would terminate with a VDSB, or? Do you silently switch the device to another resource? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB (usb) device hotswapping?
On Sun, Apr 04, 2010 at 10:54:02AM +0200, Udo Richter wrote: How did you solve the case that a device disappears while being used? If this happens for a recording, then VDR would terminate with a VDSB, or? Do you silently switch the device to another resource? As long as the device is used by vdr with a successful Provides() at the beginning, it cannot disappear, even if the real device behind it is gone. However, the vdr-device will get a no-lock after 10s and femon sees no longer a type and description after one minute. That also triggers the VDSB message, but recording goes on if the resource re-appears, as the vdr-device is not shutdown. Since the tuner behind it is already virtualized, it will be immediately attached again to the dangling dvbdevice if something matching appears, e.g. when the network gets reconnected. This is due to the fact that the tuning parameters are included in the MLDv2-messages the mcli-plugin will resend every few seconds for an open device. The streaming starts again when an appropriate server gets these messages. In principle it is possible to switch to another resource, but the current firmware supports no distributed sources (=satellite positions) over different NetCeivers, they need to be exclusive. We have already a peer-to-peer-like firmware that supports distributed resources and would allow redundant NetCeivers, but it still needs some CPU optimizations for the slow CPU on the NetCeiver... However, internally in one NetCeiver an expensive resource (like a rotor or a S2-tuner that were used because no other tuners were free at that time) is automatically switched back to a cheaper resource if possible. This is almost invisible from the outside... -- Georg Acher, ac...@in.tum.de 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 xine-lib eac3
Yes, the file is ff_audio_decoder.c
You must put the line
this-context-request_channels = 2;
after
this-context-codec_tag = _x_stream_info_get(this-stream,
XINE_STREAM_INFO_AUDIO_FOURCC);
Jose Alberto
El Sábado, 27 de Marzo de 2010, zaverel escribió:
Is ff_audio_decoder.c to patch ?
I try but that change nothing.
Le 26/03/2010 13:12, Jose Alberto Reguero a écrit :
You can add the line:
this-context-request_channels = 2;
in line 247 and 295.
Then you have stereo sound.
Joae Alberto
El Viernes, 26 de Marzo de 2010, zaverel escribió:
After some test there are some issue:
ramdom crash at start up or without sound.
But the real probleme i think is with 5.0 sound.
In the sample the 2.0 audio out is good
but the 5.0 has low volume and metallic sound
just try xine
fra piste 5.0
ffmpeg_audio_dec: unknown header with buf type 0x300
qaa 2.0
is good
ffmpeg -i 1.ts
...
Input #0, mpegts, from '1.ts':
Duration: 00:02:10.51, start: 10461.634989, bitrate: 6905 kb/s
Program 132
Stream #0.0[0x78]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR
16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc
Stream #0.1[0x82](fra): Audio: eac3, 48000 Hz, 5.0, s16, 256 kb/s
Stream #0.2[0x83](qaa): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s
Stream #0.3[0x8c](fra): Subtitle: dvbsub
Stream #0.4[0x8d](fra): Subtitle: dvbsub
Le 25/03/2010 16:08, Jose Alberto Reguero a écrit :
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now
must work if you patch remux.c.
You must have the latest xine-lib and xineliboutput. Yesterday both
have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c = lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533
case SI::AC3DescriptorTag:
+case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag;
+Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch.
I make the same changes that in the second patch, but maintaining
the logic of the first patch. Also I commented the line:
+//this-context-request_channels = 2;
because your example has 5 channels. If you have trouble with that
you can comment the line again.
Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c
and with use xine-lib-1.2 with your second patch (who has typo
error) and that doesn't work.
corrected remux.c
line 533
case SI::AC3DescriptorTag:
+case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag;
+Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with
line 402
case SI::AC3DescriptorTag:
+case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |Spectral extension ?
because in france dvb-t with eac3 has it
and need a ffmpeg patched for that.
And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch
also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag:
+case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag;
+Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri
Hintukainen
And I notice this part is not working like it should
-if((m-descriptor_tag == STREAM_AUDIO_AC3) ||/* ac3 -
raw */ +if(m-descriptor_tag == HDMV_AUDIO_84_EAC3) {
+ m-content = p;
+ m-size = packet_len;
+ m-type |= BUF_AUDIO_EAC3;
+ return 1;
+
+} else if((m-descriptor_tag == STREAM_AUDIO_AC3) ||/*
ac3 - raw */
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is
STREAM_AUDIO_AC3, so the program never run the first if
(installed a debug printf here)
It seems that your first approach (at least what I understood) by
forcing the decoding of all AC-3 stream by ffmepg instead of
internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to
ffmpeg or xine-lib)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work :
Re: [vdr] DVB (usb) device hotswapping?
On 3 April 2010 21:17, Teemu Rantanen t...@iki.fi wrote: Hi, now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported? I guess adding a new device could be done quite easily e.g. by probing new cards. But ejecting a device might not be that easy I guess as there may be device pointers around vdr? This also leads to another problem with (linux and vdr) device numbering, as the nature of usb devices is lot less constant as with pci devices. I That is true for pci devices because there is a persistent udev rule created for pci devices. I guess usb can also have a persistent rule/association created. However this will not solve your problem where device 0 and 2 is mapped persistently and 1 is still missing. Vdr will there for stop at 1 :( noticed that e.g. if you insert 3 devices (and have adapters 0,1,2) and remove the second adapter, then you only have (in linux) adapters 0 and 2. Even if the device is ejected when vdr is not running, it looks like to me (by reading cDvbDevice::Initialize()) that only adapter 0 is detected by vdr, as the initialize loop stops after adapter 1 is not found... Even though this isn't really a problem for most installations, I wanted to start a thread to give this some thought. Teemu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB (usb) device hotswapping?
On 4 April 2010 03:37, Georg Acher ac...@in.tum.de wrote: On Sun, Apr 04, 2010 at 12:35:04AM +0200, Udo Richter wrote: Am 03.04.2010 21:17, schrieb Teemu Rantanen: now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported? VDR is far from being able to hot-swap. This is true, but there is a workaround for that. It involves one indirection in the device handling by a plugin. During the development of the mcli-plugin for the NetCeiver the same issue appeared. The networked tuners are already virtualized, they get visible a few seconds after the plugin start and may also disappear or change their type. So hotplugging support was a must. It is now solved by the mcli plugin by allocating all (16) devices at startup. When the various Provides*-methods are called for tuning, the plugin searches in its internal resource database for an appropriate tuner and assigns it to the vdr-device. If there is no appropriate tuner for the request the Provides-methods return simply false, so the device is skipped. That is virtualizing of already virtual tuners :-O Can this solution coexist with vdr-streamdev/iptv? I ask because currently vdr-streamdev does not support dynamic increase in streams to remote server(s). Only way now is to copy the plugin multiple times and load them accordingly. If the plugin is loaded 3 times, then it will allow 3 connections. I take it this will then consume 3 devices? This means also that every tuner has initially no type like DVB-S/C/T. The type is allocated on demand during tuning and reset when the device has no active PIDs (for short, actually it's a bit more complicated since there is no reliable resource usage tracking in vdr...). -- Georg Acher, ac...@in.tum.de 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
Hi, There's a new version of the patch implemented as a plugin. It seems to work, but there are few things to notice: - Plugin does not cache which devices are Reddo devices, instead it probes sysfs every time QAM256 channel is being tuned into (on any device). It would be nice if cDeviceHook added a mechanism for a hook to store context for each device. Hooking into device probe (like full feature card plugin does) would be much nicer way, but it would interfere with other plugins which need the same mechanism. - VDR crashes at very late in exit() when clearing some list (most likely cDeviceHook list), but I couldn't find a way to avoid that - You may get syslog messages about trying to tune into QAM256 channel if/when EPG is being updated on the background. - The sysfs probe code in full feature card plugin is buggy :-) The plugin is available here: http://tvr.dy.fi/vdr/vdr-disablereddoqam256-0.0.1.tgz Teemu 2010/4/3 VDR User user@gmail.com Klaus added the ability to limit satellites to certain dvb card in VDR-1.7.13. However, a lot of users have the need to do device limiting at the transponder level, which VDR still can't do (and likely will never do I think, unfortunately). But, Klaus also added device hooks in VDR-1.7.13 as well: - Implemented cDeviceHook to allow plugins more control over which device can provide which transponder (thanks to Reinhard Nissl). This means that a plugin can be written that DOES provide device limiting at the transponder level! Rnissl, as a test for the device hook patch, threw together a quick skeleton plugin using hardcoded values and it worked great. To finish the plugin, it would just need support for a conf file where you define which transponder:polarity:satellite devices you want to limit them to. I assume this file would be read into a table stored in memory, and then referenced during a channel change for live tv or recording. If Rnissl see's this, maybe he'll elaborate further. Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
