#9145 closed defect (fixed)
J2K Parser generates large (concatenated) packet when HDR metadata present
| Reported by: | Chris Olekas | Owned by: | gautamramk@gmail.com |
|---|---|---|---|
| Priority: | important | Component: | avcodec |
| Version: | git-master | Keywords: | j2k regression |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | no |
Description
Summary of the bug:
The J2K parser added in this commit
d09c35677d libavcodec/jpeg2000_parser: Add jpeg2000 parser
d09c35677defb383f69395cef84a5e20c41da6d2 is the first bad commit
commit d09c35677defb383f69395cef84a5e20c41da6d2
Author: Gautam Ramakrishnan <gautamramk@gmail.com>
Date: Sat Jun 6 11:42:17 2020 +0530
libavcodec/jpeg2000_parser: Add jpeg2000 parser
I have attempted to write a JPEG2000 Parser. Have tested
by generating a file containing 14 frames, as mentioned
by Micheal. Have also tried testing with various packet
sizes by setting -frame_size option. Additionally,
fixed a few formatting issues as pointed out by Micheal.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavcodec/Makefile | 1 +
libavcodec/jpeg2000_parser.c | 190 +++++++++++++++++++++++++++++++++++++++++++
libavcodec/parsers.c | 1 +
3 files changed, 192 insertions(+)
create mode 100644 libavcodec/jpeg2000_parser.c
will concatenate many packets together which introduces a huge gap in the file. This was git bisected to determine the commit in question.
This can be reproduced with the following source
Tested on: c35e456f54d6c59ea62b18ce5b273da67c60903c
How to reproduce:
% ffprobe -hide_banner -select_streams v:0 -show_entries packet=dts_time,size VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b.mxf
Output is
Input #0, mxf, from 'VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b.mxf':
Metadata:
operational_pattern_ul: 060e2b34.04010101.0d010201.01010100
uid : 2479e9ff-e1e7-9844-a691-8ab03df86b5e
generation_uid : 2d55bb48-69f9-3748-a0ee-5887dc480d51
company_name : Blackmagic Design
product_name : DaVinci Resolve
product_version : 16.0
product_uid : 057cd849-178a-4b88-b4c7-825af8761b34
modification_date: 2020-04-01T05:20:41.252000Z
application_platform: DaVinci Resolve
material_package_umid: 0x060A2B340101010501010F20130000001FDEB977D7634287A4391BFC88FBC3C4
material_package_name: VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b
timecode : 00:00:00:00
Duration: 00:04:23.08, start: 0.000000, bitrate: 120661 kb/s
Stream #0:0: Video: jpeg2000, rgb48le(12 bpc, unknown/smpte432/smpte2084, progressive), 3840x2160, SAR 1:1 DAR 16:9, 24 tbr, 24 tbn, 24 tbc
Metadata:
file_package_umid: 0x060A2B340101010501010F2013000000E4DA5FCD5FFC4713BCDD95EA579D790B
file_package_name: VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b
track_name : PHDR Image Track
Side data:
Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2650,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.000100, max_luminance=1000.000000
[PACKET]
dts_time=0.000000
size=39270
[/PACKET]
[PACKET]
dts_time=0.250000
size=39270
[/PACKET]
[PACKET]
dts_time=0.500000
size=39270
[/PACKET]
[PACKET]
dts_time=0.750000
size=39270
[/PACKET]
[PACKET]
dts_time=1.000000
size=919019
[/PACKET]
[PACKET]
dts_time=1.375000
size=1569032922
[/PACKET]
[PACKET]
dts_time=22.166667
size=4162551
[/PACKET]
[PACKET]
dts_time=22.208333
size=4162551
[/PACKET]
...
When tested before the J2K parser change this is the output that would be gotten (tested with 4.2.2 build from JohnVanSickle)
ffprobe version 4.2.2-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2007-2019 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat 58. 29.100 / 58. 29.100 libavdevice 58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 libpostproc 55. 5.100 / 55. 5.100
Input #0, mxf, from 'VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b.mxf': [4386/4398]
Metadata:
operational_pattern_ul: 060e2b34.04010101.0d010201.01010100
uid : 2479e9ff-e1e7-9844-a691-8ab03df86b5e
generation_uid : 2d55bb48-69f9-3748-a0ee-5887dc480d51
company_name : Blackmagic Design
product_name : DaVinci Resolve
product_version : 16.0
product_uid : 057cd849-178a-4b88-b4c7-825af8761b34
modification_date: 2020-04-01T05:20:41.252000Z
application_platform: DaVinci Resolve
material_package_umid: 0x060A2B340101010501010F20130000001FDEB977D7634287A4391BFC88FBC3C4
material_package_name: VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b
timecode : 00:00:00:00
Duration: 00:04:23.08, start: 0.000000, bitrate: 120661 kb/s
Stream #0:0: Video: jpeg2000, rgb48le(12 bpc, progressive), 3840x2160, SAR 1:1 DAR 16:9, 24 tbr, 24 tbn, 24 tbc
Metadata:
file_package_umid: 0x060A2B340101010501010F2013000000E4DA5FCD5FFC4713BCDD95EA579D790B
file_package_name: VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b
track_name : PHDR Image Track
[PACKET]
dts_time=0.000000
size=6545
[/PACKET]
[PACKET]
dts_time=0.041667
size=6545
[/PACKET]
[PACKET]
dts_time=0.083333
size=6545
[/PACKET]
[PACKET]
dts_time=0.125000
size=6545
[/PACKET]
[PACKET]
dts_time=0.166667
size=6545
[/PACKET]
[PACKET]
dts_time=0.208333
size=6545
[/PACKET]
[PACKET]
dts_time=0.250000
size=6545
[/PACKET]
[PACKET]
dts_time=0.291667
size=6545
[/PACKET]
[PACKET]
dts_time=0.333333
size=6545
[/PACKET]
[PACKET]
dts_time=0.375000
size=6545
[/PACKET]
[PACKET]
dts_time=0.416667
size=6545
[/PACKET]
[PACKET]
dts_time=0.458333
size=6545
[/PACKET]
[PACKET]
dts_time=0.500000
size=6545
[/PACKET]
...
Note that the dts_times differ as well after the introduction of the J2K parser change.
I couldn't reproduce this testing other J2K/MXF combinations that don't have metadata attached to it.
Attachments (1)
Change History (11)
comment:1 by , 4 years ago
| Keywords: | j2k regression added; jpeg2000 mxf removed |
|---|---|
| Priority: | critical → important |
comment:2 by , 4 years ago
| Reproduced by developer: | set |
|---|---|
| Status: | new → open |
by , 4 years ago
| Attachment: | VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b_cut.mxf added |
|---|
comment:4 by , 4 years ago
#8966 just notes that metadata on the MXF level is lost. This seems to be an issue with the parser for the included J2K stream generating a large packet, which then due to AVSTREAM_PARSE_TIMESTAMPS being set in mxfdec leads to a large timestamp change between received packets.
if (st->codecpar->codec_type != AVMEDIA_TYPE_DATA &&
source_track->wrapping != FrameWrapped) {
/* TODO: decode timestamps */
st->need_parsing = AVSTREAM_PARSE_TIMESTAMPS;
}
Previous to d09c35677defb383f69395cef84a5e20c41da6d2 there was no parser for J2K so packets would be output as-is.
comment:5 by , 4 years ago
IIUC J2k muxed in MXF does not need parser at all. So there is probably only need to add bypass mode in j2k parser.
comment:6 by , 4 years ago
Yes, I do wonder what the meaning of that check is in mxfdec, in which cases is it /meant/ to need to set that parser flag (yes, video is not data, but the FrameWrapped check was then later added in 00a2652df3bf25a27d174cc67ed508b5317cb115 ).
Otherwise all video streams only get st->need_parsing = AVSTREAM_PARSE_HEADERS; set for themselves, which I think should not make this problem happen?
comment:7 by , 3 years ago
comment:8 by , 3 years ago
| Owner: | set to |
|---|
Please check the patch https://patchwork.ffmpeg.org/project/ffmpeg/patch/CAGKSLywdGwJ=B1fa_1Ns5Ac-ZaxecB7PUFuiTYnNFA9=+NYF-A@mail.gmail.com/ that fixes your parser. Is it LGTM?
comment:9 by , 3 years ago
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
Won't that be a duplicate of #8966?