shaka-packager/packager/media/formats/mp4/mp4_muxer.h

85 lines
2.6 KiB
C
Raw Permalink Normal View History

// Copyright 2014 Google LLC. All rights reserved.
//
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file or at
// https://developers.google.com/open-source/licenses/bsd
#ifndef PACKAGER_MEDIA_FORMATS_MP4_MP4_MUXER_H_
#define PACKAGER_MEDIA_FORMATS_MP4_MP4_MUXER_H_
#include <optional>
#include <vector>
#include <packager/macros/classes.h>
#include <packager/media/base/muxer.h>
namespace shaka {
namespace media {
class AudioStreamInfo;
class StreamInfo;
class TextStreamInfo;
class VideoStreamInfo;
namespace mp4 {
class Segmenter;
struct ProtectionSchemeInfo;
struct Track;
/// Implements MP4 Muxer for ISO-BMFF. Please refer to ISO/IEC 14496-12: ISO
/// base media file format for details.
class MP4Muxer : public Muxer {
public:
/// Create a MP4Muxer object from MuxerOptions.
explicit MP4Muxer(const MuxerOptions& options);
~MP4Muxer() override;
private:
// Muxer implementation overrides.
Status InitializeMuxer() override;
Status Finalize() override;
Status AddMediaSample(size_t stream_id, const MediaSample& sample) override;
Status FinalizeSegment(size_t stream_id,
const SegmentInfo& segment_info) override;
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
Status DelayInitializeMuxer();
Status UpdateEditListOffsetFromSample(const MediaSample& sample);
// Generate Audio/Video Track box.
void InitializeTrak(const StreamInfo* info, Track* trak);
bool GenerateAudioTrak(const AudioStreamInfo* audio_info, Track* trak);
bool GenerateVideoTrak(const VideoStreamInfo* video_info, Track* trak);
bool GenerateTextTrak(const TextStreamInfo* video_info, Track* trak);
// Gets |start| and |end| initialization range. Returns true if there is an
// init range and sets start-end byte-range-spec specified in RFC2616.
std::optional<Range> GetInitRangeStartAndEnd();
// Gets |start| and |end| index range. Returns true if there is an index range
// and sets start-end byte-range-spec specified in RFC2616.
std::optional<Range> GetIndexRangeStartAndEnd();
// Fire events if there are no errors and Muxer::muxer_listener() is not NULL.
void FireOnMediaStartEvent();
void FireOnMediaEndEvent();
// Get time in seconds since midnight, Jan. 1, 1904, in UTC Time.
uint64_t IsoTimeNow();
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
// Assumes single stream (multiplexed a/v not supported yet).
bool to_be_initialized_ = true;
std::optional<int64_t> edit_list_offset_;
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
std::unique_ptr<Segmenter> segmenter_;
DISALLOW_COPY_AND_ASSIGN(MP4Muxer);
};
} // namespace mp4
} // namespace media
} // namespace shaka
#endif // PACKAGER_MEDIA_FORMATS_MP4_MP4_MUXER_H_