The VideoLAN Forums

Hi everyone,
I'm new to this forum, but I'm pretty sure I'm at the right place to get an answer...
So here is my problem.
I have a DVB-T card on my computer; I have been watching TV for long on it, but now I wanna extend its possibilities. It includes watching on another computer, linked to a projector (so using the projector to watch TV), and watch my local TV channels across a web stream, and a Qt application I have made to tune VLC to the right channel.
Everything in this plan works; you will say "Why did you come here so?" and I'll answer the problem isn't here.
The problem is, when I stream something coming from DVB-T, and that there is even the smallest discontinuity on the TS (there are always as someone in my family never stops sending and receiving SMS, and with an indoor antenna...) desynchronizes audio and video; the audio stays up-to-date but the video gets late, often very late (9-10 seconds). And to resynchronize I have to press "Next" on the local computer or restart the feed with my Qt application.
So what I want to do is make VLC keep the synchronization between video and audio; no matter if the two are late but they must stay synchronized together.
Some techincal details:
- I stream via HTTP, and I have a VLC client
- I'm using VLC 1.1.5 on a Linux 2.6.31.13 box
- I convert down video using this chain: And there's often a "buffer too late for mux input" error being displayed ~100 times a second, beginning when a discontinuity is received in the TS.
How to correct the delay between audio and video while streaming from DVB-T? (That doesn't happen when watching locally)
Thanks by advance
Cocodidou

Well....
If you were using Windows, then I would suggest using command "audio-sync" to correct the problem. As you are not then, take a look here.

http://trac.videolan.org/vlc/ticket/4280
And here
http://trac.videolan.org/vlc/ticket/4315#comment:2

and this post
viewtopic.php?f=4&t=84578
And the link to Launchpad in the above link. May apply to you? If you are "Affected" then click on the affected link on the bug report link.

It would seem that the problem lies elsewhere, ALSA or V4L2?
I'm not a developer so I really don't know.
If you feel the root problem is with ALSA / V4L2 then you might consider raising a bug report against ALSA or V4L2 or both via your linux distro?

Check your Videolan PM for further off topic but related info.

Okay then, firstly thanks for your so quick answer.
So, first, the root problem is just not related to ALSA/V4L2 as it only occurs with DVB-T (a digital source in which audio and video cannot come desynchronized as they are in a unique stream). Then, yes it might be as you said in the PM a ffmpeg issue (I don't have mencoder); my version of ffmpeg is quite old but as it is patched I didn't update it out (it has a patch for French "TNT HD" eac3 Dolby DIgital Plus audio).
Then I'll try to convert the stream using another way; first I'll see if I can patch the newer version of ffmpeg, then I'll look for another solution...
Thanks again
Cocodidou

Multiplexing synchronization is a thorny issue, especially when transcoding - video tends to become late w.r.t. audio. VLC lacks man power at the moment in this area.

I don't believe this is an input/demux issue here.

Would you post back your input string?
Also
Would you post back: make, model, type, chipset ,full specification of your DVB-T card. Any other information on how it delivers its video and audio data to the pc would be very interesting.

From my own experience, capturing via VLC from a Win XP box and then doing a secondary transcode and restream on a linux box (with VLC), I did not see a sync problem. I also did not see a problem when just capturing and playing on a linux box. Only when streaming?
As I have mentioned 1.0.6 did not seem to have this constant sync drift, just minor fluctuations?

Thanks a lot Rémi - I don't believe that it's a demux problem, but still it may be related to transcode... In other words, the wrong piece in this scene would be the transcoder which does not keep video synchronized.
For Greg, here's my intput string: This string is made to stream the channel France 2 HD for example.
My DVB-T receiver is a Pinnacle PCTV 340e board, currently not supported under Linux but I have ported some of Devin Heitmueller's code at http://www.kernellabs.com/blog/?p=1247
to this tarball http://corentin.ferry.free.fr/pctv-340e.tar.gz
It is a DiBCom DiB0700-based device (the DiB0700 here is a USB bridge between a computer and a tuner); the tuner itself is an XCeive XC4000, and there is a Conexant CX25843 analog-to-digital converter which is not supported on this product under Linux because of the v4l2 support lack in the dvb-usb framework. The analog support hasn't yet been done, and no one wants to do it as analog TV progressively disappears, so the need for analog TV tuners is reducing.
It is recognized as "YUANRD PCTV 340e" (maybe Yuan Research & Development has something to do with the manufacturing of this product).

To be more precise, when I stream back a recorded file, there's no delay. The delay is "created" whenever a discontinuity occurs in the TS input (some 4-5 channels at a time). And as someone in my family is always sending and receiving SMS (in France, GSM communications operate in the same frequencies as TV), discontinuity occur every 15-20 seconds; TV is almost unwatchable unless this s*** of cellphone is off.

So an immediate solution would be to throw this cellphone away; I don't see any software solution... I have tried to delay back the audio vs. the video on the client; it worked but it is very difficult to do as the delay is not fixed.

Hi cocodidou,

Maybe you want to take a look at the thread I started:
viewtopic.php?f=14&t=86369

My setup is pretty much like yours: I use a Hauppauge WinTV HVR 900-H to tune in to a DTV channel, transcode it to MP4 and stream it to localhost through HTTP, so my command line options are very close to yours. One of the differences is that I'm using Windows 7 x64 as I wasn't able to make the capture stick work on Linux.

I'm experiencing the same delay problems as you. I recently put the "audio-sync" flag on, as you (Greg didn't seem to notice you already were using it in his first reply), but it is of no use for me; it solves nothing.

Someone suggested it maybe could be a matter with ffmpeg... I doubt it, since in my setup I'm also using ffmpeg independently; that is, to catch the local stream output and re-stream it to a RTMP server (something that VLC is unable to do and a feature I'd be very happy to see ). Well, ffmpeg has its own problems, usually it gets "stuck" when streaming to server, but I haven't been able to notice it inducing any delay or desync problems: if I restart it, the delay will still exist; If I restart VLC, the delay dissapears.

