On Friday 01 November 2002 02:18, Ralph Metzler wrote:
> Dennis writes:
> > 1965 8.01648 DmxDevBufferRead
> > 0710 2150 8.77121 DmxDevTSCallback
> > 1ae0 2526 10.3052 DvbDmxSWFilterPacket
> > 1740 1398557.0537 DmxDevBufferWrite
> What contex
Dennis writes:
> 1965 8.01648 DmxDevBufferRead
> 0710 2150 8.77121 DmxDevTSCallback
> 1ae0 2526 10.3052 DvbDmxSWFilterPacket
> 1740 1398557.0537 DmxDevBufferWrite
> When I use gprof with vdr, I get similar output, ScanVideoPacket tops t
> Could you please install oprofile and try to find out where your CPU is
> spending it's time?
Hi,
Small problem is that I just have set up everything in a P1 box, which does
not support the real CPU counter oprofile likes to use, so it runs in RTC
mode, which has a fairly low sample count. Ho
> However, I'm not shure if it is supposed to work to cat two
> PES streams into /dev/dvb/a*0/audio0 and video0 and have the
> MPEG decoder produce correctly synced output...
I think it should, since it enables you to play, for example, DVDs without
re-encoding them as TS. And not every device sup
Ralph Metzler wrote:
> Johannes Stezenbach writes:
> > IMHO this should not be done in the kernel, but in a userspace library:
> > - DMX_GET_CAPS must be defined properly
> > - we need a libdvbdemux that looks at DMX_GET_CAPS and takes care of
> > emulating features that the hardware does not
Klaus Schmidinger writes:
> Johannes Stezenbach wrote:
> >
> > ...
> > One thing the driver does which I think it shouldn't is emulating
> > demux features in software that the hardware doesn't have.
> > E.g. the AV7110 does not give us the TS, thus the output for
> > the dvr device must be
Hi Dennis,
Dennis wrote:
This could just as well be a high IRQ load due to the small
dual ported RAM which the AV7110 uses to pass data to the PC.
Sorry for not giving you the whole story. Currently, (P1-133 machine), using
the old (i.e. before NEWSTRUCT) drivers and vdr-1.0.4, I can record
Johannes Stezenbach writes:
> On Thu, Oct 31, 2002 at 02:21:31AM +0100, Felix Domke wrote:
> > - "receive buffer size". not the DMX_SET_BUFFER-thing (so not the
> > ringbuffer size), but instead (on hardware layer) the interrupt frequency.
> > for example:
> > on hi-datarate services, specify
> This could just as well be a high IRQ load due to the small
> dual ported RAM which the AV7110 uses to pass data to the PC.
Sorry for not giving you the whole story. Currently, (P1-133 machine), using
the old (i.e. before NEWSTRUCT) drivers and vdr-1.0.4, I can record a channel
on card 2, wh
On Thu, Oct 31, 2002 at 04:57:20PM +0200, Dennis Noordsij wrote:
>
> > One thing the driver does which I think it shouldn't is emulating
> > demux features in software that the hardware doesn't have.
> > E.g. the AV7110 does not give us the TS, thus the output for
> > the dvr device must be recrea
On Thu, Oct 31, 2002 at 05:37:44PM +0100, Klaus Schmidinger wrote:
> Johannes Stezenbach wrote:
> >
> > I don't see why an application would request a TS from the driver if the
> > applicaton wants PES and the driver can deliver PES.
> > STB controllers that support recording can use any format th
> The entire recording and "Transfer Mode" mechanisms of VDR are based on the
> assumption that the driver can deliver TS packets, since that's the most
> basic form of data (AFAIK that's the way it is broadcast), and it is the
> easiest way to distribute the data to various receivers. This is wha
Johannes Stezenbach wrote:
>
> On Thu, Oct 31, 2002 at 05:28:21PM +0200, Dennis Noordsij wrote:
> >
> > > capability... As far as I understand Ralph's work here he found a way
> > > to grab the TS data by directly reaching into the data stream at an earlier
> > > stage, before the PES packets are
> I'm not shure about Ralph's last work for the AV7110 firmware, so maybe
> my knowledge is out of date. I don't know what the firmware does
> for DATA_TS_RECORD.
> Look in av7110.c for pes_to_ts(). AFAIK the does AV7110 not give you
> the TS packets, at least not if the data is also going to the
On Thu, Oct 31, 2002 at 05:28:21PM +0200, Dennis Noordsij wrote:
>
> > capability... As far as I understand Ralph's work here he found a way
> > to grab the TS data by directly reaching into the data stream at an earlier
> > stage, before the PES packets are generated. maybe I'm misunderstanding
>
Hi,
Johannes Stezenbach wrote:
just a question: is there a well-documented, strict specified way of the
order while doing zapping?
Unfortunately not.
for example, WHEN to i have to issue which
VIDEO_* command, when do i have to enable the pidfilters and so on.
What works well for us is
> capability... As far as I understand Ralph's work here he found a way
> to grab the TS data by directly reaching into the data stream at an earlier
> stage, before the PES packets are generated. maybe I'm misunderstanding
> something here, but the bottom line is: the driver should _always_ provi
Hi,
> > - "receive buffer size". not the DMX_SET_BUFFER-thing (so not the
> > ringbuffer size), but instead (on hardware layer) the interrupt
frequency.
> > for example:
> > on hi-datarate services, specify a high number. the user will geht few
but
> > big packages of data. on lo-datarate service
Johannes Stezenbach wrote:
>
> ...
> One thing the driver does which I think it shouldn't is emulating
> demux features in software that the hardware doesn't have.
> E.g. the AV7110 does not give us the TS, thus the output for
> the dvr device must be recreated in software from PES packets.
> IOW,
> One thing the driver does which I think it shouldn't is emulating
> demux features in software that the hardware doesn't have.
> E.g. the AV7110 does not give us the TS, thus the output for
> the dvr device must be recreated in software from PES packets.
> IOW, there's a complete TS multiplexer
On Thu, Oct 31, 2002 at 02:21:31AM +0100, Felix Domke wrote:
> > I'd like to invite everybody to review the audio/video decoder and demux
> > API. We'll freeze everything soon and want to make a release again, so
> > please stand up and make your suggestions now if you think that things
> > should
21 matches
Mail list logo
