[linux-dvb] Remultiplexer filter - call for code (2)

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Well, looks like the mailing list doesn't like attachments, so I'm
inserting the code at the end of this message...

Since it looks like it won't be possible to make the driver deliver
a clean data stream directly, the next best thing to do IMO is to
implement a remultiplexing filter into VDR. Apparently first recording
an entire broadcast and the nremultiplexing it is not the way to go,
since this makes "time shifting" impossible.

I myself don't know enough about MPEG2 multiplexing to do this,
so I was wondering if somebody on this list might be able to
implement this. Attached is a small C++ class framework with a
description how I believe the remultiplexing filter should work.

Any comments, ideas or suggestions are greatly appreciated.

Klaus

------------------- snip -------------------------------
class cRemuxer {
private:
  // put any members you need for remultiplexing here
public:
  const char *Process(const char *Data, int &Count, int &Result);
  cRemuxer(void);
  ~cRemuxer();
  };

const char *cRemuxer::Process(const char *Data, int &Count, int &Result)
{
  /*
     'Data' points to a chunk of data that consists of 'Count' bytes.
     The 'Process' function shall try to remultiplex as much of the
     data as possible and return a pointer to the resulting buffer.
     That buffer typically is different from the incoming 'Data',
     but in the simplest case (when 'Process' does nothing) might
     as well point to the original 'Data'. When returning, 'Count'
     shall be set to the number of bytes that have been processed
     (i.e. have been taken from 'Data'), while 'Result' indicates
     how many bytes the returned buffer contains.

     'Process' shall do it's best to keep the latency time as short
     as possible in order to allow a quick start of VDR's "Transfer
     mode" (displaying the signal of one DVB card on another card).
     In order to do that, this function may decide to first pass
     through the incoming data (almost) unprocessed, and make
     actual processing kick in after a few seconds (if that is at
     all possible for the algorithm). This may result in a non-
     optimal stream at the beginning, which won't matter for normal
     recordings but may make switching through encrypted channels
     in "Transfer mode" faster.

     In the resulting data stream, a new packet shall always be started
     when a frame border is encountered. VDR needs this in order to
     be able to detect and store the frame indexes, and to easily
     display single frames in fast forward/back mode.

     If the incoming data is not enough to do remultiplexing, a value
     of NULL shall be returned ('Result' has no meaning then). This
     will tell the caller to wait for more data to be presented in
     the next call.

     Any data that is not used during this call will appear at the
     beginning of the incoming 'Data' buffer at the next call, plus
     any new data that has become available.
  */

// Here's the simplest possible implementation of 'Process':

  Result = Count;
  return Data;
}

cRemuxer::cRemuxer(void)
{
  // initialize any members
}

cRemuxer::~cRemuxer()
{
  // free any used memory
}

-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


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