Lines Matching refs:the

4 # This tests that the matroska demuxer correctly adds the icpf header atom
9 # This tests that the matroska demuxer supports modifying the colorspace
11 # It also tests automatic insertion of the vp9_superframe bitstream filter
20 # This tests that the Matroska demuxer correctly demuxes WavPack
25 # This tests that the matroska demuxer supports decompressing
26 # zlib compressed tracks (both the CodecPrivate as well as the actual frames).
30 # This tests that the matroska demuxer can decompress lzo compressed tracks.
34 # This tests that the matroska demuxer correctly propagates
35 # the channel layout contained in vorbis comments in the CodecPrivate
40 # This tests that the Matroska muxer writes the channel layout
41 # of FLAC tracks as a Vorbis comment in the CodecPrivate if necessary
44 # Furthermore it tests everything the matroska-flac-channel-mapping test
45 # tests and it also tests the FLAC decoder and encoder, in particular
46 # the latter's ability to send updated extradata.
53 # demuxing it from Matroska/WebM. It furthermore tests the WebM muxer, in
54 # particular its DASH mode. Finally, it tests writing the Cues at the front.
62 # level 1-elements after the Cluster. This is tested on the demuxer's side.
63 # For the muxer this tests that it can correctly write huge TrackNumbers and
64 # that it can expand the Cues element's length field by one byte if necessary.
65 # It furthermore tests correct propagation of the description tag.
70 # This mainly tests the Matroska muxer's ability to shift the data
71 # to create enough free space to write the Cues at the front.
73 # to write the Cues are necessary.
75 # Cues with the same timestamp in the same CuePoint as well as
82 # as well as writing the Cues at the front (by shifting data) if
83 # the initially reserved amount of space turns out to be insufficient.
93 # This tests the scenario like tickets #4536, #5784 where
94 # the first packet (with the overall lowest dts) is a video packet,
95 # whereas an audio packet to be muxed later has the overall lowest pts
97 # (-ss 1.09 ensures that a video frame has the lowest dts of all packets;
98 # yet there is an audio packet with the overall lowest pts. output_ts_offset
99 # makes the pts of the audio packet, but not the leading video packet negative
100 # so that we run into the above issue.)
107 # This tests writing the MS-compatibility modes V_MS/VFW/FOURCC and A_MS/ACM.
108 # It furthermore tests writing the Cues at the front if the cues_to_front
110 # (Btw: The keyframe flags of the input video stream seem wrong.)
118 # This test the following features of the Matroska muxer: Writing projection
119 # stream side-data; not setting any track to default if the user requested it;
125 # The input file of the following test contains Content Light Level as well as
129 # Both input audio tracks are completely zero, so the noise bsf is used
138 # the correct interlaced flags and overriding the sample aspect ratio, leading
139 # to anamorphic video. Given that the input file has lots of filler material,
140 # the h264_metadata filter is used to remove it as well as the H.264 AUD.
141 # The video is decoded twice to show that this did not change the decoded
155 # It also tests the capability of the VP8 parser to set the keyframe flag
156 # (the input file lacks ReferenceBlock elements making everything a keyframe).
169 # This test uses the setts bsf to derive the duration of every packet
170 # except the last from the next packet's pts.
175 # and once with durations derived via the setts filter. Said filter
176 # sets the duration for every packet except the last it receives.
177 # The "-t 20" also tests that the BSF is properly flushed even
178 # when processing ended due to something else than the input's EOF.
179 # Notice that the last packet of stream 0 before 20s is present,
187 # The following test tests the various flavours of WebVTT in WebM.
189 # (and therefore lost). It moreover tests that the muxer writes CuePoints
190 # with multiple CueTrackPositions if the timestamps coincide.