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

[Olof Astrand]

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.

I have written a test program that I attatch with this mail. It works both on windows and unix if you have winpcap or pcap installed.
Compile it with g++ -lpcap tsdump.cpp -o tsdumptsdump -port xxx 
if you are using any other port than 5555

Too me it seems
like PCR and PTS are free running and quickly goes out of sync. I think they should be better in sync if one want to see anything on the set-top box.

--------------------

These are some of the error messages that I get
from vlc when streaming.

 

main warning: backward_pts != dts (81413)

main warning: vout warning: early picture
skipped (79756844)

main warning: backward_pts != current_pts
(-81413)

main warning: vout warning: early picture
skipped (79755844)

main warning: received buffer in the future (80079867)
Theese are
the commands I run to capture and stream:

ffmpeg  -f jack 
-ac 2 -i ffmpeg  -ab 128000 -ac 2
-ar 44100 -acodec mp2 -f x11grab -r 25 -s pal -i :0.0 -vcodec mpeg2video -b
5000000 -maxrate 9000000 -minrate 0 -bufsize 1835008 -packetsize 2048  -muxrate 4800000  -qscale 1 
-threads 4 -f mpegts udp://239.255.148.69:5555\?pkt_size=1316

If you don?t
have jack support this is how you stream without sound and at constant bitrate:

ffmpeg  -an -f x11grab -r 25 -s pal -i :0.0 -vcodec
mpeg2video -b 5000000 -maxrate 5000000 -minrate 5000000 -bufsize 1835008
-packetsize 2048   -qscale 1 
-threads 4 -f mpegts udp://239.255.148.69:5555\?pkt_size=1316
This is the ouput of the test program. While
capturing you see the PIDs and approximate rate.

pid 0, 14
Kbps/sec

pid
17,  2 Kbps/sec

pid 256,
4592 Kbps/sec

pid 4095,
14 Kbps/sec----------------------

When you
press Ctrl-c you get a dump of the data collected.

What you
see is 

1)      delta PCR value since last PCR. 

2)      Offset PCR (from the pcap time). 

3)      Within parantheses (Time difference between PCR
and PTS)

1848    -32.939911

1848    -32.994167      (125.407585) (125.447586)

1848    -33.374523      (125.467056) (125.507057) (125.547058)
(125.587059) (125.627052)

1848    -33.355099

1904    -33.334946  (125.667053) (125.707054) (125.747055)
(125.787056) (125.827057)It looks like the PCR is drifting quickly compared to the libpcap time. 33 seconds difference after only a few minutes, and the PTS times are 125 seconds off compared to PCR. 


If I use
vlc for streaming of the data captured by ffmpeg then I get the following
results. It seems like vlc is doing a much better job.

6410    -0.000433       (0.392567) (0.353378) (0.379500)
(0.432567)

6303    0.000056        (0.335589) (0.361711) (0.402533)
(0.387833)

6381    0.000689        (0.371633) (0.343067) (0.369189)
(0.411633) (0.395311)

6381    0.001389        (0.380733) (0.350533) (0.376656)
(0.420733)

6155    -0.000733       (0.334389) (0.392344) (0.360511)

6336    -0.000422
/Olof ?strand

_________________________________________________________________
Windows Live?: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tsdump.cpp
Type: text/x-c++src
Size: 14200 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090603/cc06c967/attachment.cpp>