Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] VDR plugins - RFC - audio handling
Hi Klaus, hi all
I have a wish. For the new version, i would like to be able to support
multiple audio out devices for all players (VDR, DVD, VCD, ...).
Currently we support the primary DVB card and one additional external device
via the '-a' parameter.
This sheme nad the current implementation of it has some limitations:
- only 2 audio output channels (might be enough, but it is a limitation
nevertheless)
- for AC3 playback over soundcard, audio decoding has to be done in the
output thread, possibly introducing A/V sync problems
- no control over audio buffer (an thereby audio delay) in external AC3 tools
- control information available on the input side can not be passed to the
external tool, again resulting in audio sync problems
- audio output currently (StipAudioPackets) is to comlicated and unflexible
Some of those limitations have already been addressed in some way or the other
in the current patches. But IMHO a more generic and general solution is
needed.
Goals for a new scheme should be:
- be able to use the same audio output processing methods for all players
- have the output side only perform the necessary hardware setup, A/V
syncing and audio packet routing
- have all major processing being done on the input side, this also applies
to audio channel selection when multiple audio tracks are available
- be able to pass control messages from the imput to the output thread
directly
For that to work, the most important change for vdr will be to mark every
audio packet on the input side with a destination device id and packet type
(DD, DTS, PCM, MPEG), with 0 (zero) being the DVB card and any id > 0 being
an additional device handled by some kind of audio plugin.
This will have the biggest impact on the transfer mode as it mostly handles
data as a transparent data stream.
I see two possible ways to attach such a device id to audio packets. We could
always use the frame buffers and make the device id part of the frame
attributes.Or, we always remux all PRIVATE_STREAM2 packets, so that the first
bytes of the payload can contain the additional information - much like on
DVD. Some PES packet analyzing would still be needed on the output side (and
i'm not sure wether i like that or not).
Any comments?
Andreas
--
Andreas Schultz <aschultz@cs.uni-magdeburg.de>
Student of computer science
"In accordance with plans for Linux OS world domination
infiltration of governments is vital (:-))."
Home |
Main Index |
Thread Index