Rendition Switching Related Pauses in HLS Content Playback

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load an HLS video from our Content
2. Start playing a video stream through the app Interface
3. Notice that there is non-network related rendition switching pausses from 
1-2 seconds

What is the expected output? What do you see instead?
The expected output is smooth continuous playback of video.  The actual output, 
which is not always reproducible at the exact same time-codes, shows choppy 
playback.  IMPORTANT: These are NOT buffer underflows or network related as we 
have good playback in other non-cast HLS players on the same network.

What version of the product are you using? On what operating system?

version 0.9.0 if the Media Player Library
version 2.0.0 of the cast Receiver.js
The latest version of Chromecastt Libraries from Google Play Services for the 
Android Sender SDK

Please provide any additional information below.
As mentioned above, these aren't buffer underflows or standard network issues, 
as playback occurs without issues on other devices (or extrememely rarely)

Original issue reported on code.google.com by squorais...@gmail.com on 28 Aug 2014 at 5:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Could you please turn on media player library DEBUG logging level by calling

cast.player.api.setLoggerLevel(cast.player.api.LoggerLevel.DEBUG);

and post a console log, including where approximately the stutter happens?

If the buffer underflow is ruled out, the problem possibly happens when MPL 
changes the bitrate and starts playing a stream at a different bitrate level.

If the segments in your stream do not start with a keyframe, it could lead to a 
brief "freeze" while the initial non-keyframes are essentially skipped at the 
point when the bitrate changes.

According to the Apple HLS recommendation, segments should start with a key 
frame, please see below:

https://developer.apple.com/library/ios/technotes/tn2224/_index.html

Use at least one IDR-frame per segment (preferably at the start)
In order to have fast startup and seek, you need to have an IDR frame in your 
segment. In H.264 video, IDR refers to Instantaneous Decoder Refresh frames, a 
special kind of I-frame. These indicate to the decoder that no frame occurring 
after an IDR frame depends on any frame that occurs before it. We recommend you 
have at least one IDR frame at the beginning of your segment, because when 
seeking or starting up partway through a live stream the client needs an IDR 
frame to get started. If you put your IDR frames partway into the segment, the 
client cannot start until it finds an IDR frame.

Original comment by vadi...@google.com on 2 Sep 2014 at 9:39

[GoogleCodeExporter]

Based on the specs, each segment should start with a keyframe to avoid this 
issue. We may relax this in future but there is no definite plans at this point.

Original comment by anad...@google.com on 9 Sep 2014 at 9:50

• Changed state: WontFix

[GoogleCodeExporter]

Hello, I am running into the same issue.  It consistently happens at the end of 
the 1st TS segment.  If the master m3u8 only has 1 variant (1 bitrate), then no 
pause is seen.  As soon as the m3u8 has 2 bitrate variants, there is always a 
brief pause at approximately 10 seconds, which is our TS segment duration.  I 
have confirmed that all our TS segments start with a key frame and each key 
frame is an IDR frame.  Any other suggestions on this?  Also, is there any 
recommendations on how many variants we should include in our master m3u8.  As 
I indicated, I see this issue with just 2, however if I introduce more variants 
spaced closer together (approx 250 kbps difference between them), then I see 
the freezes a lot more thorough out the playback.  Please let me know if you 
need any more details.

Original comment by manish...@gmail.com on 4 Dec 2014 at 7:29

[GoogleCodeExporter]

Could you please attach a zip file with the manifests and first 3 segments for 
both renditions?

Original comment by vadi...@google.com on 4 Dec 2014 at 9:01

[GoogleCodeExporter]

Thanks for the quick reply.  I have attached a zip file containing the master 
and media playlists for the 2 renditions (2500 Kbps and 3600 Kbps).  I have not 
included the TS segments as they are AES-128 encrypted.  The key is specified 
in the manifest file.  If you can please try this as is that would be great as 
this is a customer requirement and the freezes are experienced with this set 
up.  If you would like an unencrypted sample, please let me know.

Original comment by manish...@gmail.com on 5 Dec 2014 at 7:33

Attachments:

• BC_Once_Chromecast.zip

