[FFmpeg-user] HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Discussion:

Chris von Görstinger

2018-11-09 14:25:49 UTC

Permalink

Hello FFmpeg Developers!

I think I found an bug in FFmpeg regarding HD MXFs. Or maybe I have missed
a syntax option which I does not know yet.

But first things first.

---------------------------------------------------------------------------------------------

1.) CURRENT SITUATION
I am testing to generate XDMCAMHD422 and AVCIntra50/100 MXFs with ffmpeg
4.0.2. and 4.0.
My used syntaxes are working good, there are no errors or warnings at the
commandline.

Used Syntax for XDCAMHD422:

ffmpeg -i inputfileSD_720x608.avi -map 0:v -map 0:a -map 0:a -map 0:a -map
0:a -map_channel 0.1.0:0.1.0 -map_channel 0.1.1:0.2.0 -map_channel
0.1.2:0.3.0 -map_channel 0.1.3:0.4.0 -vf "setfield=tff, crop=720:576:0:32,
scale=oh*16/9:1080:interl=1, pad=1920:1080:(ow-iw)/2:(oh-ih)/2,
fieldorder=tff, setsar=1, colormatrix=bt601:bt709" -c:v mpeg2video -r 25
-pix_fmt yuv422p -s 1920x1080 -aspect 16:9 -minrate 50000k -maxrate 50000k
-b:v 50000k -g 12 -flags +ildct+ilme -intra_vlc 1 -dc 10 -non_linear_quant
1 -bf 2 -qmin 4 -qmax 12 -top 1 -bufsize 17825792 -rc_init_occupancy
17825792 -rc_min_vbv_use 1 -rc_max_vbv_use 1 -sc_threshold 1000000000 -lmin
"1*QP2LAMBDA" -vtag xd5c -color_range tv -color_primaries bt709 -color_trc
bt709 -c:a pcm_s24le -ar 48000 -f mxf -timecode 12:34:56:11
-max_muxing_queue_size 1024 -metadata "creation_time=2015-10-28T15:37:56"
outputfile.mxf

Used syntax for AVCINTRA100:

ffmpeg -i inputfileSD_720x608.avi -map 0:v -map 0:a -map 0:a -map 0:a -map
0:a -map 0:a -map 0:a -map 0:a -map 0:a -map_channel 0.1.0:0.1.0
-map_channel 0.1.1:0.2.0 -map_channel 0.1.2:0.3.0 -map_channel 0.1.3:0.4.0
-map_channel 0.1.4:0.5.0 -map_channel 0.1.5:0.6.0 -map_channel 0.1.6:0.7.0
-map_channel 0.1.7:0.8.0 -vf "setfield=tff, crop=720:576:0:32,
scale=oh*16/9:1080:interl=1, pad=1920:1080:(ow-iw)/2:(oh-ih)/2,
fieldorder=tff, setsar=1, colormatrix=bt601:bt709" -c:v libx264 -r 25 -s
1920x1080 -aspect 16:9 -g 1 -b:v 111818k -pix_fmt yuv422p10le -flags
+ildct+ilme -x264opts avcintra-class=100 -profile:v high422 -level 4.1
-coder cavlc -x264opts colorprim=bt709 -x264opts transfer=bt709 -x264opts
colormatrix=bt709 -x264opts tune=psnr -x264opts interlaced=1 -x264opts
force-cfr=1 -x264opts fps=25/1 -forced-idr 1 -8x8dct 1 -top 1 -vtag avc1
-color_range tv -color_primaries bt709 -color_trc bt709 -c:a pcm_s24le -ar
48000 -f mxf -timecode 12:34:56:11 -metadata
"creation_time=2015-10-28T15:37:56" outputfile.mxf

After generating these files I am testing them with an MXF Analyzer which
analyses the MXF to SMPTE ST377-1 Standard-Compliance (MXF— File Format
Specification). So I check if the MXF is fullfilling minimum MXF
requirements for the MXF world.
And I get every time the same errors multiple times:
"Error: This Index Table Segment has the same Instance ID value of
ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00 as the Index Table Segment
located at byte offset XXXXXXXX.
The current Index Table Segment is not a repetition of the earlier Index
Table Segment."

---------------------------------------------------------------------------------------------

