google / universal-dash-transmuxer Goto Github PK

Issue and steps to reproduce the problem

We're using UDT together with Widevine iOS CDM to play DASH on iOS devices. Video and audio streams are transmuxed correctly, but we have a problem with subtitle streams (tried web-vtt and srt). We've extended Stream, MpdParser and PlaylistBuilder classes in the Widevine iOS example project to support textual streams, but Udt_ParseDash funciton returns kDashToHlsStatus_BadDashContents when trying to parse a textual stream. Is the transmuxer able to transmux a textual stream at all?

What is the expected result?

HLS with subtitles.

What happens instead?

Udt_ParseDash() returns kDashToHlsStatus_BadDashContents.

Additional info

Generated master playlist

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA:URI="0.m3u8",TYPE=AUDIO,GROUP-ID="audio",NAME="audio0",DEFAULT=NO,AUTOSELECT=YES
#EXT-X-MEDIA:URI="1.m3u8",TYPE=SUBTITLES,GROUP-ID="subtitles",NAME="subtitles1",DEFAULT=NO,AUTOSELECT=YES
#EXT-X-STREAM-INF:BANDWIDTH=400000,CODECS="avc1.4d401e",RESOLUTION=720x480,AUDIO="audio",SUBTITLES="subtitles"
2.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=544775,CODECS="avc1.4d401e",RESOLUTION=720x480,AUDIO="audio",SUBTITLES="subtitles"
3.m3u8

Log

2018-08-02 14:53:13:687 [28275:1839693] Downloading data from https://../ct24-9_subtitle_init_2.mp4.
2018-08-02 14:53:13.709221+0800 [28275:1839689] Downloading data from https://../ct24-9_subtitle_init_2.mp4.
2018-08-02 14:53:14.047118+0800 [28275:1839693] parseInitializationData
2018-08-02 14:53:14.047410+0800 [28275:1839693] Udt_ParseDash(..., DASHMediaType: 5, ...)
2018-08-02 14:53:14.047861+0800 [28275:1839693] {
	'Message':'Unknown Media Type',
	'File':'/var/lib/jenkins/workspace/iOS_CDM_Tests/udt/library/dash_to_hls_api.cc',
	'Line':225,
	'Reason':'Missing Audio/Video Box',
	'Extra':''
}
2018-08-02 14:53:14.048015+0800 [28275:1839693] status: 3, status == kDashToHlsStatus_BadDashContents: 1
2018-08-02 14:53:14:048 [28275:1839693] Error:
     failed to parse dash
2018-08-02 14:53:14.048344+0800 [28275:1839689] Error:
     failed to parse dash
2018-08-02 14:53:14.048608+0800 [28275:1839693] 0-Box<ftyp:32 Unknown> 
32-Box<moov:669 Movie> 
   32-Box<mvhd:108 Movie Header> Version 0 flags 0 Creation Time: 3616030889 Modification Time: 3616030889 Timescale: 1000 Duration: 0
   140-Box<meta:137 Unknown> 
   277-Box<trak:376 Track> 
      277-Box<tkhd:92 Unknown> 
      369-Box<mdia:276 Media> 
         369-Box<mdhd:32 Movie Header> Version 0 flags 0 Creation Time: 3616030889 Modification Time: 3616030889 Timescale: 1000 Duration: 0 Language code: 12
         401-Box<hdlr:44 Unknown> 
         445-Box<minf:192 MediaInformation> 
            445-Box<dinf:36 DataInformation> 
               445-Box<dref:28 Unknown> 
            481-Box<stbl:136 SampleTable> 
               481-Box<stsd:60 SampleDescription> Version 0 flags 0 descriptions: 1
                  481-Box<wvtt:44 Unknown> 
               541-Box<stts:16 Unknown> 
               557-Box<stsc:16 Unknown> 
               573-Box<stsz:20 SampleTable> Version 0 flags 0 samples: 0
               593-Box<stco:16 Unknown> 
            617-Box<sthd:12 Unknown> 
   653-Box<mvex:40 MovieExtend> 
      653-Box<trex:32 TrackExtends> Version 0 flags 0 Track ID:1 Default Sample Description Index:1 Default Duration:0 Default Size:0 Default Flags:0