[GoogleCodeExporter]

Thank you for the repro stream!  I can reproduce the problem, please keep the 
stream available while we're investigating.

Original comment by vadi...@google.com on 5 Dec 2014 at 8:58

[GoogleCodeExporter]

Definitely.  Its available till Jan 31, 2015.  Thanks!

Original comment by manish...@gmail.com on 5 Dec 2014 at 10:33

[GoogleCodeExporter]

Hello, just wondering if there is any update on this?  Thanks.

Original comment by manish...@gmail.com on 16 Dec 2014 at 5:44

[GoogleCodeExporter]

Hi,
I've been debugging this issue on our side with Vadim. We have downloaded and 
decrypted video streams from comment #6 and the second .tg segment in the 3600 
video stream seems to be malformed. Try playing it with VLC and you'll get 
exactly the same issue. I have debugged this a little further and the root 
cause of the issue seems to be in the incorrect MPEG2 TS stream. In the 
3600_segment1.ts the PAT (Program Association Table) is contained in the second 
TS packet. But the first key video frame of the media segment starts in the 
first TS packet. Our MPEG2 TS parser drops any TS packets until it get the PAT. 
So what happens here is we drop the first TS packet, then get the seconds TS 
packet with PAT, but since we already dropped the first TS packet, we are 
forced to drop the whole first video frame from the H264 bitstream. And because 
of that we can't start video decoding until the next video key frame, which 
happens about 1 second after the start of the segment.
Here is the dvbsnoop output of the first two TS packets of the second media 
segment (decrypted), note that PAT comes in the second packet, and the first 
video frame starts in the first packet, before we have the PAT.

dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ 

------------------------------------------------------------
TS-Packet: 00000001   PID: (Unkown PID), Length: 188 (0x00bc)
from file: 3600_segment1_dec.ts
------------------------------------------------------------
  0000:  47 41 00 31 07 10 00 07  5a 9e 7e 00 00 00 01 e0   GA.1....Z.~.....
  0010:  c5 93 80 80 05 21 00 3f  56 a9 00 00 00 01 09 f0   .....!.?V.......
  0020:  00 00 00 01 67 64 00 20  ac b2 00 a0 0b 76 02 20   ....gd. .....v. 
  0030:  00 00 7d 20 00 1d 4c 11  e3 06 49 00 00 00 01 68   ..} ..L...I....h
  0040:  eb c1 fc b0 00 00 00 01  65 88 84 09 7f e2 3c 6b   ........e.....<k
  0050:  ce 15 62 9d fe dd 8e cb  d9 c2 2c 6f 03 57 e0 eb   ..b.......,o.W..
  0060:  0f be 3f ce 99 07 65 44  93 e5 7c 43 1e fb ea 01   ..?...eD..|C....
  0070:  19 ff 76 80 fa 31 10 e1  9f 5d e3 eb 26 b2 58 d6   ..v..1...]..&.X.
  0080:  2d 81 35 3c 65 c3 f3 22  d7 c5 4c d8 e2 e4 d3 db   -.5<e.."..L.....
  0090:  49 eb 6d de 5c 78 11 e2  44 ab a4 43 ae cf b2 a5   I.m.\x..D..C....
  00a0:  ad 9a 0a 3c 46 4d 78 0b  4e 00 37 73 14 73 74 cb   ...<FMx.N.7s.st.
  00b0:  69 16 bc 43 9c db f2 b5  b8 fd e6 6d               i..C.......m