2.) PROBLEM DESCRIPTION
When analysing the file with BMX MXF using mxfdump I can count 30 times (in
a 5minutes file) the UID ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00.
So there are 30 Index Table Segments, and all 30 have the same UIDs
The error in MXF Analyzer is mentioned 29 times. (!)
-> So one IndexTableSegment with one UNIQUE ID is allowed.
-> So its logical -> the UniqueID should NOT BE THE SAME in multiple
IndexTableSegments entries.

In FFMPEGs IMX and DVCPRO MXF there is only one IndexTable Segment.
In SD/HD MXFs from 3rd Party tools there is also just one OR multiple
IndexTableSegment(s) in the MXF.
When generating an AVCI or XDCAMHD with 10seconds length with ffmpeg ->
There is just 1 IndexTableSegment and no error are mentioned and MXF
Analysis. So the Error Count increases with the length of the videos
because more than one "ITS" are written.

2.1) THE UID VALUE
It does not matter which MXF format I am creating (IMX, DV/DVCPRO,
AVCINTRA/HDCAMHD422) with ffmpeg.
The IndexTableSegment UID is always this value:
ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00

You can see it here in the examples from MXFDUMP:

2.1.1) AVCINTRA MXF UID:

[ K = IndexTableSegment ( 000000006287f600 )
06.0e.2b.34.02.53.01.01.0d.01.02.01.01.10.01.00, L = 3934 (f5e), LL =
3 ]
InstanceUID = ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00
Index Edit Rate = ( 25 / 1 )
Index Start Position = 00000000000009ce
Index Duration = 00000000000000fb
Edit Unit Byte Count = 00000000
IndexSID = 00000002
BodySID = 00000001
SliceCount = 01
DeltaEntryArray = [ Number of entries = 10
Entry size = 6 ]
Pos Table Slice Element
Index Delta
0 : 0 0 0
1 : 0 0 512
2 : 0 1 0
3 : 0 1 6144
4 : 0 1 12288
5 : 0 1 18432
6 : 0 1 24576
7 : 0 1 30720
8 : 0 1 36864
9 : 0 1 43008
IndexEntryArray = [ Number of entries = 251
Entry size = 15 ]
Temporal Anchor Flags Stream
Offset Offset Offset
[ Index table truncated from 251 entries to 0 entries ]

2.1.2) XDCAMHD UID

[ K = IndexTableSegment ( 0000000074030600 )
06.0e.2b.34.02.53.01.01.0d.01.02.01.01.10.01.00, L = 3925 (f55), LL =
3 ]
InstanceUID = ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00
Index Edit Rate = ( 25 / 1 )
Index Start Position = 0000000000001a9e
Index Duration = 00000000000000fc
Edit Unit Byte Count = 00000000
IndexSID = 00000002
BodySID = 00000001
SliceCount = 01
DeltaEntryArray = [ Number of entries = 6
Entry size = 6 ]
Pos Table Slice Element
Index Delta
0 : 0 0 0
1 : 255 0 512
2 : 0 1 0
3 : 0 1 6144
4 : 0 1 12288
5 : 0 1 18432
IndexEntryArray = [ Number of entries = 252
Entry size = 15 ]
Temporal Anchor Flags Stream
Offset Offset Offset

2.1.3) UID Overview:

IMX50 MXF: 1 Index Table Segment. UID
ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00
DV MXF: 1 Index Table Segment. UID
ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00
DVCPRO50 MXF: 1 Index Table Segment. UID
ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00
AVCINTRA100 MXF: MULTIPLE Index Table Segments with UID
ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00
XDCAMHD422 MXF: MULTIPLE Index Table Segments with UID
ad.ab.44.24.2f.25.4d.c7.92.ff.29.bd.00.0f.00.00

---------------------------------------------------------------------------------------------

3.) QUESTIONS:

I.) Why are there so many IndexTableSegments in XDCAMHD422/AVCINTRA files?
If the amount is a bug (and I dont think so) then: The index Table Segment
Count should be reduced to 1.

II.) If MORE than ONE Index Table Segments are necessary then the UID
should never be equal
Due to the fact that the UID is in every time the same maybe there is a
shuffle algorythm necessary or just not working correctly? (I am not a
programmer, thats just my first idea)

I think the main problem here is just the UID values and NOT the amount of
index table segments.

---------------------------------------------------------------------------------------------

4.) CommandlineOutputs

