On 04/05/04 15:55, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
