Try to trim frames out of a video for motion tracked shitposting

Not op, but I guess -c:v can only cut at keyframes.

as the other guy said, -c:v copy only works on keyframes, and in this video the keyframes are in the most retarded positions.
So instead of making a new keyframe at a position, regenerating the B-frames and I-frames until the next keyframe and just ending it there, they have you re-encode the whole file (???)
71fps is an idiotic number for framerate particularly because it's a prime number

Blender doesn't have the concept of framerate. It'll read the literal number of frames in your file, ignoring your framerate altogether.
Incidentally, FFMPEG also does this when you perform frame-based operations like -frames:v 25

in context of this anime, it is. weeds out all the moralfags.

For real.

bump

goblin rape is though

The problem lies with -c:a copy. This messes up the frame count. You don't notice it with ffprobe, when you only select the video stream. Try again with ffmpeg but this time reencode the audio and it should work.
Handbrake reencodes the audio by default (and actually doesn't offer you the option of audio passthrough, if you trim the input). That's why it worked right off the bat.

>and actually doesn't offer you the option of audio passthrough, if you trim the input
Scratch that. I didn't notice my test file had Opus audio. That's why no passthrough was available.

It didn't work.
Exact command I ran
ffmpeg -ss 00:14:59.691 -to 00:17:24.044 -i "[HorribleSubs] Goblin Slayer - 02 [720p].mkv" -c:v libx264 -preset veryslow -crf 32 "[HorribleSubs] Goblin Slayer - 02 [720p] (2).mkv"
You'll notice the missing -c:a copy
I also attempted -c:a flac but no such luck

-c:v copy is worse for trimming and completely inaccurate

This guy is probably right, the audio copy is probably causing timing issues.

well obviously not
but it is still possible to be into the idea conditionally
like when you are at home and getting comfy and you imagine being jumped by say a werewolf

of course autists are unable to think in anything but black and white and think that people who are into rape-themes are sitting around waiting for literally anybody anytime

I have not seen goblin slayer though

you should put the seeking after the -i for one otherwise it uses some inaccurate faster version

>otherwise it uses some inaccurate faster version
I think that's only true for older versions.
I tried it anyway, same old extra 3.6x frames

Very weird. Does the problem persist if you suppress the audio entirely?

>you should put the seeking after the -i for one otherwise it uses some inaccurate faster version
That was the case in older versions. Nowadays it skips to the nearest preceding keyframe then encodes and discards everything until the specified timecode. For the old behaviour you need to add -noaccurate_seek to the command.

does
... -c:a libvorbis -b:a 320k ...

in addition to that command work?

ffmpeg -i "[HorribleSubs] Goblin Slayer - 02 [720p].mkv" -ss 00:14:59.691 -t 00:02:24.353 -c:v libx264 -preset veryfast -c:a libvorbis -b:a 320k "[HorribleSubs] Goblin Slayer - 02 [720p] (2).mkv"
Result: 12497 frames

ffmpeg -i "[HorribleSubs] Goblin Slayer - 02 [720p].mkv" -ss 00:14:59.691 -t 00:02:24.353 -c:v libx264 -preset veryfast -an "[HorribleSubs] Goblin Slayer - 02 [720p] (2).mkv"
Result: 12497 frames

So even without audio I'm getting extra frames in Blender. I'm even doing placebo shit like deleting the file before I encode

I am sorry user
I have had issues with ffmpeg and timings myself and usually encode each of the source videos with the same codecs before doing what I was going to do with the now already once encoded ones
and then I cry and hope it works

pretty interested in any potential resolution to the issue here

The bright side is that when I removed the audio and subtitle streams, -frames:v 25 actually started being accurate again
so your theory about the audio codec messing with the frames was probably right

ffmpeg might be screwy but Blender is just fucked beyond belief

audio codec user was originally suggested by another user I think

So some new information: The actual number of real frames is accurate in Blender, ffmpeg, and Aegisub.
However for some reason Blender now has a shitload of blank frames appended to the end of the video.
I guess I can live with that.

>blank frames
fairly sure that has something to do with the audio track being longer than the video track

I went ahead and downloaded the file. Your problem are the subtitles. Suppress them and you get the exact length you want.
I'm not too familiar with subtitle encoding, so I can't offer a solution on how to properly trim the subtitles yet. I guess hardsubbing might work, but I haven't tried it.

I dunno what's wrong with the file I have because I removed every stream
result from ffmpeg -i
Input #0, matroska,webm, from '[HorribleSubs] Goblin Slayer - 02 [720p] (3).mkv':
Metadata:
ENCODER : Lavf58.12.100
Duration: 00:02:24.35, start: 0.000000, bitrate: 17934 kb/s
Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
BPS : 2020007
BPS-eng : 2020007
DURATION-eng : 00:23:39.962000000
NUMBER_OF_FRAMES: 34045
NUMBER_OF_FRAMES-eng: 34045
NUMBER_OF_BYTES : 358541751
NUMBER_OF_BYTES-eng: 358541751
_STATISTICS_WRITING_APP: no_variable_data
_STATISTICS_WRITING_APP-eng: no_variable_data
_STATISTICS_WRITING_DATE_UTC: 1970-01-01 00:00:00
_STATISTICS_WRITING_DATE_UTC-eng: 1970-01-01 00:00:00
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
ENCODER : Lavc58.18.100 libx264
DURATION : 00:02:24.352000000

So adding -metadata:s:v:0 DURATION-eng=-1 seems to give me the exact number of frames I'm looking for
that's not removing the tag but what can you do

Son of a fucking bitch, all this time Blender has been caching videos

Attached: 1534452318926.png (1118x630, 1.02M)

>15 minutes in, there's an offset of -2 frames for no apparent reason
Edited out commercial break?

That's a possibility. I'd know if I went through ffprobe and actually looked at the frames.
But this is something I discovered after seeking to a timecode (15 minutes) and grabbing the next 35 frames--there's a -2 frame offset from what Aegisub reports.
So it could also be a timing issue

Goddamn. This is really fucking stupid. So I figured out what's ffmpeg's problem.
Video, audio and subtitle streams don't support different types of seeking syntax to the same extent, when it comes to frame accurate trimming.

Videos can be accurately trimmed with:
ffmpeg -ss -to -i
ffmpeg -ss -i -t
ffmpeg -i -ss -to

Subtitles can be accurately trimmed with:
ffmpeg -ss -i -t
ffmpeg -i -ss -to

-to before the input will be silently ignored and results in the subtitles going from -ss to the end of the file (this is what caused the extra frames mentioned here ).

Audio can be accurately trimmed with
ffmpeg -i -ss -to

What's even more confusing: Audio can only be accurately trimmed if the above syntax is being used and the audio gets copied. Reencoding the audio (no matter the syntax) will always produce a small error, albeit it less than copying the audio with the wrong syntax.

Attached: 1531251182863.png (452x710, 211K)

The final command, which solved all of my timing problems, without any placebos, was this
ffmpeg -ss 00:14:59.691 -to 00:17:24.044 -i "[HorribleSubs] Goblin Slayer - 02 [720p].mkv" -c:v libx264 -preset veryslow -crf 0 -an -sn "[HorribleSubs] Goblin Slayer - 02 [720p] (2).mkv"
Let's do a quick rundown on what's going on here:

-ss 00:14:59.691 -to 00:17:24.044
Trimming to the exact frame. If this is your intention, don't mix with -c:v copy Requires an encode; I chose lossless.

-sn
The subtitle stream has a `DURATION`, which causes blank frames to be appended to the video. This needs to be removed in order to be imported into Blender.

-an
This stream causes Blender to be confused and duplicate frames for seemingly no reason.
For those who need to split their video but don't need motion tracking, -c:a flac should be good enough.

>goblin slayer
pff I expected rape, and it was only implied
1/10 don't recommend

Nice. So the final command, without any "gotchas" or otherwise compromising on having streams stick around, would be
ffmpeg -i "[HorribleSubs] Goblin Slayer - 02 [720p].mkv" -ss 00:14:59.691 -to 00:17:24.044 -c:v libx264 -preset veryslow -crf 0 -c:a copy "[HorribleSubs] Goblin Slayer - 02 [720p] (7).mkv"
I've tested for accuracy in Blender, Aegisub, and ffmpeg by extracting exact frames as jpgs.

All of our problems were caused by operator order.
What do we even gain by making flag order important?

remux the mkv with mkvtoolnix and set framerate to 24000/1001 and audio delay to -83ms before doing any of that other stuff.
i've run into a similar issue with horriblesubs videos before and that fixed it for me.

>Blender--broken.
Did you set the correct fps in the render tab?

render tab's got nothing to do with motion capture, and blender don't care about framerate when it imports video clips

we already solved the problem

Nice. I didn't dissect the root cause as thoroughly as you did but I noticed that seeking issue when trying to burn subtitles onto a video with a mpv-webm script. The script was using the -ss -to -i syntax which made the subtitles that were burned in inaccurately timed.

Adding onto this, does -i, -ss, -t accurately trim all three (video, subtitles, audio)? I've been using that for my own webm scripts and I haven't really noticed anything off.

I just tested it out. I don't see any problems.
Subs work.
Aegisub shows the audio spectrogram lining up with the frames that I expect them to.
Blender has the right number of frames.
ffmpeg outputs the right jpegs when I extract frames.

So looks good to me. Must be real niche if it doesn't work for someone.

This thread is really good.
This is so rare on Jow Forums nowadays.

>and blender don't care about framerate when it imports video clips
It actually does but I'm not sure I remember why. Something about audio sync in the VSE if I recall correctly.

There's nothing better

>an actual good thread on Jow Forums that isnt talking shit but actual useful

Attached: 1533744412514.jpg (626x667, 69K)