4.1) AVCINTRA100:

C:\Users\gersti>ffmpeg -i
E:\AVCIntra\01_testpattern16z9+progressive_8ch.avi -map 0:v -map 0:a -map
0:a -map 0:a -map 0:a -map 0:a -map 0:a -map 0:a -map 0:a -map_channel
0.1.0:0.1.0 -map_channel 0.1.1:0.2.0 -map_channel 0.1.2:0.3.0 -map_channel
0.1.3:0.4.0 -map_channel 0.1.4:0.5.0 -map_channel 0.1.5:0.6.0 -map_channel
0.1.6:0.7.0 -map_channel 0.1.7:0.8.0 -vf "setfield=tff, crop=720:576:0:32,
scale=oh*16/9:1080:interl=1, pad=1920:1080:(ow-iw)/2:(oh-ih)/2,
fieldorder=tff, setsar=1, colormatrix=bt601:bt709" -c:v libx264 -r 25 -s
1920x1080 -aspect 16:9 -g 1 -b:v 111818k -pix_fmt yuv422p10le -flags
+ildct+ilme -x264opts avcintra-class=100 -profile:v high422 -level 4.1
-coder cavlc -x264opts colorprim=bt709 -x264opts transfer=bt709 -x264opts
colormatrix=bt709 -x264opts tune=psnr -x264opts interlaced=1 -x264opts
force-cfr=1 -x264opts fps=25/1 -forced-idr 1 -8x8dct 1 -top 1 -vtag avc1
-color_range tv -color_primaries bt709 -color_trc bt709 -c:a pcm_s24le -ar
48000 -f mxf -timecode 12:34:56:11 -metadata
"creation_time=2015-10-28T15:37:56" -t 00:01:00.000
E:\AVCIntra\outputAVCINTRA100.mxf
ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 7.3.1 (GCC) 20180722
configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv
--enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg
--enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr
--enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2
--enable-libzimg --enable-lzma --enable-zlib --enable-gmp
--enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc
--enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom
--enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid
--enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
--enable-avisynth
libavutil 56. 14.100 / 56. 14.100
libavcodec 58. 18.100 / 58. 18.100
libavformat 58. 12.100 / 58. 12.100
libavdevice 58. 3.100 / 58. 3.100
libavfilter 7. 16.100 / 7. 16.100
libswscale 5. 1.100 / 5. 1.100
libswresample 3. 1.100 / 3. 1.100
libpostproc 55. 1.100 / 55. 1.100
Input #0, avi, from 'E:\AVCIntra\01_testpattern16z9+progressive_8ch.avi':
Metadata:
encoder : Lavf57.83.100
Duration: 00:05:00.00, start: 0.000000, bitrate: 119775 kb/s
Stream #0:0: Video: ffvhuff (FFVH / 0x48564646), yuv422p10le, 720x608,
110561 kb/s, SAR 93:85 DAR 837:646, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 7.1,
s32 (24 bit), 9216 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (ffvhuff (native) -> h264 (libx264))
Stream #0:1 -> #0:1 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:2 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:3 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:4 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:5 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:6 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:7 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:8 (pcm_s24le (native) -> pcm_s24le (native))
Press [q] to stop, [?] for help
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c0.
[pan @ 000001e69fcc8880] Pure channel mapping detected: 0
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c1.
[pan @ 000001e69fcca380] Pure channel mapping detected: 1
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c2.
[pan @ 000001e69fcc8e80] Pure channel mapping detected: 2
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c3.
[pan @ 000001e69fcc9380] Pure channel mapping detected: 3
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c4.
[pan @ 000001e69fcc9f80] Pure channel mapping detected: 4
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c5.
[pan @ 000001e69fd4d600] Pure channel mapping detected: 5
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c6.
[pan @ 000001e69fd4b400] Pure channel mapping detected: 6
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c7.
[pan @ 000001e69fd4d300] Pure channel mapping detected: 7
[libx264 @ 000001e69edd7680] using SAR=1/1
[libx264 @ 000001e69edd7680] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 000001e69edd7680] profile High 4:2:2 Intra, level 4.1, 4:2:2
10-bit
Output #0, mxf, to 'E:\AVCIntra\outputAVCINTRA100.mxf':
Metadata:
creation_time : 2015-10-28T15:37:56
timecode : 12:34:56:11
encoder : Lavf58.12.100
Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv422p10le(tv,
unknown/bt709/bt709), 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 111818 kb/s,
25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc58.18.100 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/111818000 buffer size: 0 vbv_delay: -1
Stream #0:1: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:2: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:3: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:4: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:5: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:6: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:7: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:8: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
frame= 1500 fps= 23 q=-1.0 Lsize= 843824kB time=00:01:00.00
bitrate=115210.1kbits/s speed=0.918x
video:770622kB audio:67500kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.680381%
[libx264 @ 000001e69edd7680] frame I:1500 Avg QP:15.97 size:526078
[libx264 @ 000001e69edd7680] mb I I16..4: 48.4% 17.8% 33.8%
[libx264 @ 000001e69edd7680] final ratefactor: 6.39
[libx264 @ 000001e69edd7680] field mbs: intra: 31.4%
[libx264 @ 000001e69edd7680] 8x8 transform intra:17.8%
[libx264 @ 000001e69edd7680] coded y,uvDC,uvAC intra: 89.2% 72.7% 71.5%
[libx264 @ 000001e69edd7680] i16 v,h,dc,p: 68% 26% 3% 3%
[libx264 @ 000001e69edd7680] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 27% 21%
4% 5% 5% 8% 5% 8%
[libx264 @ 000001e69edd7680] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 58% 9%
2% 3% 3% 4% 3% 4%
[libx264 @ 000001e69edd7680] i8c dc,h,v,p: 46% 17% 31% 6%
[libx264 @ 000001e69edd7680] kb/s:105215.55

