[FFmpeg-devel] [BUG] PCR, PTS drift for mpegts streams. Black screen on set-top box.

Vladimir Pantelic pan
Thu Jun 4 23:08:32 CEST 2009

Alexandre Ferrieux wrote:
> Baptiste Coudurier wrote:
>> Hi,
>> On 6/3/2009 8:17 AM, Olof Astrand wrote:
>>> Hello,
>>> I have been trying to get ffmpeg to stream a screen capture (x11grab)
>>> to a set top box. Unfortunately ffmpeg has not been so successful so
>>> far. It seems like mpegtsenc.c does not set or calculate PCR
>>> correctly.
>>> I have not gone into the details yet but would really like some help
>>> or pointers if someone is working on this problem, or know anything
>>> about it.
>>> When I set ts->cur_pcr to the current pts for the audio stream like
>>> this:
>>> + if (pts != AV_NOPTS_VALUE) {
>>> + ts->cur_pcr = pts-90000;
>>> + }
>>> Then at I get an image for a while, otherwise the image on the set
>>> top box is black.
>> PCR is related to DTS, and yes this is a known problem. It should work
>> better in CBR mode, ie with rc_max_rate set and respected.
> Baptiste, can you please give the explicit command-line switches and
> values to use for the CBR mode ?
> Also, an IP box is not likely to expect the stuffing used to reach the
> constant bitrate, so it might not fully work, right ?
>> A fully working buffering model for the TS muxer is needed, patch very
>> welcome.
> The problem is that the real experts here are you, Mans, Michael... what
> can we do to help you give this a higher priority ? Do you need further
> characterizations of the problem, or is every aspect of it well known ?
> FWIW, here in my company, this very problem makes us dependent on vlc
> for TS muxing, which induces extra latency and instability (vlc has bugs
> too, though fewer in the TS muxer :-P ). So it is THE dark spot about
> ffmpeg which is absolutely perfect otherwise.

well, you being inside a not so small company could convince said company
to sponsor somebody to do that work, given that you need it so badly, no?

More information about the ffmpeg-devel mailing list