Mirror-Tools
/
shaka-packager
mirror of https://github.com/shaka-project/shaka-packager.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
shaka-packager/packager/app/test/testdata/live-static-profile-and-ad-.../output.mpd

48 lines
2.9 KiB
Plaintext
Raw Normal View History

Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
<?xml version="1.0" encoding="UTF-8"?>
chore: Update URLs after moving projects (#1042) Since a project URL is encoded into outputs, this means also updating the golden output files. Closes #1043
2022-03-07 19:56:34 +00:00
<!--Generated with https://github.com/shaka-project/shaka-packager version <tag>-<hash>-<test>-->
fix: duration formatting and update mpd testdata to reflect new format (#1320) As part of the CMake port we updated the duration formatting to contain maximum of 6 decimal places but without trailing 0s. There was a bug however where it used 6 significant digits rather than 6 decimal places (`%g` rather than `%f`). This fixes the bug and also updates the MPD sample files for the integration tests to contain maximum of 6 decimal places.
2024-02-08 17:48:14 +00:00
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" xmlns:cenc="urn:mpeg:cenc:2013" profiles="urn:mpeg:dash:profile:isoff-live:2011" minBufferTime="PT2S" type="static" mediaPresentationDuration="PT2.736067S">
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<Period id="0" duration="PT2.002S">
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
<AdaptationSet id="0" contentType="video" width="640" height="360" frameRate="30000/1001" segmentAlignment="true" par="16:9">
Use max bitrate in Representation@bandwidth instead of average bitrate According to DASH spec (23009-1:2014): Consider a hypothetical constant bitrate channel of bandwidth with the value of this attribute in bits per second (bps). Then, if the Representation is continuously delivered at this bitrate, starting at any SAP that is indicated either by @startwithsap or by any Segment Index box, a client can be assured of having enough data for continuous playout providing playout begins after @minbuffertime * @bandwidth bits have been received (i.e. at time @minbuffertime after the first bit is received). For dependent Representations this value specifies the bandwidth according to the above definition for the aggregation of this Representation and all complementary Representations. This suggests that max bitrate should be used instead of average bitrate. Also cleaned up BandwidthEstimator code. Fixes #376. Change-Id: Ibf5896394c5c6bb820849771a2129c59202d2273
2018-04-13 18:48:11 +00:00
<Representation id="0" bandwidth="974122" codecs="avc1.64001e" mimeType="video/mp4" sar="1:1">
Remove Test File Index in packager_test.py Instead of using the test file's index in a list to create the output name, use the original filename and the descriptor. This caused some problems with file name collisions when some tests were using the same name. That was fixed by changing the names. This will go away once they are transitioned to use DiffDir like the other tests. Change-Id: I0a4c480406705ca63fcea61c86c67d4a5f739295
2018-03-02 17:02:38 +00:00
<SegmentTemplate timescale="30000" initialization="bear-640x360-video-init.mp4" media="bear-640x360-video-$Number$.m4s" startNumber="1">
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
<SegmentTimeline>
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<S t="0" d="30030" r="1"/>
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
</SegmentTimeline>
</SegmentTemplate>
</Representation>
</AdaptationSet>
<AdaptationSet id="1" contentType="audio" segmentAlignment="true">
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<Representation id="1" bandwidth="133929" codecs="mp4a.40.2" mimeType="audio/mp4" audioSamplingRate="44100">
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
Remove Test File Index in packager_test.py Instead of using the test file's index in a list to create the output name, use the original filename and the descriptor. This caused some problems with file name collisions when some tests were using the same name. That was fixed by changing the names. This will go away once they are transitioned to use DiffDir like the other tests. Change-Id: I0a4c480406705ca63fcea61c86c67d4a5f739295
2018-03-02 17:02:38 +00:00
<SegmentTemplate timescale="44100" initialization="bear-640x360-audio-init.mp4" media="bear-640x360-audio-$Number$.m4s" startNumber="1">
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
<SegmentTimeline>
Integrate CueAlignmentHandler Also changed ChunkingHandler to be one-one handler. Issue: #355 Change-Id: Ie98a96bcc0ddded347699c9f333f604826976d11
2018-03-20 17:12:18 +00:00
<S t="0" d="45056"/>
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<S t="45056" d="43008"/>
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
</SegmentTimeline>
</SegmentTemplate>
</Representation>
</AdaptationSet>
</Period>
fix: duration formatting and update mpd testdata to reflect new format (#1320) As part of the CMake port we updated the duration formatting to contain maximum of 6 decimal places but without trailing 0s. There was a bug however where it used 6 significant digits rather than 6 decimal places (`%g` rather than `%f`). This fixes the bug and also updates the MPD sample files for the integration tests to contain maximum of 6 decimal places.
2024-02-08 17:48:14 +00:00
<Period id="1" duration="PT0.734067S">
Moves AdaptationSet@id management out of Period class It is now managed in SimpleMpdNotifier. This avoids unnecessary increment in AdaptationSet id counter. Also makes sure the AdaptationSet is sorted by id in XML output. Change-Id: Ibcd0b047a71c19cd30ad7d8af9a2ed0bb05e043e
2018-01-25 23:04:59 +00:00
<AdaptationSet id="0" contentType="video" width="640" height="360" frameRate="30000/1001" segmentAlignment="true" par="16:9">
<Representation id="0" bandwidth="869044" codecs="avc1.64001e" mimeType="video/mp4" sar="1:1">
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<SegmentTemplate timescale="30000" presentationTimeOffset="60059" initialization="bear-640x360-video-init.mp4" media="bear-640x360-video-$Number$.m4s" startNumber="3">
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
<SegmentTimeline>
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<S t="60060" d="22022"/>
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
</SegmentTimeline>
</SegmentTemplate>
</Representation>
</AdaptationSet>
Moves AdaptationSet@id management out of Period class It is now managed in SimpleMpdNotifier. This avoids unnecessary increment in AdaptationSet id counter. Also makes sure the AdaptationSet is sorted by id in XML output. Change-Id: Ibcd0b047a71c19cd30ad7d8af9a2ed0bb05e043e
2018-01-25 23:04:59 +00:00
<AdaptationSet id="1" contentType="audio" segmentAlignment="true">
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<Representation id="1" bandwidth="108086" codecs="mp4a.40.2" mimeType="audio/mp4" audioSamplingRate="44100">
Moves AdaptationSet@id management out of Period class It is now managed in SimpleMpdNotifier. This avoids unnecessary increment in AdaptationSet id counter. Also makes sure the AdaptationSet is sorted by id in XML output. Change-Id: Ibcd0b047a71c19cd30ad7d8af9a2ed0bb05e043e
2018-01-25 23:04:59 +00:00
<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<SegmentTemplate timescale="44100" presentationTimeOffset="88288" initialization="bear-640x360-audio-init.mp4" media="bear-640x360-audio-$Number$.m4s" startNumber="3">
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
<SegmentTimeline>
Add support for EditLists in ISO-BMFF - EditLists in input files are parsed and applied to sample timestamps. - An EditList will be inserted in the ISO-BMFF output if - There is an offset between the initial presentation timestamp (pts) and decoding timestamp (dts). Chrome, as of M67, still uses dts in buffered range API [1], which creates various problems when buffered range by pts does not align with buffered range by dts. There is another bug in Chrome that applies EditList to pts only [2]. This means that we can insert an EditList to align pts range and dts range. - MediaSamples have negative timestamps (e.g. for Audio Priming). You may notice the below change on some contents: - Some media duration is reduced by one or two frames. This is because EditList in the input file was ignored in the previous code, so video streams start with a zero dts and a non-zero pts; the smaller of dts and pts was used as the starting timestamp (related to the earlier workaround for Chrome's dts bug), so the calculated duration was actually a bit larger than the actual duration. Now with EditList applied, the initial pts is reduced to zero, so the media duration is also reduced to reflect the actual and correct media duration. It may also result in negative timestamps in TS/HLS Packed Audio, which will be addressed in a follow up CL. Fixes #112. Partially address b/110782437. [1] https://crbug.com/718641, fixed but behind MseBufferByPts. [2] https://crbug.com/354518. Chrome is planning to enable the fix for [1] before addressing this bug, so we are safe. Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
2018-07-03 00:52:25 +00:00
<S t="88064" d="32768"/>
Share chunkers from the same input except for WVM Updated test files and added end to end tests for AdCues. Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-10 00:04:40 +00:00
</SegmentTimeline>
</SegmentTemplate>
</Representation>
</AdaptationSet>
</Period>
</MPD>