C:\Users\gersti>

4.2) XDCAMHD422:

C:\Users\gersti>ffmpeg -i E:\XDCAMHD422\01_testpattern16z9+progressive.avi
-map 0:v -map 0:a -map 0:a -map 0:a -map 0:a -map_channel 0.1.0:0.1.0
-map_channel 0.1.1:0.2.0 -map_channel 0.1.2:0.3.0 -map_channel 0.1.3:0.4.0
-vf "setfield=tff, crop=720:576:0:32, scale=oh*16/9:1080:interl=1,
pad=1920:1080:(ow-iw)/2:(oh-ih)/2, fieldorder=tff, setsar=1,
colormatrix=bt601:bt709" -c:v mpeg2video -r 25 -pix_fmt yuv422p -s
1920x1080 -aspect 16:9 -minrate 50000k -maxrate 50000k -b:v 50000k -g 12
-flags +ildct+ilme -intra_vlc 1 -dc 10 -non_linear_quant 1 -bf 2 -qmin 4
-qmax 12 -top 1 -bufsize 17825792 -rc_init_occupancy 17825792
-rc_min_vbv_use 1 -rc_max_vbv_use 1 -sc_threshold 1000000000 -lmin
"1*QP2LAMBDA" -vtag xd5c -color_range tv -color_primaries bt709 -color_trc
bt709 -c:a pcm_s24le -ar 48000 -f mxf -timecode 12:34:56:11
-max_muxing_queue_size 1024 -metadata "creation_time=2015-10-28T15:37:56"
E:\XDCAMHD422\output_XDCAMHD422.mxf
ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 7.3.1 (GCC) 20180722
configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv
--enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg
--enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr
--enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2
--enable-libzimg --enable-lzma --enable-zlib --enable-gmp
--enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc
--enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom
--enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid
--enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
--enable-avisynth
libavutil 56. 14.100 / 56. 14.100
libavcodec 58. 18.100 / 58. 18.100
libavformat 58. 12.100 / 58. 12.100
libavdevice 58. 3.100 / 58. 3.100
libavfilter 7. 16.100 / 7. 16.100
libswscale 5. 1.100 / 5. 1.100
libswresample 3. 1.100 / 3. 1.100
libpostproc 55. 1.100 / 55. 1.100
Input #0, avi, from 'E:\XDCAMHD422\01_testpattern16z9+progressive.avi':
Metadata:
encoder : Lavf57.83.100
Duration: 00:05:00.00, start: 0.000000, bitrate: 115167 kb/s
Stream #0:0: Video: ffvhuff (FFVH / 0x48564646), yuv422p10le, 720x608,
110561 kb/s, SAR 93:85 DAR 837:646, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 4.0,
s32 (24 bit), 4608 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (ffvhuff (native) -> mpeg2video (native))
Stream #0:1 -> #0:1 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:2 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:3 (pcm_s24le (native) -> pcm_s24le (native))
Stream #0:1 -> #0:4 (pcm_s24le (native) -> pcm_s24le (native))
Press [q] to stop, [?] for help
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c0.
[pan @ 00000267a0bd7700] Pure channel mapping detected: 0
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c1.
[pan @ 00000267a0e0bd00] Pure channel mapping detected: 1
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c2.
[pan @ 00000267a0c32240] Pure channel mapping detected: 2
-map_channel is forwarded to lavfi similarly to -af pan=0x4|c0=c3.
[pan @ 00000267a0e27240] Pure channel mapping detected: 3
Output #0, mxf, to 'E:\XDCAMHD422\output_XDCAMHD422.mxf':
Metadata:
creation_time : 2015-10-28T15:37:56
timecode : 12:34:56:11
encoder : Lavf58.12.100
Stream #0:0: Video: mpeg2video (4:2:2) (xd5c / 0x63356478), yuv422p(tv,
unknown/bt709/bt709), 1920x1080 [SAR 1:1 DAR 16:9], q=4-12, 50000 kb/s, 25
fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc58.18.100 mpeg2video
Side data:
cpb: bitrate max/min/avg: 50000000/50000000/50000000 buffer size:
17825792 vbv_delay: -1
Stream #0:1: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:2: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:3: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
Stream #0:4: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s
Metadata:
encoder : Lavc58.18.100 pcm_s24le
frame= 7500 fps= 60 q=1.3 Lsize= 2017476kB time=00:05:00.01
bitrate=55088.6kbits/s speed=2.42x
video:1831055kB audio:168756kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.883369%

