bugged -c and -c copy version. Adding some extra frames at the end

[whatforiam]

Description:

A few joints

1. When the -c argument is used, the video analysis speed drops from 300fps to 200, although I don't think it should, because it only affects the render (I think it does -c copy for ffmpeg)
2. I have already addressed you with the problem that when cutting an anime (23.976fps) video, it affects adjacent frames and adds one frame from the next moment to the last. So, with the -c key, this problem remained and reached a new level. Now literally every moment has a frame from the next one at the end. And considering that I have a hevc video, I have to use the icaros program to display previews of files, and the preview shows just the last frame from the future moment. And if you recode the video, then there is no such problem. (writing -a "-c copy" does not help. It only solved the problem with the rendering speed, and now it does other things with an extra couple of frames at the end)

Command:

scenedetect -i "input/%%~i" -d 4 -b pyav detect-adaptive -w 0.1 0.1 1.0 0.0 -c 34 -t 2.7 split-video -o "anime%folder%%%~ni" -с
(-b pyav added threshold as you recommended in my last report)

Output:

BUG_REPORT.txt

Environment:

System Info

OS Windows-10-10.0.19045-SP0
Python CPython 3.13.0rc1
Architecture 64bit + WindowsPE

Packages

av 13.1.0
click 8.1.7
cv2 4.10.0
imageio 2.36.0
imageio_ffmpeg 0.5.1
moviepy 2.1.1
numpy 2.1.3
platformdirs 4.3.6
scenedetect 0.6.5
tqdm 4.67.1

Tools

ffmpeg 7.1-full_build-www.gyan.dev
mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit

Media/Files:

[whatforiam]

-с files

DB.Kyoukai.no.Kanata_-_01_.Dual.Audio_10bit_BD1080p_x265.-Scene-041.mp4

DB.Kyoukai.no.Kanata_-_01_.Dual.Audio_10bit_BD1080p_x265.-Scene-042.mp4

-a "-c copy" files

DB.Kyoukai.no.Kanata_-_01_.Dual.Audio_10bit_BD1080p_x265.-Scene-038.mp4

DB.Kyoukai.no.Kanata_-_01_.Dual.Audio_10bit_BD1080p_x265.-Scene-039.mp4

default normal re-encoded files

DB.Kyoukai.no.Kanata_-_01_.Dual.Audio_10bit_BD1080p_x265.-Scene-038.mp4

DB.Kyoukai.no.Kanata_-_01_.Dual.Audio_10bit_BD1080p_x265.-Scene-039.mp4

DB.Kyoukai.no.Kanata_-_01_.Dual.Audio_10bit_BD1080p_x265.-Scene-040.mp4

And I noticed that the weight of the final moments is also strikingly different.

[Breakthrough]

Just to confirm, are the cuts for the video correct if you use a normal encoding mode (e.g. don't use copying mode)? From what you posted above this seems to be the case but I want to double check.

When the -c argument is used, the video analysis speed drops from 300fps to 200, although I don't think it should, because it only affects the render (I think it does -c copy for ffmpeg)

This shouldn't be possible... I'm unable to reproduce this behaviour locally, and can confirm that any arguments passed to the split-video command won't affect the analysis phase. Are you sure nothing else was running in the background that would affect performance when you tested that?

And I noticed that the weight of the final moments is also strikingly different.

Could you check which audio tracks are present? There might be some differences in how the tracks are being mapped.

---

Aside, could you try to see if you can tell where the I-frames occur in the original video you're splitting? If they don't line up with the cuts exactly, that would explain why you're seeing these off-by-one errors when using codec copy mode. Could you also try manually running ffmpeg on a few scenes, and see if you can tweak the timecodes to avoid the extra frame?

You can also try using the load-scenes command to do the same thing and tweak the frame numbers.

Now literally every moment has a frame from the next one at the end.

If this affects every single scene we can try to add a parameter to shift all start and/or end timecodes by a certain # of frames, or perhaps shrink them at the cost of maybe dropping a frame here and there.

[whatforiam]

Just to confirm, are the cuts for the video correct if you use a normal encoding mode (e.g. don't use copying mode)? From what you posted above this seems to be the case but I want to double check.

Yes, everything is well done in the normal mode. I'm just not completely satisfied with the usual encoding, because it uses a relatively static amount of bitrate. That is, if I take crf 17 and render on the processor, then in dynamic scenes the video bitrate will not rise above 5M, and in ordinary almost static frames there will still be a lot of bitrate. If I use -c:v hevc_nvenc -b:v 4M, then the same story. If there is an option that does not create additional frames at the end, and selects the required bitrate itself (that is, in low-moving scenes, low bitrate, more in dynamic ones), I would be grateful.

This shouldn't be possible... I'm unable to reproduce this behaviour locally, and can confirm that any arguments passed to the split-video command won't affect the analysis phase. Are you sure nothing else was running in the background that would affect performance when you tested that?

Oh, okay, sorry...
something was really different. I tried to restart the computer and the problem was solved

Could you check which audio tracks are present? There might be some differences in how the tracks are being mapped.

Again, after restarting my computer tried running them again and the size matched, apparently something went wrong for me during the first tests, apologies again

Aside, could you try to see if you can tell where the I-frames occur in the original video you're splitting? If they don't line up with the cuts exactly, that would explain why you're seeing these off-by-one errors when using codec copy mode. Could you also try manually running ffmpeg on a few scenes, and see if you can tweak the timecodes to avoid the extra frame?

I'm a little confused about the question, how do I understand this? Most videos have a frame of the following at the end. I tried to trim one moment (not the one I gave) and it turned out similar to this command

ffmpeg -ss 00:00:06.300 -i “[DB]Kyoukai no Kanata_-01(Dual Audio_10bit_BD1080p_x265).mp4” -to 00:00:01 -c copy “test.mp4”.

That is, the first piece goes to 06.300, the frame change is supposedly at 06.275 (presumably), and the next frame starts at 06.300.
So I suspect that maybe, it determines the places to trim at 0.1 of a second?

You can also try using the load-scenes command to do the same thing and tweak the frame numbers.

I'm sorry, I'm not good at this kind of thing. I'd just like to make it easier on myself to cut scenes. And judging by the name of the team, it smells like manual labor. If that's the case, I'd rather re-encode, losing quality in dynamic scenes. Is there any way to speed up the usual renderer (because 30 fps is not too much), and not lose quality in dynamic scenes, and not have excessive bitrate in quiet scenes?

If this affects every single scene we can try to add a parameter to shift all start and/or end timecodes by a certain # of frames, or perhaps shrink them at the cost of maybe dropping a frame here and there.

It's not on every frame, it did okay somewhere