Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Record Filters in V4 API
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.
Home |
Main Index |
Thread Index