C:\Users\gersti>
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subje

Carl Eugen Hoyos

2018-11-09 15:08:26 UTC

Permalink

2018-11-09 15:25 GMT+01:00, Chris von Görstinger

Post by Chris von GÃ¶rstinger
I am testing to generate XDMCAMHD422 and AVCIntra50/100 MXFs
with ffmpeg 4.0.2. and 4.0.

Please test current FFmpeg git head, nothing else is supported here.

[...]

Post by Chris von GÃ¶rstinger
After generating these files I am testing them with an MXF Analyzer which
analyses the MXF to SMPTE ST377-1 Standard-Compliance (MXF— File Format
Specification). So I check if the MXF is fullfilling minimum MXF
requirements for the MXF world.

How can I reproduce this? How can I see the error messages?

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org w

Christoph Gerstbauer

2018-11-09 16:12:34 UTC

Permalink

Hello Carl,

thanks for the fast reply

Post by Carl Eugen Hoyos
Please test current FFmpeg git head, nothing else is supported here.
[...]

I cant because I am not able to compile. I am just a user. Not a
programmer/compiler.
I am dependent on the windows exe builds from
https://ffmpeg.zeranoe.com/builds/ which are linked on the offical
ffmpeg homepage.
Is there another way to get a working exe from the current FFmpeg git head?

Post by Carl Eugen Hoyos

How can I reproduce this? How can I see the error messages?

Unfortunately you cant without the IRT MXF Analyzer. It is a commercial
product from the Institut für Rundfunktechnik.
But you can send me your generated files and I can check them and send
you a report file back.

Regarding mxfdump: You can use the free toolset of BMX MXF from the BBC.
Here:
https://sourceforge.net/projects/bmxlib/

br

Christoph Gerstbauer

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-request

Carl Eugen Hoyos

2018-11-09 17:01:40 UTC

Permalink

2018-11-09 17:12 GMT+01:00, Christoph Gerstbauer

Post by Christoph Gerstbauer
Hello Carl,
thanks for the fast reply

Post by Carl Eugen Hoyos
Please test current FFmpeg git head, nothing else is supported here.
[...]

Where it tells you that the release builds are unsupported while
the current builds are supported.
(That's at least what we tried to communicate, improvements
welcome)

Post by Christoph Gerstbauer
Is there another way to get a working exe from the current FFmpeg git head?

Post by Carl Eugen Hoyos

How can I reproduce this? How can I see the error messages?

Unfortunately you cant without the IRT MXF Analyzer.

