Chiebot-Mirror
/
FFmpeg
mirror of https://github.com/FFmpeg/FFmpeg.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
102561 Commits
37 Branches
400 Tags
465 MiB
Tag: Branch: Tree: 4718d74c58
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '4718d74c58'
${ noResults }
FFmpeg/tests/ref/fate/mxf-d10-user-comments

29 lines
1.1 KiB
Raw Normal View History Unescape

fate/mxf: Fix d10-user-comments test The mxf_d10 muxer is very picky regarding the input it accepts: The only video accepted is MPEG-2 with absolutely constant bitrate, i.e. all packets need to have exactly the same size; and only a few bitrates are accepted. The sample file used did not abide by this: Writing the first packet (a video packet) errors out and afterwards an audio packet from the muxing queue has been written. That's all besides metadata (which this test is about). The FFmpeg cli returned an error, but said error has been ignored by the md5 test. This commit changes the test to actually send a compliant stream to the muxer, so that it does not error out; furthermore, the test is changed to explicitly check the metadata instead of it only being implicitly included in the md5 checksum. The compliant stream is created by our encoder at runtime. Finally, the test now also covers writing user-specified product/company/version identification. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
4 years ago
6dc13ae283257e898e069e5041ac8435 *tests/data/fate/mxf-d10-user-comments.mxf_d10
3782189 tests/data/fate/mxf-d10-user-comments.mxf_d10
#extradata 0: 34, 0x716b05c4
#tb 0: 1/25
#media_type 0: video
#codec_id 0: mpeg2video
#dimensions 0: 1280x720
#sar 0: 3/4
lavf/framecrcenc: do not hash side data There are no guarantees that all side data types have the same representation on all platforms. Tests that change output due to this: id3v2-priv-remux, cover-art-mp3-id3v2-remux, gapless-mp3: SKIP_SAMPLES, which is tested by fate-gapless-mp3-side-data matroska-vp8-alpha-remux: MATROSKA_BLOCKADDITIONAL, which is tested by remux itself (side data is written into output) matroska-mastering-display-metadata: MASTERING_DISPLAY_METADATA and CONTENT_LIGHT_LEVEL, which are tested by ffprobe invocation in the same test matroska-spherical-mono-remux: STEREO3D and SPHERICAL, which are tested by ffprobe invocation in the same test segment-mp4-to-ts: MPEGTS_STREAM_ID, which is tested by ts remuxing tests webm-webvtt-remux: WEBVTT_IDENTIFIER/SETTINGS, which is tested by the ffprobe invocation in the same test mxf-d10-user-comments: CPB_PROPERTIES, which is tested by mxf-probe-d10 mov-cover-image: SKIP_SAMPLES, which is tested for mov by mov-aac-2048-priming copy-trac3074: AUDIO_SERVICE_TYPE, which is tested by fate-hls-fmp4_ac3
4 years ago
0, -1, 0, 1, 150000, 0x0547870d
fate/mxf: Fix d10-user-comments test The mxf_d10 muxer is very picky regarding the input it accepts: The only video accepted is MPEG-2 with absolutely constant bitrate, i.e. all packets need to have exactly the same size; and only a few bitrates are accepted. The sample file used did not abide by this: Writing the first packet (a video packet) errors out and afterwards an audio packet from the muxing queue has been written. That's all besides metadata (which this test is about). The FFmpeg cli returned an error, but said error has been ignored by the md5 test. This commit changes the test to actually send a compliant stream to the muxer, so that it does not error out; furthermore, the test is changed to explicitly check the metadata instead of it only being implicitly included in the md5 checksum. The compliant stream is created by our encoder at runtime. Finally, the test now also covers writing user-specified product/company/version identification. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
4 years ago
0, 0, 1, 1, 150000, 0xe80a1612, F=0x0
0, 1, 2, 1, 150000, 0xc5c50e2f, F=0x0
0, 2, 3, 1, 150000, 0x51e28a04, F=0x0
0, 3, 4, 1, 150000, 0x9bbe6feb, F=0x0
[FORMAT]
TAG:operational_pattern_ul=060e2b34.04010101.0d010201.01010900
TAG:uid=adab4424-2f25-4dc7-92ff-29bd000c0000
TAG:generation_uid=adab4424-2f25-4dc7-92ff-29bd000c0001
TAG:company_name=FATE-company
TAG:product_name=FATE-test
avformat/mxfdec: add support for getting product version number metadata Signed-off-by: Marton Balint <cus@passwd.hu>
4 years ago
TAG:product_version_num=0.0.0.0.0
fate/mxf: Fix d10-user-comments test The mxf_d10 muxer is very picky regarding the input it accepts: The only video accepted is MPEG-2 with absolutely constant bitrate, i.e. all packets need to have exactly the same size; and only a few bitrates are accepted. The sample file used did not abide by this: Writing the first packet (a video packet) errors out and afterwards an audio packet from the muxing queue has been written. That's all besides metadata (which this test is about). The FFmpeg cli returned an error, but said error has been ignored by the md5 test. This commit changes the test to actually send a compliant stream to the muxer, so that it does not error out; furthermore, the test is changed to explicitly check the metadata instead of it only being implicitly included in the md5 checksum. The compliant stream is created by our encoder at runtime. Finally, the test now also covers writing user-specified product/company/version identification. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
4 years ago
TAG:product_version=3.14159
TAG:application_platform=Lavf
TAG:product_uid=adab4424-2f25-4dc7-92ff-29bd000c0002
avformat/mxfdec: change toolkit_version metadata field to toolkit_version_num It only got added recently, and the new name makes it consistent with product_version_num in the next patch. Signed-off-by: Marton Balint <cus@passwd.hu>
4 years ago
TAG:toolkit_version_num=0.0.0.0.0
fate/mxf: Fix d10-user-comments test The mxf_d10 muxer is very picky regarding the input it accepts: The only video accepted is MPEG-2 with absolutely constant bitrate, i.e. all packets need to have exactly the same size; and only a few bitrates are accepted. The sample file used did not abide by this: Writing the first packet (a video packet) errors out and afterwards an audio packet from the muxing queue has been written. That's all besides metadata (which this test is about). The FFmpeg cli returned an error, but said error has been ignored by the md5 test. This commit changes the test to actually send a compliant stream to the muxer, so that it does not error out; furthermore, the test is changed to explicitly check the metadata instead of it only being implicitly included in the md5 checksum. The compliant stream is created by our encoder at runtime. Finally, the test now also covers writing user-specified product/company/version identification. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
4 years ago
TAG:material_package_umid=0x060A2B340101010501010D001300000000000000000000000000000000000000
TAG:comment_test=value
TAG:timecode=01:00:00:00
[/FORMAT]