• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Live streams - ReClock slave to graph reference clock

CiNcH

Member
Thread Starter
Joined
Jun 11, 2008
Messages
22
Likes
0
Got a question concerning live streams. A streaming source filter usually implements the reference clock which is synchronized to the broadcaster's clock (e.g. PCR in a DVB system). Using a clock without synchronization results in A/V playback which is either sligthly slower or faster compared to the broadcaster/encoder (buffer overflow/underrun problem) which is due to different clock speed/drift of two quartz.

Can ReClock be slave to the reference clock within a DirectShow graph? Guess that the whole video synchronization within ReClock won't work any longer then!? So no advantages over the DirectSound renderer any longer..

Could ReClock detect an active reference clock within a source filter and automatically be slave to this clock in this case and only use the internal synchronization mechanism if the clock within the source filter is not used as reference?
 
Last edited:
Got a question concerning live streams. A streaming source filter usually implements the reference clock which is synchronized to the broadcaster's clock (e.g. PCR in a DVB system). Using a clock without synchronization results in A/V playback which is either sligthly slower or faster compared to the broadcaster/encoder (buffer overflow/underrun problem) which is due to different clock speed/drift of two quartz.

Can ReClock be slave to the reference clock within a DirectShow graph? Guess that the whole video synchronization within ReClock won't work any longer then!? So no advantages over the DirectSound renderer any longer..
Correct.

Could ReClock detect an active reference clock within a source filter and automatically be slave to this clock in this case and only use the internal synchronization mechanism if the clock within the source filter is not used as reference?
It already does this - or at least tries to.
 
ReClock does not play well then. I am using DVBViewer with its DVBSource filter acting as reference clock. With ReClock and a sound pre-buffer of 500ms audio and video are completely off. Reducing pre-buffer helps however.

DirectSound also has rate-matching which synchronizes audio output to the reference clock by altering the audio frequency according to how full the buffer is. But it only does this in 75 Hz steps.
 
Last edited:
This is very interesting topic, pls. post your hw specs, that dvb-t/freeair card of yours is internal?
Describe in a little bit more detail your DirectShow/software chain as well.
http://www.dvbviewer.com/en/index.php?page=features

What are the best opensource/freeware alternatives as of today? Haven't been watching this scene for some time..
http://www.progdvb.com/

Quick search: there is anecdotal evidence from 2006 that ProgDVD + BDA drivers work ok w. ReClock:
http://forums.dvbowners.com/index.php?showtopic=6071&view=findpost&p=50668
http://en.wikipedia.org/wiki/Broadcast_Driver_Architecture

Generally, I'd say the dvb-t scene is not that much evolved as the htpc/cinema arena is, that's why opensource/diy drivers/filters are lacking. What also plays a role, is that US/EU/Asia-Pacific prefers slightly different stuff like cable, so not much worldwide coherent interest into this..
 
Last edited:
Try to stay on topic please. I don't want this to become a mess discussing DVB apps and the like.

I am using DVB-S/DVB-S2/DVB-T together with DVBViewer. The hardware does not play a role as every DVB device delivers a TransportStream and the DVBViewer provides a buffer which acts as a smoothing condenser. From this buffer, TS data is fed into the graph via DVBSource filter.

Basically ReClock works with the above limitation. But at least in my opinion it is neither a good idea to tie playback of a live stream to the audio clock nor to a clock derived from the GPU. Playback or A/V processing within the graph should be synchronized to the stream speed to avoid buffer underruns and overflows which is handled by the DVBSource filter, acting as reference clock tied to the PCR. Question is whether ReClock is really a slave to this clock..

I just thought that ReClock may have better rate-matching compared to the DirectSound renderer, which as I already stated only switches audio in 75 Hz steps. So it always has to slow down and speed up audio by a "big" amount and very often to adhere to the stream speed. Most audio hardware only react at 150 Hz changes, which is sometimes audible.
 
Last edited:
You are so funny, how on earth is discussion about dvb-t players/drivers deemed off topic here. Chances are that ReClock may already work in certain configuration, and we can start from there. Probably many people on this board never heard about your dvb-t / progiee, keep it cool.. :p
 
A third party viewpoint: It certainly seems off-topic to me. The thread is about playing live streams through Reclock NOT about dvb players (which were mentioned only as additional info).
 
ReClock does not play well then. I am using DVBViewer with its DVBSource filter acting as reference clock. With ReClock and a sound pre-buffer of 500ms audio and video are completely off. Reducing pre-buffer helps however.

DirectSound also has rate-matching which synchronizes audio output to the reference clock by altering the audio frequency according to how full the buffer is. But it only does this in 75 Hz steps.

Logfile, please. But why are you trying to use ReClock with live streams? DVBViewer has a nice feature which lets you choose between different audio setups. You can use one with, and one without ReClock.
 
I use Graph A/B of course. And ReClock for file only.

Just wanted to see whether ReClock can be slave to another clock in the graph and whether it applies better rate-matching than DirectSound renderer, rate-matching with 150 Hz steps is not too good. What ReClock seems to do is calculate an audio frequency which better matches display refresh rate. If, in case of PAL, refresh rate is a little higher than a multiple of 25, it will speed up audio. So earlier or later we will run out of audio data every now and then because playback is faster relative to the stream. Is this assumpion correct?


(I can't reproduce audio/video async at the moment. Will have to keep an eye on that.)
 
I use Graph A/B of course. And ReClock for file only.

Just wanted to see whether ReClock can be slave to another clock in the graph
It can, but it will (should) disable itself, like in "audio only" mode.
No syncing to the video will be done - to do this, it has to be the reference clock.
and whether it applies better rate-matching than DirectSound renderer, rate-matching with 150 Hz steps is not too good. What ReClock seems to do is calculate an audio frequency which better matches display refresh rate. If, in case of PAL, refresh rate is a little higher than a multiple of 25, it will speed up audio. So earlier or later we will run out of audio data every now and then because playback is faster relative to the stream. Is this assumpion correct?

Absolutely. The solution is to hit pause / play in DVBViewer to force timeshifting, and ReClock will play filne. It can even be used to play PAL at 24fps (reverse PAL speedup) with this method.
 
I would still like to place a feature idea here (no request!!!):

- rate-matching, so varying audio frequency according to the audio buffer fullness within ReClock if it detects a source filter acting as reference clock

Think this could be a great feature within a streaming environment.

BTW, I enabled logging, but no file is created under C:\.
 
Last edited:
I would still like to place a feature idea here (no request!!!):

- rate-matching, so varying audio frequency according to the audio buffer fullness within ReClock if it detects a source filter acting as reference clock

Think this could be a great feature within a streaming environment.

BTW, I enabled logging, but no file is created under C:\.

Because of Vista, W7 & UAC, it has been moved to your "Documents" directory.
 
OK, here we go... Audio is totally off in this case:
 

Attachments

  • reclock_log.zip
    6.5 KB · Views: 4
Back
Top