Stream copy of mxf format is weird
Dear all, Sorry for sending an HTML-only message right before. I am trying to make a stream copy of a mxf file to a new one with custom metadata. But, I found that the new stream copied mxf file suffers from non-monotonous dts problem. What I found is that dts is duplicated every 3 frames. I tried to use setpts bsf:v, but it didn't work. You can find in the attached stream_copied_mxf.txt, the message below appears: "Application provided invalid, non monotonically increasing dts to muxer in stream 0" ffprobe result shows the same dts information: it goes like 1,2,2,4,5,5,7,8,8,.... The command I used is as follows: ffmpeg -i (original_mxf).mxf -codec copy (stream_copied).mxf Interestingly, if I convert the weird mxf output file to another format such as mov, or avi, it works well. Of course, I used the latest ffmpeg. Should I report this as a bug? If you have any idea, I would appreciate it. Thank you. Sincerely, Kim Syehoon
Dear all, Sorry for having broken etiquette again...I am resending without the attachment. I am trying to make a stream copy of a mxf file to a new one with custom metadata. But, I found that the new stream copied mxf file suffers from non-monotonous dts problem. What I found is that dts is duplicated every 3 frames. I tried to use setpts bsf:v, but it didn't work. The ffmpeg -vf showinfo message shows like belows: [Parsed_showinfo_0 @ 000002967cb79c40] n: 1 pts: 2 pts_time:0.0667333 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:0 type:B checksum:4360C96A plane_checksum:[AC14C627 CC6DC0BD 71754277] mean:[219 486 569] stdev:[209.8 27.8 31.7] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [Parsed_showinfo_0 @ 000002967cb79c40] n: 2 pts: 0 pts_time:0 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:1 type:I checksum:223C10C9 plane_checksum:[319CEFE3 D55DA81D 43B078AB] mean:[219 486 569] stdev:[209.8 27.8 31.7] [Parsed_showinfo_0 @ 000002967cb79c40] side data - H.26[45] User Data Unregistered SEI message: UUID=a74602bb-f8a1-4cc0-a936-48e391dce761 [Parsed_showinfo_0 @ 000002967cb79c40] User Data=535249443011 [Parsed_showinfo_0 @ 000002967cb79c40] [Parsed_showinfo_0 @ 000002967cb79c40] side data - H.26[45] User Data Unregistered SEI message: UUID=dba1adef-b20c-40b4-8c85-8c0b46d5241e [Parsed_showinfo_0 @ 000002967cb79c40] User Data=494d494401000000 [Parsed_showinfo_0 @ 000002967cb79c40] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [null @ 000002967c208c00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 2 >= 0 [Parsed_showinfo_0 @ 000002967cb79c40] n: 3 pts: 4 pts_time:0.133467 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:0 type:B checksum:621CB96F plane_checksum:[BFA555AE CFB30BDD 8B9157E4] mean:[219 486 569] stdev:[209.7 27.8 31.6] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [Parsed_showinfo_0 @ 000002967cb79c40] n: 4 pts: 5 pts_time:0.166833 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:0 type:B checksum:EA130FF7 plane_checksum:[071C6426 7FD85BF0 0A374FD2] mean:[219 486 569] stdev:[209.7 27.7 31.6] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [Parsed_showinfo_0 @ 000002967cb79c40] n: 5 pts: 3 pts_time:0.1001 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:0 type:P checksum:ACEC2AC6 plane_checksum:[18186F28 23F23D94 F0DB7DFB] mean:[219 486 569] stdev:[209.7 27.8 31.7] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [null @ 000002967c208c00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 5 >= 3 [Parsed_showinfo_0 @ 000002967cb79c40] n: 6 pts: 7 pts_time:0.233567 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:0 type:B checksum:AEC5E43A plane_checksum:[4DE4C8D9 F909E08C 67543AC6] mean:[219 486 569] stdev:[209.7 27.7 31.6] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [Parsed_showinfo_0 @ 000002967cb79c40] n: 7 pts: 8 pts_time:0.266933 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:0 type:B checksum:8FAF60F1 plane_checksum:[CC499F8E 22A94FB8 3DCD719C] mean:[219 486 569] stdev:[209.7 27.7 31.6] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [Parsed_showinfo_0 @ 000002967cb79c40] n: 8 pts: 6 pts_time:0.2002 duration: 1 duration_time:0.0333667 fmt:yuv422p10le cl:left sar:1/1 s:1920x1080 i:T iskey:0 type:P checksum:38971DE5 plane_checksum:[43CC9EB6 D6FC5C4C 78DA22D4] mean:[219 486 569] stdev:[209.7 27.7 31.7] [Parsed_showinfo_0 @ 000002967cb79c40] side data - SMPTE 12-1 timecode: timecode - 00:00:00:00 [Parsed_showinfo_0 @ 000002967cb79c40] color_range:tv color_space:bt709 color_primaries:bt709 color_trc:bt709 [null @ 000002967c208c00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8 >= 6 and it goes with this pattern. The ffprobe result is as follows: [FRAME] media_type=video stream_index=0 key_frame=0 pts=1 pts_time=0.033367 pkt_dts=1 pkt_dts_time=0.033367 best_effort_timestamp=1 best_effort_timestamp_time=0.033367 pkt_duration=1 pkt_duration_time=0.033367 duration=1 duration_time=0.033367 pkt_pos=906240 pkt_size=82883 width=1920 height=1080 crop_top=0 crop_bottom=0 crop_left=0 crop_right=0 pix_fmt=yuv422p10le sample_aspect_ratio=1:1 pict_type=B coded_picture_number=1 display_picture_number=0 interlaced_frame=1 top_field_first=1 repeat_pict=0 color_range=tv color_space=bt709 color_primaries=bt709 color_transfer=bt709 chroma_location=left TAG:timecode=00:00:00:00 [SIDE_DATA] side_data_type=SMPTE 12-1 timecode [TIMECODE] value=00:00:00:00 [/TIMECODE] [/SIDE_DATA] [/FRAME] [FRAME] media_type=video stream_index=0 key_frame=0 pts=2 pts_time=0.066733 pkt_dts=2 pkt_dts_time=0.066733 best_effort_timestamp=2 best_effort_timestamp_time=0.066733 pkt_duration=1 pkt_duration_time=0.033367 duration=1 duration_time=0.033367 pkt_pos=994816 pkt_size=85453 width=1920 height=1080 crop_top=0 crop_bottom=0 crop_left=0 crop_right=0 pix_fmt=yuv422p10le sample_aspect_ratio=1:1 pict_type=B coded_picture_number=2 display_picture_number=0 interlaced_frame=1 top_field_first=1 repeat_pict=0 color_range=tv color_space=bt709 color_primaries=bt709 color_transfer=bt709 chroma_location=left TAG:timecode=00:00:00:00 [SIDE_DATA] side_data_type=SMPTE 12-1 timecode [TIMECODE] value=00:00:00:00 [/TIMECODE] [/SIDE_DATA] [/FRAME] [FRAME] media_type=video stream_index=0 key_frame=1 pts=0 pts_time=0.000000 pkt_dts=2 pkt_dts_time=0.066733 best_effort_timestamp=0 best_effort_timestamp_time=0.000000 pkt_duration=1 pkt_duration_time=0.033367 duration=1 duration_time=0.033367 pkt_pos=7168 pkt_size=893392 width=1920 height=1080 crop_top=0 crop_bottom=0 crop_left=0 crop_right=0 pix_fmt=yuv422p10le sample_aspect_ratio=1:1 pict_type=I coded_picture_number=0 display_picture_number=0 interlaced_frame=1 top_field_first=1 repeat_pict=0 color_range=tv color_space=bt709 color_primaries=bt709 color_transfer=bt709 chroma_location=left TAG:timecode=00:00:00:00 [SIDE_DATA] side_data_type=H.26[45] User Data Unregistered SEI message [/SIDE_DATA] [SIDE_DATA] side_data_type=H.26[45] User Data Unregistered SEI message [/SIDE_DATA] [SIDE_DATA] side_data_type=SMPTE 12-1 timecode [TIMECODE] value=00:00:00:00 [/TIMECODE] [/SIDE_DATA] [/FRAME] [FRAME] media_type=video stream_index=0 key_frame=0 pts=4 pts_time=0.133467 pkt_dts=4 pkt_dts_time=0.133467 best_effort_timestamp=4 best_effort_timestamp_time=0.133467 pkt_duration=1 pkt_duration_time=0.033367 duration=1 duration_time=0.033367 pkt_pos=1387008 pkt_size=78518 width=1920 height=1080 crop_top=0 crop_bottom=0 crop_left=0 crop_right=0 pix_fmt=yuv422p10le sample_aspect_ratio=1:1 pict_type=B coded_picture_number=4 display_picture_number=0 interlaced_frame=1 top_field_first=1 repeat_pict=0 color_range=tv color_space=bt709 color_primaries=bt709 color_transfer=bt709 chroma_location=left TAG:timecode=00:00:00:00 [SIDE_DATA] side_data_type=SMPTE 12-1 timecode [TIMECODE] value=00:00:00:00 [/TIMECODE] [/SIDE_DATA] [/FRAME] [FRAME] media_type=video stream_index=0 key_frame=0 pts=5 pts_time=0.166833 pkt_dts=5 pkt_dts_time=0.166833 best_effort_timestamp=5 best_effort_timestamp_time=0.166833 pkt_duration=1 pkt_duration_time=0.033367 duration=1 duration_time=0.033367 pkt_pos=1471488 pkt_size=77660 width=1920 height=1080 crop_top=0 crop_bottom=0 crop_left=0 crop_right=0 pix_fmt=yuv422p10le sample_aspect_ratio=1:1 pict_type=B coded_picture_number=5 display_picture_number=0 interlaced_frame=1 top_field_first=1 repeat_pict=0 color_range=tv color_space=bt709 color_primaries=bt709 color_transfer=bt709 chroma_location=left TAG:timecode=00:00:00:00 [SIDE_DATA] side_data_type=SMPTE 12-1 timecode [TIMECODE] value=00:00:00:00 [/TIMECODE] [/SIDE_DATA] [/FRAME] [FRAME] media_type=video stream_index=0 key_frame=0 pts=3 pts_time=0.100100 pkt_dts=5 pkt_dts_time=0.166833 best_effort_timestamp=3 best_effort_timestamp_time=0.100100 pkt_duration=1 pkt_duration_time=0.033367 duration=1 duration_time=0.033367 pkt_pos=1085952 pkt_size=295239 width=1920 height=1080 crop_top=0 crop_bottom=0 crop_left=0 crop_right=0 pix_fmt=yuv422p10le sample_aspect_ratio=1:1 pict_type=P coded_picture_number=3 display_picture_number=0 interlaced_frame=1 top_field_first=1 repeat_pict=0 color_range=tv color_space=bt709 color_primaries=bt709 color_transfer=bt709 chroma_location=left TAG:timecode=00:00:00:00 [SIDE_DATA] side_data_type=SMPTE 12-1 timecode [TIMECODE] value=00:00:00:00 [/TIMECODE] [/SIDE_DATA] [/FRAME] The command I used is as follows: ffmpeg -i (original_mxf).mxf -codec copy (stream_copied).mxf Interestingly, if I convert the weird mxf output file to another format such as mov, or avi, it works well. Of course, I used the latest ffmpeg. Should I report this as a bug? If you have any idea, I would appreciate it. Thank you. Sincerely, Kim Syehoon
De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> De la part de Syehoon Kim (...) But, I found that the new stream copied mxf file suffers from non-monotonous dts problem. What I found is that dts is duplicated every 3 frames.
The command I used is as follows: ffmpeg -i (original_mxf).mxf -codec copy (stream_copied).mxf Interestingly, if I convert the weird mxf output file to another format such as mov, or avi, it works well.
It is not very clear to me, but it seems you only inspected the output and not the input. To start with, here is something you can try to quickly check dts/pts of your mxf input: ffmpeg -I input.mxf -map v -c copy -f framecrc - You can also directly decode to void to check some non-monotonous errors: ffmpeg -i input.mxf -f null null You can also play your input file with mpv keeping an eye on the console output messages. You can also dump your input mxf structure with dedicated tools (bmx, mxflib). It is not very widespread or well-known, but timestamp issues DO happen in the mxf wrapper itself. Nicolas
2024년 1월 30일 (화) 오후 6:28, Nicolas Gaullier <nicolas.gaullier@cji.paris>님이 작성:
De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> De la part de Syehoon Kim (...) But, I found that the new stream copied mxf file suffers from non-monotonous dts problem. What I found is that dts is duplicated every 3 frames.
The command I used is as follows: ffmpeg -i (original_mxf).mxf -codec copy (stream_copied).mxf Interestingly, if I convert the weird mxf output file to another format such as mov, or avi, it works well.
It is not very clear to me, but it seems you only inspected the output and not the input. To start with, here is something you can try to quickly check dts/pts of your mxf input: ffmpeg -I input.mxf -map v -c copy -f framecrc - You can also directly decode to void to check some non-monotonous errors: ffmpeg -i input.mxf -f null null You can also play your input file with mpv keeping an eye on the console output messages. You can also dump your input mxf structure with dedicated tools (bmx, mxflib). It is not very widespread or well-known, but timestamp issues DO happen in the mxf wrapper itself.
Dear Nicolas, Thank you for responding. mpv says the output file has wrong dts like below: Invalid video timestamp: 0.066733 -> 0.000000 AV: 00:00:00 / 00:00:31 (0%) A-V: 0.069 Invalid video timestamp: 0.166833 -> 0.100100 AV: 00:00:00 / 00:00:31 (1%) A-V: 0.119 Invalid video timestamp: 0.266933 -> 0.200200 AV: 00:00:00 / 00:00:31 (1%) A-V: 0.169 Invalid video timestamp: 0.367033 -> 0.300300 AV: 00:00:00 / 00:00:31 (1%) A-V: 0.219 Invalid video timestamp: 0.467133 -> 0.400400 AV: 00:00:00 / 00:00:31 (2%) A-V: 0.269 ct: 0.065 Invalid video timestamp: 0.567233 -> 0.500500 AV: 00:00:00 / 00:00:31 (2%) A-V: 0.289 ct: 0.112 Whilst with input file, there is no problem.(No message) And also I checked ffmpeg -i original.mxf -f framecrc, and it says 0, 0, 0, 1, 8294400, 0x56b7a44f 1, 0, 0, 1602, 3204, 0x3aa6ef88 0, 1, 1, 1, 8294400, 0x2398a5bd 1, 1602, 1602, 1601, 3202, 0xefa05a78 1, 3203, 3203, 1602, 3204, 0x38666a9f 0, 2, 2, 1, 8294400, 0x7993d275 0, 3, 3, 1, 8294400, 0xb12c0e14 1, 4805, 4805, 1601, 3202, 0xee903064 1, 6406, 6406, 1602, 3204, 0xd3624831 0, 4, 4, 1, 8294400, 0x9f309f83 0, 5, 5, 1, 8294400, 0x13e0a483 1, 8008, 8008, 1602, 3204, 0x13ca68e6 0, 6, 6, 1, 8294400, 0x7202ffa7 1, 9610, 9610, 1601, 3202, 0x30fa7edc 1, 11211, 11211, 1602, 3204, 0xcf8654dd 0, 7, 7, 1, 8294400, 0xf7c8a639 0, 8, 8, 1, 8294400, 0x9a581134 1, 12813, 12813, 1601, 3202, 0x13fd730a 1, 14414, 14414, 1602, 3204, 0x1a733eb1 0, 9, 9, 1, 8294400, 0x9adaf21b 0, 10, 10, 1, 8294400, 0x647034b3 1, 16016, 16016, 1602, 3204, 0xbdf95fa5 0, 11, 11, 1, 8294400, 0x0bc80cf3 1, 17618, 17618, 1601, 3202, 0x40d40c11 1, 19219, 19219, 1602, 3204, 0x1565256b 0, 12, 12, 1, 8294400, 0xb6a2cb17 Which seems fine with packet_dts. But, ffmpeg -i output.mxf -f framesrc says 1, 0, 0, 1602, 3204, 0x3aa6ef88 0, 1, 1, 1, 8294400, 0x56b7a44f 1, 1602, 1602, 1601, 3202, 0xefa05a78 1, 3203, 3203, 1602, 3204, 0x38666a9f 0, 2, 2, 1, 8294400, 0x2398a5bd 1, 4805, 4805, 1601, 3202, 0xee903064 1, 6406, 6406, 1602, 3204, 0xd3624831 0, 4, 4, 1, 8294400, 0xb12c0e14 0, 5, 5, 1, 8294400, 0x9f309f83 1, 8008, 8008, 1602, 3204, 0x13ca68e6 1, 9610, 9610, 1601, 3202, 0x30fa7edc 1, 11211, 11211, 1602, 3204, 0xcf8654dd 0, 7, 7, 1, 8294400, 0x7202ffa7 0, 8, 8, 1, 8294400, 0xf7c8a639 1, 12813, 12813, 1601, 3202, 0x13fd730a 1, 14414, 14414, 1602, 3204, 0x1a733eb1 0, 10, 10, 1, 8294400, 0x9adaf21b 1, 16016, 16016, 1602, 3204, 0xbdf95fa5 0, 11, 11, 1, 8294400, 0x647034b3 1, 17618, 17618, 1601, 3202, 0x40d40c11 1, 19219, 19219, 1602, 3204, 0x1565256b 0, 13, 13, 1, 8294400, 0xb6a2cb17 1, 20821, 20821, 1601, 3202, 0x2be40b71 1, 22422, 22422, 1602, 3204, 0x2e7f26be 0, 14, 14, 1, 8294400, 0x85a41143 1, 24024, 24024, 1602, 3204, 0xa74d1c7b50 bitrate= 26.9kbits/s dup=0 drop=5 speed=0.984x 0, 16, 16, 1, 8294400, 0x94964a0b Definitely, there is no packet_dts=3,6,9,... and there are 5 frame drops. I think there is nothing wrong with the original input file. Like you said, maybe it is due to the defect of the mxf wrapper. Thank you for notifying about mxf wrapper's timestamp issue. Sincerely, Kim Syehoon
De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> De la part de Syehoon Kim
I think there is nothing wrong with the original input file. Can you check with -c copy, I mean exactly ffmpeg -i input.mxf -map v -c copy -f framecrc - If your input has B frames, you should be able to distinguish the dts and pts columns.
Like you said, maybe it is due to the defect of the mxf wrapper. Thank you for notifying about mxf wrapper's timestamp issue. Kim Syehoon Well, I was talking about the mxf wrapper in a general manner, not ffmpeg's implementation. But anything might happen. Can you share a sample of your input (it would be required for trac anyway) ? Nicolas
2024년 1월 30일 (화) 오후 7:53, Nicolas Gaullier <nicolas.gaullier@cji.paris>님이 작성:
De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> De la part de Syehoon Kim
I think there is nothing wrong with the original input file. Can you check with -c copy, I mean exactly ffmpeg -i input.mxf -map v -c copy -f framecrc - If your input has B frames, you should be able to distinguish the dts and pts columns.
Below is the stdout of ffmpeg -i original.mxf -map v -c copy -f framecrc -: 0, -1, 2, 1, 672483, 0x8bd399df.03 bitrate= -0.0kbits/s speed=N/A 0, 0, 0, 1, 68278, 0x151ccf19, F=0x0 0, 1, 1, 1, 94762, 0x93b9fc75, F=0x0 0, 2, 5, 1, 274535, 0x6a5d2af8, F=0x0 0, 3, 3, 1, 128771, 0x247b89da, F=0x0 0, 4, 4, 1, 175939, 0x430aadb2, F=0x0 0, 5, 8, 1, 270016, 0xea154608, F=0x0 0, 6, 6, 1, 192351, 0x2e347924, F=0x0 0, 7, 7, 1, 199322, 0xeaebc0b6, F=0x0 0, 8, 11, 1, 259604, 0x4d57f015, F=0x0 0, 9, 9, 1, 199440, 0x3df86353, F=0x0 0, 10, 10, 1, 203249, 0xedd312f0, F=0x0 0, 11, 14, 1, 255367, 0x49a8fd8c, F=0x0 0, 12, 12, 1, 198382, 0xa4ca616b, F=0x0 0, 13, 13, 1, 193293, 0x1755209c, F=0x0 0, 14, 17, 1, 278686, 0x10a26986 0, 15, 15, 1, 145956, 0xf641c2c3, F=0x0 0, 16, 16, 1, 133157, 0xf9e4753b, F=0x0 0, 17, 20, 1, 243905, 0xf3728bbb, F=0x0 0, 18, 18, 1, 129545, 0x3c7547b0, F=0x0 0, 19, 19, 1, 123770, 0xcae5af54, F=0x0 0, 20, 23, 1, 250163, 0x45a54b5d, F=0x0 0, 21, 21, 1, 127813, 0xc83680c4, F=0x0 0, 22, 22, 1, 127352, 0x59a077c4, F=0x0 0, 23, 26, 1, 245345, 0xdc11da2f, F=0x0 0, 24, 24, 1, 131952, 0xd3b80148, F=0x0 0, 25, 25, 1, 134883, 0x6aa3627c, F=0x0 0, 26, 29, 1, 237893, 0x8b3ee2da, F=0x0 0, 27, 27, 1, 134788, 0x8d4d28c5, F=0x0 0, 28, 28, 1, 133607, 0x3d2db42b, F=0x0 0, 29, 32, 1, 485516, 0x66aa7aee 0, 30, 30, 1, 126395, 0x5863b059, F=0x0 0, 31, 31, 1, 121790, 0xaaf2b8f1, F=0x0 0, 32, 35, 1, 252756, 0x9f802af6, F=0x0 0, 33, 33, 1, 118577, 0x4b280fa6, F=0x0 0, 34, 34, 1, 119502, 0x93c109c5, F=0x0 0, 35, 38, 1, 247543, 0xcea9d0ae, F=0x0 0, 36, 36, 1, 119215, 0x3d100930, F=0x0 0, 37, 37, 1, 117839, 0x8fd807fc, F=0x0 I see nothing wrong. (Please note that the original.mxf consists of B frames, and I know that the order of dts should be mixed.)
Like you said, maybe it is due to the defect of the mxf wrapper. Thank you for notifying about mxf wrapper's timestamp issue. Kim Syehoon Well, I was talking about the mxf wrapper in a general manner, not ffmpeg's implementation. But anything might happen. Can you share a sample of your input (it would be required for trac anyway) ? Of course I can. Below is the URL from the company(SBS) where I work. In case it causes an http 500 error, just refresh it. https://megamail.sbs.co.kr:8443/xmegaAttach/BigFileDown.file?type=attachDown&fileName=Clip0003.MXF&fileIndex=K3YpOVEsvZg5eTu3mmTNF6F52kcPSl68poeFOYkO71k%3D
If you don't like it, maybe I can share it with Google Drive below, or something. https://drive.google.com/file/d/14y95vS_tIAO9xtxnFbX-5xh32p1nrADQ/view?usp=s... Please check it out. Sincerely, Kim Syehoon
De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> De la part de Syehoon Kim
Of course I can. Below is the URL from the company(SBS) where I work. In case it causes an http 500 error, just refresh it.
If you don't like it, maybe I can share it with Google Drive below, or something. https://drive.google.com/file/d/14y95vS_tIAO9xtxnFbX-5xh32p1nrADQ/view?usp=s...
Please check it out. Sincerely, Kim Syehoon
Ok, this is AVC long gop. The essence stream copy works fine - binary match. But the index metadata is lost: your input is actually correct as you said, the index table is VBR with video tagged posTableIndex=-1 to apply temporal reordering. The output is not, video has posTableIndex=0 (and temporalOffsets = 0), so no reordering, so bad. A trac ticket already exists: https://trac.ffmpeg.org/ticket/9315 Maybe you can add some words there to complete the description of the issue. Nicolas
2024년 1월 30일 (화) 오후 11:24, Nicolas Gaullier <nicolas.gaullier@cji.paris>님이 작성:
De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> De la part de Syehoon Kim
Of course I can. Below is the URL from the company(SBS) where I work. In case it causes an http 500 error, just refresh it.
If you don't like it, maybe I can share it with Google Drive below, or something. https://drive.google.com/file/d/14y95vS_tIAO9xtxnFbX-5xh32p1nrADQ/view?usp=s...
Please check it out. Sincerely, Kim Syehoon
Ok, this is AVC long gop. The essence stream copy works fine - binary match. But the index metadata is lost: your input is actually correct as you said, the index table is VBR with video tagged posTableIndex=-1 to apply temporal reordering. The output is not, video has posTableIndex=0 (and temporalOffsets = 0), so no reordering, so bad. A trac ticket already exists: https://trac.ffmpeg.org/ticket/9315 Maybe you can add some words there to complete the description of the issue.
Dear Nicolas, I appreciate your help. I am going to provide some more info on the trac you introduced. Thank you again. Sincerely, Kim Syehoon
participants (2)
-
Nicolas Gaullier -
Syehoon Kim