Lines Matching refs:moov
2675 isomp4/mux: don't overwrite with a bigger moov when fragmenting
2677 the moov to maybe add a duration to the mvex. If we start by not
2678 writing the initial moov->mvex->mhed duration and then overwrite with a
2679 moov containing mhed atom, the moov's will have different sizes and
2681 e.g. The initial moov would be of size 842 and the final moov would have
2683 Fix by always pushing out the mhed duration in the moov when
7132 isomp4/mux: add a fragment mode for initial moov with data
7137 mdat+moov complete with an edit list and durations, tags, etc.
7142 are also kept for writing out the final moov.
7143 3. On finalisation, the initial moov is invalidated to a hoov and the
7145 Then a moov is written as regularly would in moov-at-end mode (the
7170 qtdemux: fix subsequent moof parsing after moov with valid samples
7173 Fixes subsequent parsing of a moof following a moov that contains valid
7182 the media that is in the moov. Extend the edit list stop time when we
15427 [moov] size=8+1571
17038 qtdemux: set need_segment after a second moov
17040 list, also when a new `moov` is received. Unfortunately this was not
17043 performed on the new moov and no segment event was being emitted.
17044 When performing stream switching (e.g. in MSE) the new moov may have a
17519 whenever demux got moov without delay.
17520 Meanwhile, since there is no moov box in MSS stream,
17521 the caps will act like moov. Then, there is delay for exposing new pads
18975 This used not to happen because there were places in moov parsing where
19141 qtdemux: mark segment as sent after pushing when moov is received
19142 Otherwise we would try to send it a second time if the same moov is
19549 qtdemux: Try to expose whenever got new moov or new stream-start
19550 Whenever got new moov or new stream-start,
19552 Comparing stream-id in the current moov with previous one, then
19570 qtdemux: Create stream whenever got new moov
19571 Whenever demux got moov, demux will create new stream. Only exception is
19572 duplicated track-id in a moov box. In that case the first stream
19573 will be accepted. This patch is pre-work for rework of moov handling.
22206 if we're not sending periodic moov updates downstream for
22706 The same is already done for one sample given in the moov.
25124 We don't have any space reserved for this in the moov and the
25125 pre-finalized moov would have broken A/V synchronization. Error out here
25131 qtmux: Calculate with reserved moov size instead of last moov size
25132 We have some padding added after the initial moov, so a bigger updated
25133 moov can be handled to some degree and is expected. Previously we just
25179 This sets up a moov with the correct sample positions beforehand and
25390 Since mss has no moov, default stsd entry should be created with media-caps.
26301 moov recovery information would be written
26309 moov recovery
26493 qtmux: Update modification times when sending the moov
28159 qtdemux: Free compressed moov node and it's corresponding decompressed data
30904 moov: discont
30908 from moov and moof at the mdat position, while the buffer offset might be
35637 In case of push mode, qtdemux expose streams after got moov box.
35638 We can not guarantee that a moov box has sample data such as sample duration
35640 So, if a moov has no sample data, streams will not be exposed until get the first moof.
40545 In fragmented streaming, multiple moov/moof will be parsed and their
40550 1) initial moov is parsed, traks as well, streams are created. The
40556 3) At some point a new moov might be sent (bitrate switching, for example)
40740 It gets stuck if it only finds a moof and no mfra/mfro or moov
42056 after updating the moov or mdat atom, and after updating the free
42062 isomp4: Only set moov header into streamheader at EOS
42063 Only update the moov header into the caps if it's the finalised
42064 moov at EOS time. Avoids posting a bogus moov at startup and
42086 the moov header at a configurable interval. Rewriting
42087 moov is done using reserved space at the start of
42088 the file, and a ping-pong strategy where the moov
42091 the moov unless they've changed. Clear any existing tags when
42092 re-writing them, so we can do progressive moov updating in robust
42103 isomp4: Update edit list when re-writing moov
42104 Correctly update any edit lists each time the moov is recalculated,
43691 cover the rest of the file, including any moov atom we write out.
45079 Refactor the functions that were bound to the 'moov' atom to
45081 This allows the tags to be written to 'udta' at the 'moov' or
45985 moov atom), we need to check and update the various duration variables
46202 chunk when have a moov, and start exposing the streams, so we
47920 DASH/fragmented moov might have no samples as those are carried
55218 1) Expose the streams on the first moof as there are no moov atoms
55647 Some buffers can have multiple moov atoms inside and the strategy
55795 qtdemux: avoid re-reading the same moov and entering into loop
55796 In the scenario of "mdat | moov (with fragmented artifacts)" qtdemux
55797 could read the moov again after the mdat because it was considering the
56308 Assume a file with atoms in the following order: moov, mdat, moof,
56310 The first moov usually doesn't contain any sample entries atoms (or
56312 at the moofs. In push mode, qtdemux parses the moov and then finds the mdat,
56325 The issue is that after parsing the next moov/moof, there might be some
56327 along with the already parsed moov/moof and playback would fail to continue
56328 after the contents of this moov/moof are played.
57794 MOOV box (moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data
60452 Avoid skipping moov atoms for fragmented MP4 files.
60457 initialization segment (a new moov atom) to the downstream qtdemux,
60458 but it doesn't handle this new moov yet, it will only parse the
60460 This commit changes qtdemux to accept a new moov in a dash bitstream
60948 qtdemux: effectively skip tracks that weren't listed on the 1st moov
61806 after each moov and moof atom.
61826 means that qtdemux will get a new moov atom. For 'standard' isomedia
61827 streams this isn't true and qtdemux should keep the previous moov
61836 Whenever dashdemux switches bitrates it sends a new moov with the
61866 'moov' atom with the media descriptions, this has to be extracted
63315 qtdemux: fix up dodgy code that tries to fix up a broken moov atom
63740 qtdemux: push mode: only parse moov 1 once
67659 qtdemux: fix parsing in push mode when moov atom is at the end
67661 fails with the error message "no 'moov' atom within the first 10 MB". This is
82194 That is, in case where no seek is peformed to moov, but preceding
87360 qtmux: add moov in streamheader
87384 In this mode, an initial empty moov (containing only stream metadata) is written,
87399 qtmux: refactor configuring and sending of moov
87732 qtmux: Adds moov recovery feature
87734 and update data about the moov atom (that is not writen till the
87766 qtmux: streamline moov data memory storage
88032 only later (when the moov atom is ready to be sent) provides
94907 an initial complete scan of all moof (though all moov sample metadata
94925 qtdemux: fragmented support; handle moov samples and proper stream duration
94936 ... as some bogus files may indicate streams of 0 duration in moov,
106662 qtdemux: skip unknown atoms when looking for moov
107503 qtdemux: Add push mode seek support for seeking to obtain the moov atom
115305 until moov atom is reached, which handles cases with multiple
123762 Handle (in pull mode) some files that have a truncated moov atom where
152952 gst/qtdemux/qtdemux.*: Make push-based work if mdat atom is before moov atom.
152958 Make push-based work if mdat atom is before moov atom.
152974 gst/qtdemux/qtdemux.c: Handle the case where data atoms are before moov atoms in push-based mode.
152977 Handle the case where data atoms are before moov atoms in push-based mode.