2018-08-02 14:53:14:049 [28275:1839693] Error:
     failed to initialize stream from https://../ct24-9_subtitle_init_2.mp4
2018-08-02 14:53:14.049283+0800 [28275:1839735] Error:
     failed to initialize stream from https://../ct24-9_subtitle_init_2.mp4

When using this as part of the Widevine iOS libraries (and probably for other cases as well) the psshHandler is only called for the first PSSH box. This means that if the first box is an unsupported box for the platform, playback will fail as it will be impossible to setup the CDM components.

Either setting the PSSH handler should accept a UUID identifier for which keysystems to listen to, or it should at the very least call the handler for each of the keysystems present.

So most likely https://github.com/google/universal-dash-transmuxer/blob/master/library/dash_to_hls_api.cc#L223 needs to use FindDeepAll and then iterate over the contents.

According to the latest version(3.2) of guidelines for implementation: DASH-IF interoperability points,
‘pssh’ boxes SHOULD NOT be present in Initialization Segments, and cenc:pssh elements in ContentProtection Descriptors used instead.
But, the current iOS_CDM_Player could not support it and report error message when play it as:
'Message':'Missing boxes.’,
'File':'/Developer/workshed/google3/third_party/video/udt_dash_transmuxer/library/dash_to_hls_api.cc',
'Line':242,
'Reason':'Missing pssh box',
'Extra':''
So is it possible to to make the sdk that compatible with the DASH-IF-IOP-V3.2?
If yes, could let us know the schedule?
Sorry to ask you question from here.

This repository misses the license file.
The severity of that varies from project to project, but my goal here is to attract some attention.

If it's not a problem, this issue can be closed.

I'm leaving it here just in case: https://help.github.com/articles/adding-a-license-to-a-repository/.

Thanks.

Hello and thanks for your contribution....but i need some directions here:

1. i cant find .xcodeproj for any of the projects above
2. i try to make my own project using the same files but i cannt find "<HTTPServer.h>" library/framework

Thanks,
Vlad

It's possible for a track to have its own timescale specified in the mdhd box, not necessarily the same value as the one in the mvhd box. MP4Box is known to generate files where this issue happens.

I am not seeing any new commits from Google. The last meaningful commit was done in 2015.

I am interested in using this lib in my iOS app, but I am hesitant to do it since git feels abandoned.

@SeawardT I was you respond so some issues. Can you shed some light on this?

Thank you!

The duration of a sample should fall back to trex if it isn't specified in trun and a default isn't present in tfhd. Writing the container like that apparently isn't recommended behaviour but it happens in practice.

Current version of transmuxer only supports 8-byte IV that causes a problem for real VOD services that have all DASH+CENC content encoded with 16-byte IV. Content play fine on all platforms except iOS with Widevine CDM because they're using this transmuxer.

I don't know whether this is true of other/all STL implementations, but on iOS at least (tested on SDK 8.4 in C++98 mode), vector assignment preserves capacity if the LHS is larger than the RHS. Therefore, when an empty vector is assigned to the desired position within DashToHls_ReleaseHlsSegment(), no actual deallocation takes place. This quickly builds up to hundreds of Megabytes, and eventually iOS will kill the application for using too much memory.

Compiling in C++11 mode solves the problem (if this is a feature of C++11, it'd be nice to require C++11 compatibility); so does using std::map's erase() to remove the element.

When these boxes have a version == 1 MdhdContents::Parse and MvhdContents::Parse parse the time scale member as 64-bits when it should be 32-bits. Interestingly, the comments before these functions have the proper class definitions from ISO 14496-12 so it just looks like a duplicated typo.

I fixed these locally to get our content parsing properly but we need these changes in future player SDKs. Can someone take a look?

Thanks,
Chris

Hi,

Are there any plans to update the UDT source with the changes included in the latest iOS CDM?

Regards,
Anders

Hi team,

we need to to run the cdm_reference_player_ios project with the new version of the library that is now published in github, this is, the changes you did on the universal-dash-transmuxer. Since we are not able to compile the github code for generating the oemcrypto_tfit2-eit_dev_dylib and oemcrypto_tfit2_dev_dylib_sim libraries we would need the compiled version, is it possible? (the current code has external references we cannot solve on our end)

Thanks!