Discussion:
[FFmpeg-user] Storing scan-type/interlaced in MXF?
Peter B.
2018-10-31 12:11:06 UTC
Permalink
Hi everyone :)

When trying to store an interlaced J2K-lossless in MXF, ffmpeg
recognizes the "top field first" given, but the resulting file claims to
be progressive :(

------------------------------
FFmpeg encoding says:
"Stream #0:0: Video: jpeg2000 (libopenjpeg), yuv422p10le(top first),
720x576 [SAR 1:1 DAR 5:4], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97
tbc"

FFprobe check says:
"Stream #0:0: Video: jpeg2000, yuv422p10le(progressive), 720x576, 29.97
tbr, 29.97 tbn, 29.97 tbc"
------------------------------

If anyone could tell me how to make the result "behave" properly, I'd be
very grateful :D

Thanks in advance,
Peter B.



Here's the commandline and uncut console output:


------------------------------
$ ffmpeg-git -f lavfi -i testsrc=size=720x576:rate=30000/1001 -c:v
libopenjpeg -pix_fmt yuv422p10le -t 1 -an -top 1 delme.mxf
------------------------------

ffmpeg version N-91407-g3c4af57 Copyright (c) 2000-2018 the FFmpeg
developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 20160609
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree
--enable-version3 --enable-postproc --enable-ffplay --enable-swscale
--enable-avfilter --enable-pthreads --enable-bzlib --enable-zlib
--enable-decoder=png --enable-encoder=png --samples=../fate-suite
--enable-libfreetype --enable-libopenjpeg --disable-decoder=jpeg2000
--enable-libvpx --enable-libvorbis --enable-libx264 --enable-libx265
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 20.104 / 58. 20.104
  libavformat    58. 17.101 / 58. 17.101
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 25.100 /  7. 25.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, lavfi, from 'testsrc=size=720x576:rate=30000/1001':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 720x576
[SAR 1:1 DAR 5:4], 29.97 tbr, 29.97 tbn, 29.97 tbc
File 'delme.mxf' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> jpeg2000 (libopenjpeg))
Press [q] to stop, [?] for help
Output #0, mxf, to 'delme.mxf':
  Metadata:
    encoder         : Lavf58.17.101
    Stream #0:0: Video: jpeg2000 (libopenjpeg), yuv422p10le(top first),
720x576 [SAR 1:1 DAR 5:4], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc58.20.104 libopenjpeg
frame=   30 fps=0.0 q=-0.0 Lsize=    1217kB time=00:00:01.00
bitrate=9956.1kbits/s speed=1.92x   
video:1186kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 2.568086%


------------------------------
ffprobe-git -i delme.mxf
------------------------------

ffprobe version N-91407-g3c4af57 Copyright (c) 2007-2018 the FFmpeg
developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 20160609
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree
--enable-version3 --enable-postproc --enable-ffplay --enable-swscale
--enable-avfilter --enable-pthreads --enable-bzlib --enable-zlib
--enable-decoder=png --enable-encoder=png --samples=../fate-suite
--enable-libfreetype --enable-libopenjpeg --disable-decoder=jpeg2000
--enable-libvpx --enable-libvorbis --enable-libx264 --enable-libx265
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 20.104 / 58. 20.104
  libavformat    58. 17.101 / 58. 17.101
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 25.100 /  7. 25.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, mxf, from 'delme.mxf':
  Metadata:
    uid             : adab4424-2f25-4dc7-92ff-29bd000c0000
    generation_uid  : adab4424-2f25-4dc7-92ff-29bd000c0001
    company_name    : FFmpeg
    product_name    : OP1a Muxer
    product_version : 58.17.101
    product_uid     : adab4424-2f25-4dc7-92ff-29bd000c0002
    modification_date: 0-01-02T00:00:00.000000Z
    material_package_umid:
0x060A2B340101010501010D001355EF5D529471340A55EF5D00529471340A5500
    timecode        : 00:00:00:00
  Duration: 00:00:01.00, start: 0.000000, bitrate: 9956 kb/s
    Stream #0:0: Video: jpeg2000, yuv422p10le(progressive), 720x576,
29.97 tbr, 29.97 tbn, 29.97 tbc
    Metadata:
      file_package_umid:
0x060A2B340101010501010D001355EF5D529471340A55EF5D00529471340A5501

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

To unsubscribe, visit link above, or email
ffmpeg-u
Carl Eugen Hoyos
2018-10-31 12:28:55 UTC
Permalink
Post by Peter B.
$ ffmpeg-git -f lavfi -i testsrc=size=720x576:rate=30000/1001 -c:v
libopenjpeg -pix_fmt yuv422p10le -t 1 -an -top 1 delme.mxf
From a quick look, interlaced mxf is only supported for selected
codecs (that support interlaced encoding), not for j2k.

Are you maybe expecting an output file with field encoding? This
is generally not supported in FFmpeg, neither for reading nor for
writing.

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
Peter B.
2018-10-31 13:10:56 UTC
Permalink
Hi Carl,
Post by Carl Eugen Hoyos
From a quick look, interlaced mxf is only supported for selected
codecs (that support interlaced encoding), not for j2k
Thanks for the quick-look-reply!
Interesting/good to know. Is this an MXF-specification thing or an
(ffmpeg) implementation thing?

