HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Christoph Gerstbauer-2
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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Carl Eugen Hoyos-2
2018-11-09 15:25 GMT+01:00, Chris von Görstinger
<[hidden email]>:

> 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.

[...]

> 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:

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

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Christoph Gerstbauer-2
Hello Carl,

thanks for the fast reply

> 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?

>
>> 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:
> 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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Carl Zwanzig
In reply to this post by Carl Eugen Hoyos-2
On 11/9/2018 7:08 AM, Carl Eugen Hoyos wrote:
> 2018-11-09 15:25 GMT+01:00, Chris von Görstinger
> <[hidden email]>:
>
>> 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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Carl Eugen Hoyos-2
In reply to this post by Christoph Gerstbauer-2
2018-11-09 17:12 GMT+01:00, Christoph Gerstbauer
<[hidden email]>:

> Hello Carl,
>
> thanks for the fast reply
>
>> 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.

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)

> Is there another way to get a working exe from the current FFmpeg git head?
>
>>
>>> 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:
>> 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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Lou Logan
On Fri, Nov 9, 2018, at 8:01 AM, Carl Eugen Hoyos wrote:
>
> (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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Marton Balint


On Fri, 9 Nov 2018, Lou Logan wrote:

> On Fri, Nov 9, 2018, at 8:01 AM, Carl Eugen Hoyos wrote:
>>
>> (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."

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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Carl Eugen Hoyos-2
2018-11-10 0:19 GMT+01:00, Marton Balint <[hidden email]>:

>
> On Fri, 9 Nov 2018, Lou Logan wrote:
>
>> On Fri, Nov 9, 2018, at 8:01 AM, Carl Eugen Hoyos wrote:
>>>
>>> (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."
>
> 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.

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

> 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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Marton Balint


On Sat, 10 Nov 2018, Carl Eugen Hoyos wrote:

> 2018-11-10 0:19 GMT+01:00, Marton Balint <[hidden email]>:
>>
>> On Fri, 9 Nov 2018, Lou Logan wrote:
>>
>>> On Fri, Nov 9, 2018, at 8:01 AM, Carl Eugen Hoyos wrote:
>>>>
>>>> (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."
>>
>> 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.
>
> 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.

>
>> 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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Carl Eugen Hoyos-2
In reply to this post by Carl Zwanzig
2018-11-09 17:36 GMT+01:00, Carl Zwanzig <[hidden email]>:

> With such a well-written bug report

Unfortunately, it isn't;-(

> (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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

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.

@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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)

Christoph Gerstbauer-2
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 <
[hidden email]>:

> 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
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".