Hi
Johannes Stezenbach wrote:
>>Hmm, assume that is a flag in the mpeg-2 ts stream. I'll try to
>>see if I can extract it from my demuxer. I'm not an expert here,
>>but maybe I can find something on Google.
> It's the first bit after the lenght field in the adaptation field,
> which is part os the TS header for the stream carrying the PCR.
Ok, I should be able to find that.
I assume that if I see a discontinuity_indicator bit set, then
it is safe to assume that the current PTS has little or no
connection to the previous PTS. For me that would mean restart my
transcoding (MPEG-2 to MPEG-4).
>>>- how does your libmpeg2 based decoder app sync to the dvbstream
>>> transmitter to ensure buffers never over/underrun?
>>Ehh ! Come again ! Not sure what you mean !
>>I demux the DVB MPEG-2 TS stream continously on a fast enough system, then
>>feed the video packets to libmpeg2 and the audio packets to LAME. Which
>>buffers should/could get over/underrun ?
>
> The broadcaster sends e.g. 25 frames/sec, if you playback without
> synchronizing your clocks at e.g. 24.95 frames/sec your buffer
> will eventually run full. (Instead of synchronizing clocks you
> could also monitor buffer fullness and drop or repeat frames
> when the buffer runs full/emtpty). Same for the audio. Additionally,
> for software playback audio and video clocks are not synced so
> you have to compensate for audio and video playing back at
> slightly different speeds (by compaing PTSs and dropping/repeating
> frames).
As such, I don't use an interim buffer in that sense you are
describing and I don't have a clock difference issue either.
In my decoder, I read the RTP packets from the network as fast
as possible and hook them onto a linked list. In another thread,
I read from the linked list, demux and decode as fast as possible.
Output is then time stamped relative to the original PTS and feed
to my encoder (MPEG-4). In this setup, output is linked to the
original streams clock. Later of course, somebody will play the
streams with a time base slightly different from the source, but
that is of no consequence here since I see the PTS jump already in
the decoding process.
So my conclusion is that either does CD broadcast streams with frequent
drops in PTS (not so likely) or a collection of TS packets gets frequently
dropped by the receiver. Lets try to look at some scenarios.
a) What happens, if dvbstream runs slower than needed. In theory
data would start queueing on the board. That would eventually
lead to either
1) a single large drop (PTS jumps) followed by a stable
period followed by a large drop etc.
or
2) a stable PTS until receivers buffers runs full followed
by many small drops (small PTS jumps) in a successive manner.
a1) is what I observe, but dvbstream runs as fast as possible and
there is a lot of processing power left.
Is there a way for an application like dvbstream to query the
API for lost data ? E.g. did we read fast enough from the device ?
Next scenario.
b) What happens if the CONAX decryption can't run at the required speed.
That would lead to either
1) a single large drop (PTS jumps) followed by a stable
period followed by a large drop etc.
or
2) a stable PTS until receivers buffers runs full followed
by many small drops (small PTS jumps) in a successive manner.
b1) is what I observe, but then many others should have noticed that
effect. Notice that I run dvbstream with 'nice --12', eg. at a higher
priority. Can that affect the user space CA process ?
1567 ? SW 0:00 kdvb-ca-1:0
1681 ? SW 0:00 kdvb-ca-3:0
and somehow starve them ? Idle CPU power though is a vailable.
Can you think of any other cause ?
> You could test if it works to just save the stream from RTP
> from a file, and then playback the file with mplayer/xine.
Will try that, but they might try to compensate for errors.
Kind regards
--PMM
+----------------------------------------------------------+
| Kabel-TV over Internettet -- http://www.streamtv.dk/ |
+----------------------------------------------------------+
