Using rt-libflute in MBS Transport Function (MBSTF)

[rjb1000]

@devbbc asked:

Hi Klaus,
I am planning to use rt-libflute as part of Multicast–Broadcast Service Transport Function (MBSTF) for Object Distribution Method. So, looking at the best way to integrate this library for the MBS User Services.
Looked into Transmitter source code and examples/flute-transmitter.cpp. The example application reads the contents of each of the input files into buffers and stores them in a C++ vector. It then sends the buffers in the vector to a target multicast address and port.
Wondering if the Transmitter can fetch an object stored both in memory and disk?

[rjb1000]

@kuehnhammer responded:

Hi Dev!
Not sure I understand your question right.. the Transmitter class in libflute expects to be handed a memory buffer in its send() function, and will trigger a completion callback when that buffer has been transmitted, giving the caller a chance to free that buffer again.
The Transmitter class can't read from disk directly, that's the responsibility of the caller. flute-transmitter.cpp shows one way to do that, depending on your application there will probably be a better way.The idea is that the library should work regardless of where the files come from (disk, network, memory, etc) and whether it even has access to persistent storage at all (it might not when it's running e.g. in a Kubernetes pod).
HTH, best, Klaus

[rjb1000]

Thanks, @kuehnhammer. Makes sense. Any file first needs to be loaded into a memory buffer before handing that to libflute.

[rjb1000]

We had an additional question after discussion this morning:

MBS User Services supports the following modes of operation defined in clause 6 of TS 26.502:

1. Packet Distribution operating mode.
2. Object Distribution operating mode.
   1. Single shot object.
   2. Object bundle listed in an object manifest (specified in TS 26.517).
      • (Essentially single shot for a bundle of objects, such as a website.)
   3. Object carousel described by an object manifest (specified in TS 26.517).
      • (Variant of the object bundle where the objects are sent repeatedly.)
   4. Streaming media presentation described by the timing model in a presentation manifest (e.g. DASH MPD).
      • (Essentially single shot for a timeline of media segments.)

Based on the analysis of libflute that @devbbc and @davidjwbbc have done, we think that it would support 2(i) easily; also 2(ii) and 2(iv) with appropriate surrounding logic. This is based on the understanding that the library sends each object once in the FLUTE Session and automatically removes it from the session afterwards. This comes as no surprise since DASH/HLS streaming over MBMS (similar to 2(iv) above) is the main Use Case for libflute so far in 5G-MAG.

The one mode of operation we think libflute doen't support is 2(iii) where the same objects are repeatedly transmitted over a FLUTE Session with the same Transport Object Identifiers according to a schedule expressed in the object manifest. This is based on the understanding that the library invokes a callback to tell the application when it has sent each object once. Hence, the only way to transmit an object more than once is for the application to retransmit it by invoking the library again. However, this will result in a new Transport Object Identifier being allocated, which is not the wanted behaviour.

Is our understanding correct, @kuehnhammer?

[rjb1000]

One potential enhancement to the library would therefore be for the application to be able to request that an object be sent repeatedly. However, this may stretch the scope of libflute beyond the original design brief.

A simpler enhancement might be to allow the application to optionally specify an explicit Transmission Object Identifier when requesting transmission of an object in the FLUTE Session. This could then be combined with the callback which we think informs the application of the TOI value just transmitted. Using this, the application could request that the object be transmitted again with the same TOI value as last time, and the logic for scheduling the objects in the carousel would sit in the application rather than in the library. This sounds good in principle, but would result in objects constantly falling out of the FLUTE File Description Table (FDT) only for it to be reinserted in the next version of the FDT sent in TOI=0. This "flapping" is presumably signalled to the client, which must then keep reprocessing each new version of the FDT.

Ideally, if the contents of the FLUTE Session is stable for a period of time (i.e. a static set of objects described in a manifest), then the FDT in TOI=0 doesn't need to change at all, and the client doesn't need to reprocess it.

Maybe what's needed is a new public function to more explicitly add items to the FLUTE Session, and later to remove them. Asking libflute to schedule the multiple transmissions feels a stretch too far, but maybe the application could compile a schedule as an array of TOI values which is passed in via another new public function in order to start the transmission. This could be a simple ABCD, ABCD repetition pattern, or something more complex like ABABCABD, ABABCABD, etc.

I can't quite remember if there is a packet counter in the FLUTE/ALC/LCT header, but maybe the set of packets for one rotation of the carousel is identical to the next rotation and they could be stored in the library for reuse in the next rotation.

Maybe the use of AL-FEC messes with this, though?