dmx_section_cb(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– dmx_section_cb πŸ’–

okay so real talk, this is a page from the Kernel API Manual and it's all about dmx_section_cb(9) β€” a function callback prototype for DVB demux TS filtering. yes bestie, we're in kernel land and it's iconic πŸŽ€


✨ NAME ✨

dmx_section_cb β€” the DVB demux TS filter callback function prototype. that's the whole vibe, she's a prototype, not the real implementation, and we respect her for it πŸ’…


🌸 SYNOPSIS 🌸

int dmx_section_cb (const u8 *buffer1 , size_t buffer1_len , const u8
*buffer2 , size_t buffer2_len , struct dmx_section_filter *source , u32
*buffer_flags );

look at all those parameters, she's got range πŸ”₯


πŸ¦‹ ARGUMENTS πŸ¦‹

  • buffer1 β€” pointer to the start of the filtered section, like e.g. sitting inside the circular buffer of the demux driver. that's where the tea (the section) begins πŸ“
  • buffer1_len β€” the length of the filtered section data in buffer1, and yes it includes the headers and the CRC. no sneaky exclusions, count it all πŸ’―
  • buffer2 β€” pointer to the tail of the filtered section data, or NULL if there isn't one. super useful when you gotta handle the wrapping of a circular buffer, iykyk πŸŒ€
  • buffer2_len β€” length of the filtered section data in buffer2, headers and CRC included, same rules as her sister above 🌈
  • source β€” tells you which section feed is the source of the callback. like a little name tag at the party πŸŽ€
  • buffer_flags β€” the address where the buffer flags are stored. these are used to report discontinuity to users via the DVB memory mapped API, as defined by enum dmx_buffer_flags. literally the receipts πŸ“

πŸ‘‘ DESCRIPTION πŸ‘‘

so this function callback prototype is provided by the client of the demux API and it gets called from the demux code. main character callback energy, periodt ✨

the function is only called when filtering of sections has been enabled using the function dmx_ts_feed.start_filtering. no enabling, no callback, that's the rule 🚨

when the demux driver has received a complete section that matches at least one section filter, the client gets notified via this callback function. normally this function is called for each received section β€” but lowkey it's also possible to deliver multiple sections with one callback, for example when the system load is high. multi-tasking queen πŸ’…

if an error occurs while receiving a section, this function should be called with the corresponding error type set in the success field, whether or not there is data to deliver. like, no data? still call it. that's the assignment 🫢

the Section Feed implementation should maintain a circular buffer for received sections. however, this is not necessary if the Section Feed API is implemented as a client of the TS Feed API, because the TS Feed implementation then buffers the received data for you. convenient? we love πŸŽ€

the size of the circular buffer can be configured using the dmx_ts_feed.set function in the Section Feed API. customizable and cute 🌸

⚠️ okay important one, bestie: if there is no room in the circular buffer when a new section is received, the section must be discarded. and if that happens, the value of the success parameter should be DMX_OVERRUN_ERROR on the next callback. don't forget, fr fr 😭

πŸ”₯ SEE ALSO πŸ”₯

kernel file ./include/media/demux.h, plus all her friends:

  • enum ts_filter_type(9)
  • struct dmx_ts_feed(9)
  • struct dmx_section_filter(9)
  • struct dmx_section_feed(9)
  • dmx_ts_cb(9)
  • enum dmx_frontend_source(9)
  • struct dmx_frontend(9)
  • enum dmx_demux_caps(9)
  • DMX_FE_ENTRY(9)
  • struct dmx_demux(9)

and that's the page, bestie!! 🧚 from ./include/media, dated October 2026, and she's officially dmx_section_cb(9). go forth and filter those sections, you're gonna slay πŸ’œβœ¨

πŸ“¦ where this page comes from