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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #1 from shakin at outlook.com <shakin at outlook.com> ---
It should be androidmedia's a bug.

In-depth investigation found that I provided
stream(https://drive.google.com/drive/folders/0B8t5E5lSOxhHbU1ERndPN3lFLU0?usp=sharing),
some frames without PTS (And it's key frames),

as shown below：
gstvideodecoder.c gst_video_decoder_decode_frame() 
--------------------------------------------
01-02 09:29:54.345   PTS 0:00:00.083000000, DTS 0:00:00.000000000, dist 0 
01-02 09:29:54.394   PTS 0:00:00.167000000, DTS 0:00:00.041000000, dist 1 
01-02 09:29:54.412   PTS 0:00:00.125000000, DTS 0:00:00.083000000, dist 2 
01-02 09:29:54.420   PTS 0:00:00.208000000, DTS 0:00:00.125000000, dist 3 
....
01-02 09:30:02.164   PTS 0:00:02.419000000, DTS 0:00:02.335000000, dist 56 
01-02 09:30:02.227   PTS 0:00:02.377000000, DTS 0:00:02.376708333, dist 57 
01-02 09:30:02.252   PTS 99:99:99.999999999, DTS 0:00:02.418416666, dist
58<=noPTS
01-02 09:30:02.298   PTS 0:00:02.544000000, DTS 0:00:02.461000000, dist 59 
01-02 09:30:02.312   PTS 0:00:02.711000000, DTS 0:00:02.502000000, dist 60 

....
01-02 09:30:12.929   PTS 0:00:12.137000000, DTS 0:00:12.053000000, dist 289  
01-02 09:30:12.957   PTS 0:00:12.095000000, DTS 0:00:12.094708333, dist 290  
01-02 09:30:13.051   PTS 99:99:99.999999999, DTS 0:00:12.136416666, dist 291
<=no PTS
....

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

then,let us to track frame #58,
gstvideodecoder.c gst_video_decoder_prepare_finish_frame():
----------------------------------
01-02 09:29:58.415   0xab85baa0 (#0) sync:1 PTS:0:00:00.083000000
DTS:0:00:00.000000000 
01-02 09:29:58.430   0xab3643f0 (#2) sync:0 PTS:0:00:00.125000000
DTS:0:00:00.083000000 
01-02 09:29:58.435   0xab85b9f8 (#1) sync:0 PTS:0:00:00.167000000
DTS:0:00:00.041000000 
...

01-02 09:30:39.734   0xab512690 (#873) sync:0 PTS:0:00:36.620000000
DTS:0:00:36.41100000
01-02 09:30:39.901   0xab512738 (#876) sync:0 PTS:0:00:36.578000000
DTS:0:00:36.53600000
01-02 09:30:39.903   0xab26cb48 (#879) sync:0 PTS:0:00:36.661000000
DTS:0:00:36.66170833
01-02 09:30:40.085   0xab512000 (#878) sync:0 PTS:0:00:36.703000000
DTS:0:00:36.62000000
01-02 09:30:40.086   0xac4675e8 (#880) sync:0 PTS:0:00:36.745000000
DTS:0:00:36.70300000
01-02 09:30:40.090   0xab26cbf0 (#877) sync:0 PTS:0:00:36.787000000
DTS:0:00:36.57800000
01-02 09:30:40.109   0xab3643f0 (#881) sync:0 PTS:0:00:36.953000000
DTS:0:00:36.74500000
01-02 09:30:40.111   0xab85baa0 (#58) sync:1 PTS:99:99:99.999999999
DTS:0:00:02.41841666

 <= Ooops .... #58　traversed to about #881 ....
This will cause　GstVideoDecoder try to fix the timestamp, getting worse...


01-02 09:30:40.233   0xab364540 (#883) sync:0 PTS:0:00:36.828000000
DTS:0:00:36.82870833
01-02 09:30:40.235   0xab26cd40 (#882) sync:0 PTS:0:00:36.870000000
DTS:0:00:36.78700000
01-02 09:30:40.273   0xab26c9f8 (#884) sync:0 PTS:0:00:36.912000000
DTS:0:00:36.87000000
01-02 09:30:40.274   0xab3885e8 (#886) sync:0 PTS:0:00:37.037000000
DTS:0:00:36.95300000
01-02 09:30:40.366   0xac4673f0 (#887) sync:0 PTS:0:00:36.995000000
DTS:0:00:36.99470833

----------------------------------
The reason for this issures is that the following code is logically wrong:
/sys/androidmedia/gstamcvideodec.c
@@ -682,7 +682,7 @@ _find_nearest_frame (GstAmcVideoDec * self, GstClockTime
reference_timestamp)
       best_id = id;
       ...
       timestamp = id->timestamp;
       ...
       /* For frames without timestamp we simply take the first frame */
-      if ((reference_timestamp == 0 && timestamp == 0) || diff == 0)

As explained in the comment, if there is no PTS, we should take the first
frame,
and then let it have the opportunity to amend PTS in _prepare_finish_frame().
But,<timestamp == 0>should never be true, it should be compared with -1 rather
than 0.

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