By the way, I don't believe the GSM interferences have much to do. I'm in Spain and I also have the same "buffer too late for mux input" from the beginning, just when I start VLC and tune in the DTV channel, and noone in my house is sending SMS . Don't forget nowadays most cell phones are using UMTS or GPRS as a bare minimum, and I don't think they operate in UHF .

Oh, I also tryied increasing the :dvb-caching param (default=300), but things just worsened (many more different errors). I haven't tryied lowering it.

When my stream is playing for hours, it becomes as serious as MINUTES in delay.

Hello All

( I did initially miss the audio-sync in the first reply....)
Perhaps an academic point now?

I have not seen the problem in Win XP in a capture/transcode/stream or network/transcode/restream over a circa 3hr period. I tend to use bt878 video capture cards + sound card for audio capture, I do not currently have a DVB-T device to try it on.
I will try a capture/transcode/stream and re/transcode/stream in win xp over a longer period, say 12hrs+ in a few days when I have time and post back my findings
The sync drift I saw in Ubuntu 10.10 using VLC 1.1.4 appeared to be a series of step functions (rather than a continious linear drift), It is difficult to say when they occured or what event(s) may have caused them.

I have had my doubts about v4l2/alsa being "The" cause of this sync problem, given the evidence so far? The problem now seems to be including Windows versions to some extent.

I am happy to test and report on any proposed "development" solutions from VideoLan

I have same problem when transcoding and just when I change the samplerate from 48000 to any lower value!.

Strangely, when I save the transcoded stream using VLC to a file and inspect it with media info it show the value of video delay, so VLC should be aware of the sync issue and have access to its details and amount but does not take action to correct it!.

Bondia, I will stream to RTMP server too, could you please explain more how you use ffmpeg in that case? which is the best method to feed ffmpeg with VLC stream and what is the problem you faces and how solved them, also a sample command line will help.

Thanks