Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: bitstreamout-0.48pre5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 29 October 2003 12:43, Dr. Werner Fink wrote:
> On Wed, Oct 29, 2003 at 01:21:51AM +0200, Sven Goethel wrote:
> > negativ value: pts > stc: audio is earlier than video
> > positiv value: stc > pts: audio arrives too late
> >
> > if the value is negativ - earlier - keep in mind,
> > that still some time (1-5 ms) will be taken to:
> > - put the data to spdif (about 1ms)
> > - xform the data to pcm (mp2 only, about 1-5ms)
>
> A difference of +/- 5 ms you can ignore (10 ms are 33cm) ... most
> people are not able to distinguish between +/- 5 ms if all channels
> have the _same_ offset. Only difference between e.g. left and
> right channels are significant and this is never the case.
>
fine ..
> > especially the zdf ac3 case looks promising,
> > 'cause audio arrives here always earlier.
> > e.g. ac3 can be made in sync via stc diff usleep !
> > (be sure to set bitstreamout option delay to zero)
>
> Hmmm ... what so you think about not usleep(ing) but simply
> playing silence.
ok .. please point me to the silence call in spdif ..
and you are right .. usleep distorts audio out ..
>
> > but all mp2 cases are about 50ms too late,
> > you can ignore the "earlier" values here .. 'cause
> > extra time is needed for decoding - so no action is taken here.
>
> How long does decoding take?
>
the timings in the log file are after fetching the blocks
outta the ringbuffer and _before_ decoding.
decoding itself takes about 1-4ms ..
> > testing the audio mp2 sync, with audio overlay listening
> > - - listening to sndcard audio-out: parallel mp2 out and analog loop
> > through - you will hear a little echo about 50-200ms .. das bad.
>
> This is really bad.
>
> > so the final question is:
> >
> > why appears ac3 audio "in time" ( -5ms ),
> > but mp2 audio always too late ( 50ms and more ) ???
>
> Hmmm ... you need some recordings to analyse the bitstream its
> self. I'll append my current xlist.c C++ program which is able
> to show PTS of the audio, video and ps1 streams. should be
> compiled with
>
> g++ -O2 -pipe -funroll-loops -Wall -D_GNU_SOURCE -o xlist xlist.c
>
> you can simply do
>
> xlist 001.vdr | less -S
>
> or
>
> xlist -s 001.vdr | less -S
>
> to analyse the stream (xlist -h shows the possible options).
> How the other channels do their streams (Sat1, Pro7 also uses AC3)?
>
> > stc-pts_ac3_zdf.txt
> > PTSDIFF stc-pts: 19741107ms - 19741112ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19741267ms - 19741272ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19741427ms - 19741432ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19741587ms - 19741592ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19741747ms - 19741752ms = -5ms, slept 12ms
> > PTSDIFF stc-pts: 19741907ms - 19741912ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19742067ms - 19742072ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19742227ms - 19742232ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19742387ms - 19742392ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19742547ms - 19742552ms = -5ms, slept 12ms
> > PTSDIFF stc-pts: 19742707ms - 19742712ms = -5ms, slept 13ms
> > PTSDIFF stc-pts: 19742867ms - 19742872ms = -5ms, slept 13ms
>
> Continous stream, perfect.
>
> > stc-pts_mp2_ard.txt
> > PTSDIFF stc-pts: 9708836ms - 9708846ms = -10ms,
> > PTSDIFF stc-pts: 9708914ms - 9708918ms = -4ms,
> > PTSDIFF stc-pts: 9708988ms - 9709014ms = -26ms,
> > PTSDIFF stc-pts: 9709106ms - 9709086ms = 20ms, mp2dec delay 20ms
> > PTSDIFF stc-pts: 9709154ms - 9709158ms = -4ms,
> > PTSDIFF stc-pts: 9709219ms - 9709230ms = -11ms,
> > PTSDIFF stc-pts: 9709346ms - 9709302ms = 44ms, mp2dec delay 44ms
> > PTSDIFF stc-pts: 9709372ms - 9709374ms = -2ms,
> > PTSDIFF stc-pts: 9709447ms - 9709470ms = -23ms,
> > PTSDIFF stc-pts: 9709522ms - 9709542ms = -20ms,
> > PTSDIFF stc-pts: 9709602ms - 9709614ms = -12ms,
> > PTSDIFF stc-pts: 9709671ms - 9709686ms = -15ms,
> > PTSDIFF stc-pts: 9709748ms - 9709758ms = -10ms,
> > PTSDIFF stc-pts: 9709858ms - 9709830ms = 28ms, mp2dec delay 28ms
> > PTSDIFF stc-pts: 9709897ms - 9709926ms = -29ms,
> > PTSDIFF stc-pts: 9709984ms - 9709998ms = -14ms,
> > PTSDIFF stc-pts: 9710082ms - 9710070ms = 12ms, mp2dec delay 12ms
> > PTSDIFF stc-pts: 9710130ms - 9710142ms = -12ms,
> > PTSDIFF stc-pts: 9710203ms - 9710214ms = -11ms,
> > PTSDIFF stc-pts: 9710338ms - 9710286ms = 52ms, mp2dec delay 52ms
> > PTSDIFF stc-pts: 9710348ms - 9710382ms = -34ms,
> > PTSDIFF stc-pts: 9710450ms - 9710454ms = -4ms,
> > PTSDIFF stc-pts: 9710530ms - 9710526ms = 4ms, mp2dec delay 4ms
> > PTSDIFF stc-pts: 9710574ms - 9710598ms = -24ms,
> > PTSDIFF stc-pts: 9710690ms - 9710670ms = 20ms, mp2dec delay 20ms
> > PTSDIFF stc-pts: 9710734ms - 9710742ms = -8ms,
>
> OK ... this could be handled by buffering (ring buffer _and_ hw
> buffer of the sound card). But IMHO the timing of this audio stream
> is broken (as all channels on this transponder) ... it seesm that
> ARD has changed their encoder. Currently I hear that the audio
> on all channels on transponder 11837 is shuttering due to this bad
> timing. Only if you catch a small delay at start you're able
> to smooth out the unstable audio stream by buffering it.
yep .. bad timings
stuttering audio on normal playout either
as i said the data is taken from the ringbuffer,
in the case of late audio the ms are skipped (mp2dec delay),
then again the audio early for a few periods ..
the dPTS is 72ms const. but the dSTC variants depending on
the taken action (skip data or not), but the problem is that
STC grow more than PTS so audio delays ..
>
> > stc-pts_mp2_zdf.txt
> > PTSDIFF stc-pts: 19657305ms - 19657308ms = -3ms,
> > PTSDIFF stc-pts: 19657474ms - 19657476ms = -2ms,
> > PTSDIFF stc-pts: 19657644ms - 19657644ms = 0ms,
> > PTSDIFF stc-pts: 19657809ms - 19657812ms = -3ms,
> > PTSDIFF stc-pts: 19657985ms - 19657980ms = 5ms, mp2dec delay 5ms
> > PTSDIFF stc-pts: 19658153ms - 19658148ms = 5ms, mp2dec delay 5ms
> > PTSDIFF stc-pts: 19658318ms - 19658316ms = 2ms, mp2dec delay 2ms
> > PTSDIFF stc-pts: 19658488ms - 19658484ms = 4ms, mp2dec delay 4ms
> > PTSDIFF stc-pts: 19658657ms - 19658652ms = 5ms, mp2dec delay 5ms
> > PTSDIFF stc-pts: 19658829ms - 19658820ms = 9ms, mp2dec delay 9ms
> > PTSDIFF stc-pts: 19658992ms - 19658988ms = 4ms, mp2dec delay 4ms
>
> You will not hear/see a difference without comparison (your test
> above with the echo effect).
so .. for this case, as well on recordings it works.
just the action,skipping audio -> mp2dec delay, stutters audio,
but you can see - without skipping these audio ms,
the audio will gets later and later .. about 1-2ms,
which is about the decoding time itself.
so .. here is a little brainstorming:
+++
.. could only be managed by holding the video itself buffered
to have a chance to sync a/v completly by our self (-> transport ?).
-> too complicated
+++
or this will prove, that the incremental delay of decoding mp2->pcm
won't make it possible to have a a/v sync.
-> hopefully not ;-)
+++
or the ringbuffer code usage is wrong at live-view (channels.c).
well on replay mode, the mp2->pcm is really done at playside, by the
player thread - which plays video as well.
but on live, the rinbuffer taker - spdif pusher does all this work,
which might be wrong ..
-> i will test this
+++
hmm .. or else ;-)
>
>
> Werner
sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/oG/fHdOA30NoFAARAoQjAJ9MKInUny5PPgP79P8L63MDjia0zgCfVyum
cyhkFhSafTZIP3qPCvzrETo=
=nop2
-----END PGP SIGNATURE-----
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.
Home |
Main Index |
Thread Index