Sync-Byte 0x47: 71 (0x47)
Transport_error_indicator: 0 (0x00)  [= packet ok]
Payload_unit_start_indicator: 1 (0x01)  [= Packet data starts]
transport_priority: 0 (0x00)
PID: 256 (0x0100)  [= ]
transport_scrambling_control: 0 (0x00)  [= No scrambling of TS packet payload]
adaptation_field_control: 3 (0x03)  [= adaptation_field followed by payload]
continuity_counter: 1 (0x01)  [= (sequence ok)]
    Adaptation_field: 
        adaptation_field_length: 7 (0x07)
        discontinuity_indicator: 0 (0x00)
        random_access_indicator: 0 (0x00)
        elementary_stream_priotity_indicator: 0 (0x00)
        PCR_flag: 1 (0x01)
        OPCR_flag: 0 (0x00)
        splicing_point_flag: 0 (0x00)
        transport_private_data_flag: 0 (0x00)
        adaptation_field_extension_flag: 0 (0x00)
        program_clock_reference:
            baseH: 0 (0x00)
            baseL: 963900 (0x000eb53c)
            reserved: 63 (0x3f)
            extension: 0 (0x0000)
             ==> program_clock_reference: 289170000 (0x113c6250)  [= PCR-Timestamp: 0:00:10.710000]
    Payload: (len: 176)
        ==> PES-stream: 224 (0xe0)  [= ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream]
    Data-Bytes:
          0000:  00 00 01 e0 c5 93 80 80  05 21 00 3f 56 a9 00 00   .........!.?V...
          0010:  00 01 09 f0 00 00 00 01  67 64 00 20 ac b2 00 a0   ........gd. ....
          0020:  0b 76 02 20 00 00 7d 20  00 1d 4c 11 e3 06 49 00   .v. ..} ..L...I.
          0030:  00 00 01 68 eb c1 fc b0  00 00 00 01 65 88 84 09   ...h........e...
          0040:  7f e2 3c 6b ce 15 62 9d  fe dd 8e cb d9 c2 2c 6f   ..<k..b.......,o
          0050:  03 57 e0 eb 0f be 3f ce  99 07 65 44 93 e5 7c 43   .W....?...eD..|C
          0060:  1e fb ea 01 19 ff 76 80  fa 31 10 e1 9f 5d e3 eb   ......v..1...]..
          0070:  26 b2 58 d6 2d 81 35 3c  65 c3 f3 22 d7 c5 4c d8   &.X.-.5<e.."..L.
          0080:  e2 e4 d3 db 49 eb 6d de  5c 78 11 e2 44 ab a4 43   ....I.m.\x..D..C
          0090:  ae cf b2 a5 ad 9a 0a 3c  46 4d 78 0b 4e 00 37 73   .......<FMx.N.7s
          00a0:  14 73 74 cb 69 16 bc 43  9c db f2 b5 b8 fd e6 6d   .st.i..C.......m
==========================================================

------------------------------------------------------------
TS-Packet: 00000002   PID: (Unkown PID), Length: 188 (0x00bc)
from file: 3600_segment1_dec.ts
------------------------------------------------------------
  0000:  47 40 00 18 00 00 b0 0d  00 01 c1 00 00 00 01 f0   G@..............
  0010:  00 2a b1 04 b2 ff ff ff  ff ff ff ff ff ff ff ff   .*..............
  0020:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  0030:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  0040:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  0050:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  0060:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  0070:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  0080:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  0090:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  00a0:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  00b0:  ff ff ff ff ff ff ff ff  ff ff ff ff               ............

Sync-Byte 0x47: 71 (0x47)
Transport_error_indicator: 0 (0x00)  [= packet ok]
Payload_unit_start_indicator: 1 (0x01)  [= Packet data starts]
transport_priority: 0 (0x00)
PID: 0 (0x0000)  [= ISO 13818-1 Program Association Table (PAT)]
transport_scrambling_control: 0 (0x00)  [= No scrambling of TS packet payload]
adaptation_field_control: 1 (0x01)  [= no adaptation_field, payload only]
continuity_counter: 8 (0x08)  [= (sequence ok)]
    Payload: (len: 184)
        ==> pointer_field: 0 (0x00)
        ==> Section table: 0 (0x00)  [= Program Association Table (PAT)]
    Data-Bytes:
          0000:  00 00 b0 0d 00 01 c1 00  00 00 01 f0 00 2a b1 04   .............*..
          0010:  b2 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0020:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0030:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0040:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0050:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0060:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0070:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0080:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0090:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          00a0:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          00b0:  ff ff ff ff ff ff ff ff                            ........
==========================================================

Original comment by serv...@google.com on 6 Jan 2015 at 12:36