[Bug 780190] New: HLS stream playback is not smooth with 1.11.2 (vlc, ffplay ok)

Fri Mar 17 12:04:52 UTC 2017

https://bugzilla.gnome.org/show_bug.cgi?id=780190

            Bug ID: 780190
           Summary: HLS stream playback is not smooth with 1.11.2 (vlc,
                    ffplay ok)
    Classification: Platform
           Product: GStreamer
           Version: 1.11.2
                OS: Linux
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: shakin at outlook.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

http://gstreamer-devel.966125.n4.nabble.com/HLS-stream-playback-is-not-smooth-with-1-11-2-vlc-ffplay-ok-td4682224.html

Hi,I'm working  with 1.11.2, when playing some HLS stream,
obviously can  feel the playback is not smooth, it should be drop frame.
----
....
01-01 08:04:00.591   944  5883 W [gstbasesink.c:2901] <basesink> warning: A lot
of buffers are being dropped.
....
01-01 08:04:02.042   944  5881 V [gstvideodecoder.c:3121] <videodecoder>
accepting buffer inside segment: 0:00:02.043000000 0:00:02.084708333 seg
0:00:00.000000000 to 99:99:99.999999999 time 0:00:00.000000000
01-01 08:04:02.042   944  5881 D [gstvideodecoder.c:3155] <videodecoder>
Dropping frame due to QoS. start:0:00:02.043000000 deadline:0:00:02.043000000
earliest_time:0:00:05.011717403
...

----
On Android, just drop frames, the screen gives a slight sense of jitter.
On PC, more serious, after about 45s,video frame freezes/hangs...

Here is one of the HLS stream:
https://drive.google.com/drive/folders/0B8t5E5lSOxhHbU1ERndPN3lFLU0?usp=sharing

Drop frames should not be performance-related,
 video specifications are as follows:
------
 Duration: 00:03:22.00, start: 567.273000, bitrate: 0 kb/s
  Program 0
    Metadata:
      variant_bitrate : 0
    Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv,
bt709), 1200x504, 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
    Metadata:
      variant_bitrate : 0
    Stream #0:1: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 44100 Hz,
stereo, fltp
    Metadata:
      variant_bitrate : 0

------
I extracted the source file audio/video pts with ffmpeg, the interval between
the two frames are about 4000,it looks like normal.

ffprobe -show_frames -select_streams a:0 -i 
http://10.9.44.131/issures/iqiyi/index.m3u8 > ~/Desktop/audio.info

ffprobe -show_frames -select_streams v:0 -i 
http://10.9.44.131/issures/iqiyi/index.m3u8 > ~/Desktop/video.info
------
        pts      diff(PTS(n) - PTS(n-1))
pkt_pts 51057810 4230
pkt_pts 51062040 4140
pkt_pts 51066180 4230
pkt_pts 51070410 4140
....
pkt_pts 51166530 4140
pkt_pts 51170670 4230
pkt_pts 51174900 4140
....

-------
，But gstreamer tsdemux.c gst_ts_demux_record_pts   out of the pts is like this:
-----
01-02 01:18:21.227  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51153930 at offset 152092      
01-02 01:18:21.403  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51229170 at offset 217892      

   <= diff= 51229170-51153930 = 75240

01-02 01:18:21.608  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51287670 at offset 280308      
   <= diff= 51287670 - 51229170 = 58500
01-02 01:18:21.649  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51316920 at offset 294220
   <= diff = 51316920 - 51287670 = 29250      
01-02 01:18:21.652  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51321150 at offset 294972      
   <= 51321150 - 51316920 = 4230
01-02 01:18:21.674  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51333660 at offset 304184      
01-02 01:18:21.678  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51337890 at offset 305124      
01-02 01:18:21.681  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51342030 at offset 305876      
01-02 01:18:21.804  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51404760 at offset 352876      
01-02 01:18:21.926  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51463260 at offset 392544      
01-02 01:18:21.933  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51467400 at offset 393296      
01-02 01:18:21.957  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51471630 at offset 400816      
01-02 01:18:21.960  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51475770 at offset 401568      
01-02 01:18:21.963  4289  4863 tsdemux.c:1973] <tsdemux> pid 0x0101 raw
pts:51480000 at offset 402320      

-----

More,
(1)
In 
https://drive.google.com/drive/folders/0B8t5E5lSOxhHbU1ERndPN3lFLU0?usp=sharing
,
Some ts file  two adjacent pcr interval of 8s, which should be regarded as a
problem well?

1. PCR:15314130000(00:09:27.190) PTS:51054570 DTS:51047100
2. PCR:15488685000(00:09:33.655) PTS:51636420 DTS:51628950  <= diff 6s
3. PCR:15713892000(00:09:41.996) PTS:52387200 DTS:52379640  <= diff 8s
...
(2) m3u8 file containing EXT-X-DISCONTINUITY tags

In tsdemux, the calculation of the timestamp
is associated with the pcr, if the file itself pcr is not continuous,
or the interval is too large, will lead to gstreamer A/V synchronization
issure?
Is it possible, do not use pcr to recalculate timestamp, just rely on pts / dts
in the
file as a basis for handling synchronization?

Vlc and ffplay can smooth play, where is a problem gstreamer?May it be
timestamp related? Or gstreamer can not properly handle EXT-X-DISCONTINUITY?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.