(Continuing a discussion I had with several people who archive.)
I wonder if this is all intentional (seriously!), you have a
specification that from all I know is unclear, multiple different
and incompatible implementations and several commercial
applications that tell you what's wrong in the files - but
nobody seems to be very interested in fixing these "issues".

Several tickets exist (including very old ones), I may be
closing them because they can't be reproduced.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-request

Lou Logan

2018-11-09 20:44:48 UTC

Permalink

Post by Carl Eugen Hoyos
(Continuing a discussion I had with several people who archive.)
I wonder if this is all intentional (seriously!), you have a
specification that from all I know is unclear, multiple different
and incompatible implementations and several commercial
applications that tell you what's wrong in the files - but
nobody seems to be very interested in fixing these "issues".

This reminds me of a few conversations I've had with those seeking alternatives in the seemingly locked-in world of the legacy cable broadcast stream conformation cycle. Luckily I'm not involved in broadcast but the situation (a few years ago at least) seemed to be:

"Buy our $4000 (USD) analyzer to see what we say is 'wrong' with your input. Buy our $6000 muxer to make it pass our analyzer."
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffm

Marton Balint

2018-11-09 23:19:31 UTC

Permalink

Post by Lou Logan

This reminds me of a few conversations I've had with those seeking
alternatives in the seemingly locked-in world of the legacy cable
broadcast stream conformation cycle. Luckily I'm not involved in
"Buy our $4000 (USD) analyzer to see what we say is 'wrong' with your
input. Buy our $6000 muxer to make it pass our analyzer."

Heh :)

Well, MXF is complicated, and based on what do you want to be compatible
with there are many flavours. Some issues reported by the analyzers can be
fixed, some can't be, because of the limited architecture of ffmpeg.

I guess there is no huge interest to improve the mxf muxer because BMXlib
tools like raw2bmx already do pretty good mxf wrapping (much better than
ffmpeg) and they support many flavours. I suggest using that for creating
standards compliant MXF.

On the other hand offering a bounty for fixing issues in the ffmpeg MXF
muxer might be an option, as far as I remember Baptiste and Michael did
work lately on mxfenc.

Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-req

Carl Eugen Hoyos

2018-11-09 23:30:54 UTC

Permalink

Post by Marton Balint

Post by Lou Logan

This reminds me of a few conversations I've had with those seeking
alternatives in the seemingly locked-in world of the legacy cable
broadcast stream conformation cycle. Luckily I'm not involved in
"Buy our $4000 (USD) analyzer to see what we say is 'wrong' with your
input. Buy our $6000 muxer to make it pass our analyzer."

We improved many part of FFmpeg although other software existed...

Post by Marton Balint
On the other hand offering a bounty for fixing issues in the ffmpeg MXF
muxer might be an option, as far as I remember Baptiste and Michael did
work lately on mxfenc.

I thought you did too, no?

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
f

Marton Balint

2018-11-09 23:49:44 UTC

Permalink

Post by Carl Eugen Hoyos

Post by Marton Balint

Post by Lou Logan

This reminds me of a few conversations I've had with those seeking
alternatives in the seemingly locked-in world of the legacy cable
broadcast stream conformation cycle. Luckily I'm not involved in
"Buy our $4000 (USD) analyzer to see what we say is 'wrong' with your
input. Buy our $6000 muxer to make it pass our analyzer."

We improved many part of FFmpeg although other software existed...

Mostly because we wanted to create a superior solution and because the
task was challenging. In this case I see little chance of reaching a
superior solution, and the task is not even challenging. If somebody pays
good money, maybe.

Post by Carl Eugen Hoyos

Post by Marton Balint
On the other hand offering a bounty for fixing issues in the ffmpeg MXF
muxer might be an option, as far as I remember Baptiste and Michael did
work lately on mxfenc.

I thought you did too, no?

I did mostly mxfdec.

Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subject "

Carl Zwanzig

2018-11-09 16:36:53 UTC

Permalink

Post by Carl Eugen Hoyos
2018-11-09 15:25 GMT+01:00, Chris von Görstinger

Post by Chris von GÃ¶rstinger
I am testing to generate XDMCAMHD422 and AVCIntra50/100 MXFs
with ffmpeg 4.0.2. and 4.0.

Please test current FFmpeg git head, nothing else is supported here.

