gstreamer/gst/mpegtsdemux/TODO
Janne Grunau 22ecf13e42 mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey
with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-17 17:56:59 +01:00

117 lines
4.2 KiB
Text

mpegtsparse rebasing
--------------------
Rationale :
-----------
mpegtsparse code is more sane to handle and work with.
We need a modular demuxer
We need to avoid duplicating code regarding mpeg-ts in a gazillion
elements and allow easy creatiof new elements.
Battleplan :
------------
* Figure out code from mpegtsparse which would be also needed for a
mpeg-ts demuxer (ex: packet/psi/pcr parsing).
* Extract common code into a base mpegtsbase class.
* Refactor mpegtsparse to subclass that base class.
* Create a minimalistic demuxer that creates pads (based on PSI info)
and outputs ES packets (let's say mpeg audio and video to start with)
Potential subclasses :
----------------------
* MpegTSParse : Program splitter. Given an incoming multi-program
mpeg-ts stream, it can provide request pads for each program. Each
of those pads will contain the ts packets specific to that program.
* TSDemux : Program demuxer. Given an incoming single or multi-program
mpeg-ts stream, it will reconstruct the original Program Streams of
the selected program and output them on dynamically created pads.
* HDVSplitter : Given an incoming HDV mpeg-ts stream, it will locate
the beginning of new scenes and output a mpeg-ts stream with the
PAT/PMT/AUX packets properly ordered and marked with DISCONT, so
that the following pipeline will automatically cut up a tape dump
into individual scenes:
filesrc ! hdvsplit ! multifilesink next-file=discont
Code/Design common to a program-spliter and a demuxer :
-------------------------------------------------------
* Parsing TS packets
* Establishing PAT/PMT mapping
* Handling the notions of Programs/Streams
* Seeking ?
One proposal... would be to have the base class automatically create
all the structures (and relationships) for the following objects:
* Programs (from PAT/PMT, dunno if it could come from something
else)
* Program id
* Streams contained in that program (with links to them)
* Which stream contains the PCR
* Metadata ?
* Streams (ideally... in a table for fast access)
* We want to be able to have stream-type specific information
easily accessible also (like mpeg video specific data)
* Maybe some other info ???
The subclasses would then be able to make their own decision based
on those objects.
Maybe we could have some virtual methods that will be called when a
new program is detected, a new stream is added, etc...
It is the subclass who decides what's to do with a given packet once
it's been parsed.
tsparse : forward it as-is to the pad corresponding to the program
tsdemux : forward it to the proper PS parser
hdvsplit : ?
Ideas to be taken into account for a proper demuxer :
-----------------------------------------------------
* Push-based (with inacurrate seeking)
* Pull-based (with fast *AND* accurate seeking)
* Modular system to add stream-type specific helper parsing
* Doesn't have to be fully fledged, just enough to help any kind of
seeking and scanning code.
* ...
Problems to figure out :
------------------------
* clock
Needed for proper dvb playback. mpegtsdemux currently does internal
clock estimation... to provide a clock with PCR estimations.
A proper way to solve that would be to timestamp the buffers at the
source element using the system clock, and then adjusting the PCR
against those values. (i.e. doing the opposite of what's done in
mpegtsdemux, but it will be more accurate since the timestamping is
done at the source).
Bugs that need fixing :
-----------------------
* Perfomance : Creation/Destruction of buffers is slow
* => This is due to g_type_instance_create using a dogslow rwlock
which take up to 50% of gst_adapter_take_buffer()
=> Bugzilla #585375 (performance and contention problems)
Code structure:
MpegTSBase
+--- MpegTSParse
+--- TSDemux
Known limitations and problems :
--------------------------------
* mpegtspacketizer
* Assumes 188 bytes packets. It should support all modes.
* offset/timestamp of incoming buffers need to be carried on to the
sub-buffers in order for several demuxer features to work correctly.
* mpegtsparser
* SERIOUS room for improvement performance-wise (see callgrind)