First frame missing (mkv file)

[CryGuy]

Hi,

I've double-double checked this. Tried ADM 2.74 release as well as latest build (9/4/2019).

If you open the following video in ADM, the first frame is missing:
https://mega.nz/#!CwZ3wQAT!cfd_vVjfpx0PEbqXbOH9FnlLrIVKtisfd0VE_POIM-M
It shows 0.08 s as the timestamp of the first frame. Correct is 0.04 s. I know this from:

1. There is a scene change at the second key frame at 6.04 s. According to ADM, this is the 150. frame in the video. If I extract all frames to jpg using ffmpeg, the same image is the 151. frame. So one frame is missing from ADM.
2. Dumping the timestamps using mkvextract. They are 40, 80, 120, etc. So I assume the frame with ts=40 is not displayed in ADM.

If I'm wrong again, I'll retire....
(Still don't understand the previous issue...)

Thanks once more.

[eumagga0x2a]

If you open the following video in ADM, the first frame is missing:
https://mega.nz/#!CwZ3wQAT!cfd_vVjfpx0PEbqXbOH9FnlLrIVKtisfd0VE_POIM-M
It shows 0.08 s as the timestamp of the first frame. Correct is 0.04 s.

Avidemux explains in the log:

Code Select Expand

[ComputeDeltaAndCheckBFrames] 05:25:34-852  First frame pts     40000 us
[open] 05:25:34-852  Have to delay by 40000 us detected for frame 80 so that PTS>DTS

1. There is a scene change at the second key frame at 6.04 s. According to ADM, this is the 150. frame in the video. If I extract all frames to jpg using ffmpeg, the same image is the 151. frame. So one frame is missing from ADM.

Unsure about that, will recheck more thoroughly later. The debug output of ffplay mentions the first IDR twice (the first one to init the video output, the second time for real while playing the video). If I search for "slice:", I get 151 matches for the first GOP, i.e. there are 150 frames when you discard the first entry for the IDR.

I see the same behaviour of ffplay with other videos.

Code Select Expand


2. Dumping the timestamps using mkvextract. They are 40, 80, 120, etc. So I assume the frame with ts=40 is not displayed in ADM.

Everything is delayed by 80ms by Avidemux to ensure the PTS-DTS delay is sufficient for B-frames.

If I'm wrong again, I'll retire....
(Still don't understand the previous issue...)

Please don't, you contributed a lot to Avidemux development as bugreporter.

[CryGuy]

Forget it. It's not reproducable with the sample video provided.  It's only reproducable with the original file (640 MB, length=41:46). The uploaded sample is the shortened version created by

Code Select Expand

ffmpeg -hide_banner -i "D:\bla\original.mkv" -map 0:v -c copy -t 10 d:\tmp\short.mkv
(optionally with -copyts, but it doesn't make a difference)

I'm extracting the images this way:

Code Select Expand


ffmpeg -hide_banner -i "D:\bla\original.mkv" -frames:v 160 d:\tmp\images_original\img_%05d.jpg
ffmpeg -hide_banner -i "D:\tmp\short.mkv" -frames:v 160 d:\tmp\images_short\img_%05d.jpg

Comparing the extracted images, the second scene starts at...
151st frame with the original
150st frame with the shortend version

I've verfied before posting here that this is NOT the case. So the sample is useless, once again.


EDIT: Regarding the original movie, I've extracted the frames again in bmp format to avoid jpg compression loss because the images are pretty dark. After adjusting the brightness, I've compared the first two frames. They are identical. So it seems, ffmpeg outputs the first frame twice, but only with the original, not the shortened copy. I wasn't aware of this. In addition, I've missed the timestamp (+40 ms) shifting again done by ADM. Both together lead me to opening this useless thread. I'm sorry.


EDIT #2: I've remuxed the original without shortening it:

Code Select Expand

ffmpeg -hide_banner -i "D:\bla\original.mkv" -map 0:v -c copy d:\tmp\full.mkv
Then I've also extracted an image sequence. Result: The start of 2nd scene is also at frame #150. Conclusion: Just remuxing the original seems to "remove" the first frame.


You say:

The debug output of ffplay mentions the first IDR twice (the first one to init the video output, the second time for real while playing the video).

I don't know what this means. I can only say that original.mkv has been created by ADM (input: MPG container, MPEG-2 video, encoder: libx264, muxer:mkv). So, the remaining question is why ffmpeg has a problem with this created file. Is this a problem on the ffmpeg or ADM side?

[eumagga0x2a]

You say:

The debug output of ffplay mentions the first IDR twice (the first one to init the video output, the second time for real while playing the video).

I don't know what this means.

I use routinely the output of

Code Select Expand

ffplay -debug pict /path/to/video

to retrieve a whole lot of useful information about the video stream.

EDIT: Regarding the original movie, I've extracted the frames again in bmp format to avoid jpg compression loss because the images are pretty dark. After adjusting the brightness, I've compared the first two frames. They are identical. So it seems, ffmpeg outputs the first frame twice, but only with the original, not the shortened copy. [...]

I can only say that original.mkv has been created by ADM (input: MPG container, MPEG-2 video, encoder: libx264, muxer:mkv).

It would be great to know exact settings. I assume, any short MPEG-2 720x576 25fps source video would do as a sample.

So, the remaining question is why ffmpeg has a problem with this created file. Is this a problem on the ffmpeg or ADM side?

I didn't have an opportunity to check saving individual frames as JPEG files in ffmpeg with the sample yet. The gut feeling is "ffmpeg bug", but it ain't necessarily so.

[CryGuy]

It would be great to know exact settings. I assume, any short MPEG-2 720x576 25fps source video would do as a sample.

Started from scratch.

This video (10 MB, 15 s)..
https://mega.nz/#!n5IUXIoD!jGWX2JXrucHRW916eL6X9po1ECNZU_HYJCN7nb7IESA

..using these x264 settings..
https://mega.nz/#!v8AgnILb!EDArKaCzsFzmj0rjzRR5cle3luLkPBmGOgnGKY8rqMI

plus the yadif filter gets transcoded to this mkv file:
https://mega.nz/#!rhQwxIRK!Lrkv5GsmhmgUMycx0HWEKG_1dgTiun5B2jAedl6GFg0

Opened in ADM and extracting images results in 367 images.
Extracting images by ffmpeg results in 377 images.

Comparing images shows that ffmpeg generates the first frame 11 times instead of 1 time, hence it outputs 10 pictures more.

[eumagga0x2a]

It looks like the behavior of FFmpeg with -frames:v is different from what you expect. It will output one image per frame increment, even if there is no frame to decode. The high first frame delay in the video re-encoded by Avidemux results in output of identical images until this delay is over. If you save the "Original.mkv" with Avidemux in copy mode to e.g. "Copy.mkv" to remove the excessive delay, there will be less duplicated frames.

FFmpeg can always set the PTS of the first frame to zero so that no duplicated frames with -frames:v are produced.

I can't test the entire chain from the original mpg because yadif is at the moment broken on my system (probably due to recent gcc update).

[CryGuy]

I didn't provide the ffmpeg command line this time, as I thought it's clear. Obviously, I should have. I didn't use -frames:v because it's a short movie this time. I extracted all images.

I think no difference without yadif as it just changes the image content.

For extracting images, original.mkv is sufficient.

[CryGuy]

Code Select Expand

The high first frame delay in the video re-encoded by Avidemux results in output of identical images until this delay is over.
I don't understand this. The delay is 1.268 s IIRC. At 25 fps, this should output ~31 additional frames, not 10.

Code Select Expand

If you save the "Original.mkv" with Avidemux in copy mode to e.g. "Copy.mkv" to remove the excessive delay, there will be less duplicated frames.

If you open original.mkv in Avidemux, there are no duplicate frames, so I don't know why they could be removed.

[eumagga0x2a]

There are neither duplicate nor missing frames in the stream, duplicated images output by ffmpeg with the -frames:v option must be an artifact from the way how it operates. The delay is 1.268 s from the POV of Avidemux, ffmpeg may come to a different conclusion, so that it would have to fill only 0.4 s.

When re-encoding a video in Avidemux, the output inherits the delay from the source video. This delay can be stripped when saving that output in copy mode. This has nothing to do with dropping frames, saving in copy mode tries to set the first DTS to zero. All following timestamps are reduced by this delta (ideally equal the DTS of the first frame).

[CryGuy]

Ok, thank you.