google / universal-dash-transmuxer Goto Github PK

View Code? Open in Web Editor NEW

55.0 23.0 30.0 1 MB

UDT (Dash Transmuxer) Project: Can transmux DASH -> HLS or other formats.

Home Page: http://www.google.com

License: Apache License 2.0

Python 2.10% C++ 84.41% Objective-C++ 8.44% C 2.48% Objective-C 2.57%

universal-dash-transmuxer's Introduction

NO LONGER MAINTAINED BY GOOGLE

See #19. We apologize for any inconvenience.

If you do not know H.264 then this code can be quite confusing.

CONTRIBUTIONS

All non-googlers must sign a Contributing License Agreement (CLA).

CUSTOMIZING

Common.gypi must be customized. library/mac_test_files.mm needs to be populated with your content. DashToHlsTools.gyp needs to add paths, read the comments in that file.

H.264 QUICK TUTORIAL.

H.264, or mpeg-4 is actually 15+ specs ranging from how to compress bits to how to package a video for transport. H.264 can also be placed in Mpeg-2 Program Streams (PS) and Transport Streams (TS). Depending on the layer you care about you should look at the different ISO 14496 specs. Most of this code is either 14496-10 or 14496-12.

Starting at the top Dash is in a 14496-12 container, which consists of boxes. Each box starts with a length followed by a 4 byte code. In this code all objects are named after their code. Any box may contain box specific data, subboxes, or a combination of the two. See 14496-12 for the exact definition of any box.

All mpeg-4 files start with a ftyp box followed by a moov. The ftyp is used to verify the content can be played. The moov contains ALL the information needed to set up the codecs.

For any file with mpeg-4 there are several ways to find the data. The DASH content this code is targetted to uses a sidx box to specify segments. Each segment is a moof and an mdat. The moof will have several important boxes in it to specify the Samples.

Each Sample is a low level Mpeg-4 chunk of data made up of nalu, slices, and other nitty gritty details. See 14496-10 for a description of these.

The basic process is to find the DASH samples, massage the nalus, set up Mpeg2 nalus for the codecs, then write out PS segments. Take the PS segments and pack them into TS segments.

CLOCKS IN H.264

There are four clock pointers in H.264 delivered over Transport Stream. System Clock Reference (SCR) Program Clock Reference (PCR) Decode Time Stamp (DTS) Program Time Stamp (PTS)

The DTS and PTS are all in 90KHz clock units. So a value of 900,000 would be 10 seconds. The SCR and PCR are in 27MHz clock units, so 10 seconds would be 900,000 * 300 = 270,000,000.

Each Sample must be delivered by either its SCR (PS) or PCR (TS). Once the packet is received it will be decoded by its DTS and put on the screen at its PTS. In H.264 packets are decoded out of order so while the DTS will go up a constant amount the PTS will jump all over the place.

Some devices need an SCR/PCR before the DTS to give time for decoding after the packets are guaranteed to arrive. This is called buffer time. While this library allows a buffer time it is expected to have a 0 buffer time (SCR == DTS).

universal-dash-transmuxer's People

Contributors

Stargazers

Watchers

universal-dash-transmuxer's Issues

dash_to_hls_api.cc assumes the timescale from mvhd is authoritative

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.

UDT Project Dead?!

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!

MVHD and MDHD Parsing Errors

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

HTTPServer library

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

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

Thanks,
Vlad

dash_to_hls_api.cc GetDuration() doesn't fall back to trex box

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.

How to get the compiled library

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!

Any plans to update the udt source?

Hi,

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

Regards,
Anders

typo in the README, PCR should be 27MHz clock units, not 27kHZ

[iOS] Memory usage issues related to DashToHls_ReleaseHlsSegment

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.

Could it support latest version(3.2) of guidelines for implementation:DASH-IF interoperability points

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.

DASH to HLS doesn't handle multiple PSSH boxes

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.

Support 16-byte IV

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.

License file is missing

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.

https://www.spotify.com/opensource/plain/

Transmuxing a subtitles stream

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