[linux-dvb] Re: Record Filters in V4 API

[Michael Hunold <hunold@convergence.de>]

Hello Rob,

On 04/05/04 15:55, Rob.McConnell@Zarlink.Com wrote:
> I have had to send this message again to the list.  This is the 2nd time
> this has happened recently - any ideas why my messages don't seem to be
> getting through?
The lists had to be migrated multiple times recently, so perhaps there 
were gaps where the list was inaccessible. I agree that this should 
never happen. 8-(

> Q5:  The ioctl "DVB_DMX_RETRIEVE_RECORDING_DATA" returns a
> "dvb_dmx_recording_data" struct, but what are the meaning of the
> rec_offset/rec_len and log_off/log_len?  Is log shorthand for a log fs, or
> is it pertaining to metadata that is stored separately to the actual
> recorded A/V data?
> Anyway with regards to Q5, I understand that the log is a log of events
> that are stored in a separate area - correct?  I guess the idea here is to
> allow quick navigation of the recorded data by reading the log to find an
> event, and "jumping" to the actual stored data.  Please feel free to
> elaborate on this or correct me.
Exactly. The current idea is like this: after having started the 
recording filter, the incoming packets that are stored in memory are 
enumerated. If a packet has one of the interesting events set (for 
example PUSI), then an entry to the log memory is made, carrying the TS 
packet number and an event mask.

When you call DVB_DMX_RETRIEVE_RECORDING_DATA, the offset and len 
parameters show you which memory areas contain valid data. There may be 
two values present in case the ringbuffer wrapped around. Have a look at 
"test_recf" for a simple test program that captures data and prints out 
the event logging informations.

Currently there is no way to specify in which events you are actually 
interested.

> Thanks,
>
> Rob : )
I'm going to answer your other mails now. 8-)

CU
Michael.



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.