If the MXF code hasn't changed since 4.0, it hardly matters, does it? Or
perhaps- "There have been some changes in that area since 4.0, please retest
with the latest."
(I haven't had a chance myself to check for code changes, but then I'm a
user here.)

With such a well-written bug report (especially compared to the more usual
"it doesn't work"), I'd rather expect the relevant developer to jump on the
problem for the challenge, or at least to acknowledge that it might be a bug
and discuss possible strategies instead of tossing it back like that. (And
as a code developer and QA engineer, I'd kill for a bug report like this.)

Later,

z!
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subject "unsubscri

Carl Eugen Hoyos

2018-11-10 13:34:04 UTC

Permalink

Post by Carl Zwanzig
With such a well-written bug report

Unfortunately, it isn't;-(

Post by Carl Zwanzig
(especially compared to the more usual "it doesn't work")

I strongly prefer "here is a link to a file that doesn't work", even
"here is a command line to a file that doesn't play with QT/WMP"
is much more useful.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.or

Martin Vignali

2018-11-12 09:58:56 UTC

Permalink

Hello,

I think this report is interesting.
Creating file for broadcast delivery, is not just about having a file which
play or doesn't play
It's mainly about passing Quality Control.

Even if a file can be play in most of software, if it doesn't pass
broadcaster QC, it will be reject.

In my use i always remux MXF generate by ffmpeg using bmxtranswrap, to have
"clean" mxf.

Mxf is a very complicated format, with very expensive "documentations".
Reason why, few people can improve it inside ffmpeg.

As suggested by Marton Balint, some developers (not me), have more chance
to work on it, with a financial support.
If you can sponsor it, you can try to contact developper who have recently
improve the mxfenc.

@Chris von Görstinger :
If you remux your file with bmx, does it still show warning in the MXF
Analyser ?

If yes, i suggest to create a bug report on trac.
Ideally, using an ffmpeg generator instead of a file as source.

Martin
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-

Chris von Görstinger

2018-11-19 14:00:41 UTC

Permalink

Hello Martin Vignali,

When rewrapping the ffmpeg-made mxf with bmxtranswrap I used following 2
types to test: OP1A or RDD9.

OP1A: Index Table Segments Problems are gone, but there is now a SAMPLERATE
problem.
RDD9: Index Table Segments Problems are gone, but there is now a KLV
Preface Problem (Preface does not start at a KLV grid line (KAGSIZE=512))

But yes, the index table segment problems are gone when rewrapping with BMX.

The issue ere is: We want to use ffmpeg to make a Standard Compliant (just
OP1a) file. Without rewrapping (rewrapping would cost extra time to remake
the file). I want to spare every unnecessary transcoding step.
We did the same in the past with IMX50 MXF Op1a format with ffmpeg. -> now
the ffmpeg made IMX50 MXF (Op1a) is now an MXF witch is completly standard
compliant and that is a BIG THING in the broadcasting world.
I mean: Now you can generate an MXFfile for professional needs with an open
source tool (!). How many MXFs from FinalCut, Premiere, Resolve,... do you
know which meet the MXF Standard ST377 completely without a problem?
Due to the fact that FFMPEG is not a blackbox and the developers can be
asked to improve this or that, or hinted to a bug because they have not
time to test everything, we can help to improve ffmpeg, like I am trying it
here.
For my personal opinion FFmpeg has the most potential of all transcoders in
the world.
Just my 5 cent.

Am Mo., 12. Nov. 2018 um 11:07 Uhr schrieb Martin Vignali <

Post by Martin Vignali
Hello,
I think this report is interesting.
Creating file for broadcast delivery, is not just about having a file which
play or doesn't play
It's mainly about passing Quality Control.
Even if a file can be play in most of software, if it doesn't pass
broadcaster QC, it will be reject.
In my use i always remux MXF generate by ffmpeg using bmxtranswrap, to have
"clean" mxf.
Mxf is a very complicated format, with very expensive "documentations".
Reason why, few people can improve it inside ffmpeg.
As suggested by Marton Balint, some developers (not me), have more chance
to work on it, with a financial support.
If you can sponsor it, you can try to contact developper who have recently
improve the mxfenc.
If you remux your file with bmx, does it still show warning in the MXF
Analyser ?
If yes, i suggest to create a bug report on trac.
Ideally, using an ffmpeg generator instead of a file as source.
Martin
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpe