search

gingerbeur / google-cast-sdk

Automatically exported from code.google.com/p/google-cast-sdk
0 stars 0 forks source link

MPL-0.9.0 HLS cc608 doesn't work #359

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Setup custom receiver to play the following m3u8 stream. (you may need to 
setup CORS in your environment)
http://nlds14.cdnak.neulion.com/nlds_vod/mls/vod/2014/07/11/741521/2_741521_dc_s
j_2014_h_whole_1_ced.mp4.m3u8

2. Toggle closed caption 608 feature in media player 0.9.0.

3. No caption show up.

What is the expected output? What do you see instead?
CC608 should should show up however it doesn't. iPad/iPhone/Mac Safari has no 
issue to turn on CC608.

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

Please provide any additional information below.

Original issue reported on code.google.com by nicevinc...@gmail.com on 13 Aug 2014 at 9:59

GoogleCodeExporter commented 9 years ago 
It looks like in this stream VBI data flag is not set, which causes MPL CC 
decoder to discard the VBI data.  If this check is bypassed, the captions show 
up, but I think MPL is doing the right thing and this bit should be set.

http://www.scte.org/documents/pdf/Standards/ANSI_SCTE%2020%202012.pdf section 
5.5 Picture User Data Syntax

vbi_data_flag 1 bslbf
if (vbi_data_flag) {
  cc_count 5 uimsbf
[...]

Original comment by vadi...@google.com on 14 Aug 2014 at 5:32

GoogleCodeExporter commented 9 years ago

Original comment by anad...@google.com on 14 Aug 2014 at 5:53

GoogleCodeExporter commented 9 years ago 
According to Apple's developer document, its CC608 data in HLS stream is 
specified by ATSC A/72.
https://developer.apple.com/library/ios/documentation/networkinginternet/concept
ual/streamingmediaguide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//app
le_ref/doc/uid/TP40008332-CH102-SW23

If you take a look at the ATSC A/72 document, in section 6.4.2, the caption 
data is specified in ANSI/SCTE 128-1.
http://www.atsc.org/cms/index.php/standards/standards/57-atsc-a72-standard
http://www.atsc.org/cms/standards/a72/A72-Part-1-2014.pdf
http://www.scte.org/documents/pdf/Standards/ANSI_SCTE%20128%202010-a.pdf

And now, if you go deep in ANSI/SCTE 128-1 (section 8, section 8.2.2), the 
format is a little differnt with MPL implementation. There's no VBI flag in 
ANSI/SCTE 128-1.

I don't know why MPL choose to implement ANSI/SCTE 20 2012. So far as I know, 
Adobe Media Server 5 injects the caption data specified by ANSI/SCTE 128 2010 
Section 8.
http://help.adobe.com/en_US/adobemediaserver/devguide/WS5262178513756206232b27a9
1396cda04c9-8000.html

Original comment by nicevinc...@gmail.com on 14 Aug 2014 at 7:01

GoogleCodeExporter commented 9 years ago 
Do you know why reserved bit for your cc_data is set to 0 instead of 1 as 
described by ANSI/SCTE 128?

cc_data() { 
 reserved 1 ’1’ 
 process_cc_data_flag 1 bslbf 
 zero_bit 1 '0' 1
 cc_count 5 uimsbf

Original comment by vadi...@google.com on 14 Aug 2014 at 8:54

GoogleCodeExporter commented 9 years ago 
No, we don't. We set it to '1'.

For instance, 
http://nlds14.cdnak.neulion.com/nlds_vod/mls/vod/2014/07/11/741521/2_741521_dc_s
j_2014_h_whole_1_800_012150.ts

Use 'Hex Editor' to open this file, then you may search binary data '47 41 39 
34 03', now the following is cc_data().

You can see the first byte of cc_data() is 0x42, i.e. 1000 0010.

Original comment by nicevinc...@gmail.com on 14 Aug 2014 at 9:07

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry, my fault, 0x42 is 0100 0010.

Original comment by nicevinc...@gmail.com on 14 Aug 2014 at 9:11

GoogleCodeExporter commented 9 years ago 
Is there any chance you could force the reserved bit to be '1'?

Original comment by vadi...@google.com on 14 Aug 2014 at 9:12

GoogleCodeExporter commented 9 years ago 
I found out the reason why we set the reserved bit to '1'. Take a look at the 
foot at ANSI/SCTE 128 section 8.2.2, it says

==
The syntax and semantics of cc_data() may be moved to CEA-708 [6]. At that 
point this standard should be 
amended to delete this entire section in deference to the CEA-708 definition. 
This syntax is bit-compatible with the 
existing syntax defined by previous versions of CEA-708. 
==

CEA-708 is '0'...
http://en.wikipedia.org/wiki/CEA-708

user_data_type_structure
Length  Name    Type    Default
1 bit (b7)  process_em_data_flag    flag    0
1 bit (b6)  process_cc_data_flag    flag    1
1 bit (b5)  additional_data_flag    flag    0
5 bits (b0-b4)  cc_count    uimsbf  variable
8 bits  em_data
(not in CDP data)   uimsbf  0

Original comment by nicevinc...@gmail.com on 14 Aug 2014 at 9:27

GoogleCodeExporter commented 9 years ago 
Back to the question you asked, I think we could not change that reserved bit. 
The reason is that we have to re-encode all the videos... There are so many 
videos and we also need to 'flush' CDN...

Original comment by nicevinc...@gmail.com on 14 Aug 2014 at 9:29

GoogleCodeExporter commented 9 years ago 
In order to continue addressing this issue, we would like you to open a ticket 
at 

https://support.google.com/cast-developer/contact/google_cast_contact_us?rd=1

There we can have a non-public channel that we can discuss this further with 
you and see if we can resolve the issue for you.

Thanks

Original comment by anad...@google.com on 14 Aug 2014 at 10:20

GoogleCodeExporter commented 9 years ago 
This should be fixed in the next MPL release.

Original comment by vadi...@google.com on 15 Aug 2014 at 8:05

GoogleCodeExporter commented 9 years ago 
I can see the Closed Captions on receiver now. Thanks.

Original comment by nicevinc...@gmail.com on 25 Sep 2014 at 2:15

GoogleCodeExporter commented 9 years ago

Original comment by anad...@google.com on 25 Sep 2014 at 2:34