Hm...
Might this be the reason why some institutions store J2K-lossless in MXF
as "field-as-frame" with double framerate?
Post by Carl Eugen Hoyos
Are you maybe expecting an output file with field encoding? This is generally not supported in FFmpeg, neither for reading nor for writing.
What do you mean by "field encoding"?

The scenario here is as follows:
Source is uncompressed, interlaced NTSC and shall be stored as
J2K-lossless in MXF.
Therefore the intention of having the resulting MXF containing all the
right metadata to be aware of scan-type and field-order.


Thanks for everything,
Peter
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffm
Paul B Mahol
2018-10-31 14:17:55 UTC
Permalink
Post by Peter B.
Hi Carl,
Post by Carl Eugen Hoyos
From a quick look, interlaced mxf is only supported for selected
codecs (that support interlaced encoding), not for j2k
Thanks for the quick-look-reply!
Interesting/good to know. Is this an MXF-specification thing or an
(ffmpeg) implementation thing?
Hm...
Might this be the reason why some institutions store J2K-lossless in MXF
as "field-as-frame" with double framerate?
Yes, and that is questionable practice.
Post by Peter B.
Post by Carl Eugen Hoyos
Are you maybe expecting an output file with field encoding? This is
generally not supported in FFmpeg, neither for reading nor for writing.
What do you mean by "field encoding"?
Source is uncompressed, interlaced NTSC and shall be stored as
J2K-lossless in MXF.
Therefore the intention of having the resulting MXF containing all the
right metadata to be aware of scan-type and field-order.
MXF muxing support on FFmpeg side lacks such bits.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-request
Tobias Rapp
2018-10-31 14:43:00 UTC
Permalink
Post by Peter B.
Hi everyone :)
When trying to store an interlaced J2K-lossless in MXF, ffmpeg
recognizes the "top field first" given, but the resulting file claims to
be progressive :(
[...]
Maybe try to double-check the generated MXF file using MediaInfo or
MxfDump. As far as I know field order is derived from the generic
picture essence descriptor in MXF.

Some time ago I had a similar issue with DV input files, see commit
e3196b686233bed3009248cb1ab7f0628ede6a2f.

Regards,
Tobias

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

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmp
Peter B.
2018-10-31 18:34:44 UTC
Permalink
Post by Tobias Rapp
Maybe try to double-check the generated MXF file using MediaInfo or
MxfDump. As far as I know field order is derived from the generic
picture essence descriptor in MXF.
Thanks for the tip, but I've already tried with Mediainfo before posting
here:
"Scan type : Progressive"
:(

Found a thread in Adobe forums (2016), that Premiere seems to allow only
progressive JPEG2000 export too, btw:
https://forums.adobe.com/thread/2196883


@Tobias:
Took a quick look at your patch :)

However, I found a related post from Carl Fleischhauer (FADGI/LoC
2016-08-23):
https://blogs.loc.gov/thesignal/2016/07/fadgi-mxf-video-specification-moves-up-an-industry-organization-approval-ladder/


[quote]
In the years following the 2006 publication, two or three vendors
developed systems unrelated to digital cinema that wrapped interlaced
video as JPEG 2000. Alas, since the recipe in the standard did not spell
things out clearly, these vendors’ wrappings differed, and the resulting
files were not interoperable.

In 2012, as we were developing AS-07, we joined a number of others who
sought improvements in the specification for interlaced video as JPEG
2000 in MXF.

The relevant SMPTE standards committee made a revision, published in
2014. Members of the committee–and this is perfectly normal–included
stakeholders from companies that had already invested in one or another
wrapping method. Thus the final 2014 version of ST 422 features three
options for interlaced wrapping (and two for progressive):
• “I1” Interlaced Frame Wrapping, 1 field per KLV Element (details
spelled out in section 5.4 in the standard)
• “I2” Interlaced Frame Wrapping, 2 fields per KLV Element (spelled out
in 5.5)
• “F1” Field Wrapping, 1 field per KLV Element (spelled out in 5.6)
[quote]


Sorry for bugging anyone with J2K/MXF, but now I'm curious:
Is any of these 3 methods (currently) possible with ffmpeg?
:D


Nice greetings, and sorry again ;)
Peter


_______________________________________________
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 s
Carl Eugen Hoyos
2018-10-31 21:23:48 UTC
Permalink
Post by Peter B.
The relevant SMPTE standards committee made a revision, published in
2014. Members of the committee–and this is perfectly normal–included
stakeholders from companies that had already invested in one or another
wrapping method. Thus the final 2014 version of ST 422 features three
• “I1” Interlaced Frame Wrapping, 1 field per KLV Element (details
spelled out in section 5.4 in the standard)
• “I2” Interlaced Frame Wrapping, 2 fields per KLV Element (spelled out
in 5.5)
• “F1” Field Wrapping, 1 field per KLV Element (spelled out in 5.6)
[quote]
Is any of these 3 methods (currently) possible with ffmpeg?
The second solution can hopefully be implemented once the technical
details are provided.
The other solutions will need user-interaction (filters) if they get
implemented so this is less likely.

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-***@f

Loading...