BtbN changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.0 is released
jtgd has joined #ffmpeg
<jollyboyjohn>
been trying to use the "oversample" rescaler (mentioned here https://ffmpeg.org/ffmpeg-filters.html#Scaling) but it doesn't seem to exist anymore, has it been renamed or replaced?
celmor has joined #ffmpeg
KombuchaKip has quit [Quit: Leaving.]
beaver has quit [Read error: Connection reset by peer]
fling has quit [Read error: Connection reset by peer]
hussein1_ has quit [Read error: Connection reset by peer]
chiselfuse has quit [Read error: Connection reset by peer]
chiselfuse has joined #ffmpeg
beaver has joined #ffmpeg
fling has joined #ffmpeg
hussein1_ has joined #ffmpeg
<noobaroo>
kepstin It's a lot more than 0.1 second difference, it's usually 4-7 seconds
<noobaroo>
And there are several "buts" that I have here.
<kepstin>
that's odd, differences that large typically only happen if you're using stream copy mode or have otherwise disabled the accurate seek feature
<kepstin>
when doing transcoding with accurate seek, -ss before -i will seek to the closest keyframe before the seek point, discard the decoded frames before the seek point, and return frames starting after the seek point.
<noobaroo>
2nd but: Even if it wasn't frame accurate, I thought the entire point of using "-avoid_negative_ts 2 -reset_timestamps 1" is so the new video will have timestamps starting from 0, even if the cut doesn't actually start until a few seconds after specified with -ss
<noobaroo>
Yeah, that definitely doesn't happen for me.
KombuchaKip has joined #ffmpeg
<kepstin>
can you share your complete ffmpeg command line please?
<kepstin>
note that avoid_negative_ts and reset_timestamps are muxer (output) options, and have no effect on the timestamps of frames as seen e.g. at the filtering stage.
<kepstin>
reset_timestamps is specifically for the segment muxer
<noobaroo>
Well this was hours ago and I have run like 100 ffmpeg commands since then
<noobaroo>
But I think it happens basically every time, I think it happened twice recently again when I tried with 2 different new videos, one second
<kepstin>
avoid_negative_ts does nothing if you don't have any negative timestamps; and you won't have any negative timestamps when doing a transcode with -ss before -i.
<noobaroo>
Here's one, it happened on every video I tried today though and I tried on 3 different videos since early this morning
<kepstin>
ok. so that reset_timestamps option does nothing since you're not using the segment muxer. And you _are_ doing some stream copying, which will influence the behaviour of the avoid_negative_ts option
<kepstin>
if the audio or subtitle frame active at the seekpoint starts before the first video frame after the seekpoint, then resetting timestamps to start at 0 will set whichever of those is first to 0, which means the timestamp of the first _video_ frame will be >0
<noobaroo>
A workaround I found is by using combined seeking, I do "-ss 25:30 -i $V -ss 00:13 -t 00:15" and that achieves desired results perfectly. It starts at 0 and is frame accurate exactly where I set -ss
<kepstin>
you probably want the -t option to be after the -i not before it (tho that's unrelated to this issue)
<noobaroo>
What does that change?
<noobaroo>
And I don't know how audio frames work, but I doubt they are 4-7 seconds off the -ss point every time.
<kepstin>
with -t before -i, it stops reading frames and feeding them to the demuxer/decoder when the time on the input file is reached. with -t after -i, it stops encoding frames and writing them to the output file when the time on the output file is reached.
<noobaroo>
As for subtitles, that's the only video I tried that had them, so you can ignore the subtitle part
<kepstin>
and yeah, with most audio codecs that shouldn't be more than ~100ms or so.
<noobaroo>
So what could be the problem then? You said the -t before -i is unrelated to this issue, but I can only guess moving it to after must be the culprit here and the fix
<kepstin>
Well, at this point i could only suggest enabling some logging/debugging options to see what's going on with the timestamps. Consider using e.g. "-debug_ts" (probably along with "-frames:v 2" or something since you're really only interested in the timestamps of the first frame).
<kepstin>
what format is the input file, anyways?
<noobaroo>
One is .mkv, one is .mp4, and the third is either one of those or it might have been .m2t
<kepstin>
any correlation with specific formats? I could see issues happening with mpeg-ts due to the fact that it doesn't have a seek indexing; seeking in those doesn't really work properly.
<noobaroo>
It happens with every file
iive has quit [Quit: They came for me...]
<noobaroo>
I just tried with -ss before -i and -t after, and the video starts at 1.281 seconds
<noobaroo>
Though I just thought of something, I think I have converted to .mkv every time. I'll try to a mp4 and see if that fixes it
<noobaroo>
Do you know what's the raw format for av1? I fixed a timestamp issue yesterday by stream copying to a raw h264 file first, and then from that back to a real mkv container
<noobaroo>
Same results going to .mp4, 1.247 though this time
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
kus has quit [Read error: Connection reset by peer]
ivanich has quit [Remote host closed the connection]
kts has quit [Ping timeout: 252 seconds]
ivanich has joined #ffmpeg
kts has joined #ffmpeg
kts has quit [Max SendQ exceeded]
kts has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
kts has quit [Ping timeout: 240 seconds]
lavaball has joined #ffmpeg
kts has joined #ffmpeg
HerbY_NL has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
e^pi-1 has joined #ffmpeg
HerbY_NL_ has joined #ffmpeg
HerbY_NL has quit [Ping timeout: 268 seconds]
kts has quit [Ping timeout: 252 seconds]
e^pi-1 has quit [Quit: WeeChat 4.3.0]
e^pi-1 has joined #ffmpeg
kts has joined #ffmpeg
billchenchina has joined #ffmpeg
Livio has joined #ffmpeg
HerbY_NL_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
billchenchina has quit [Client Quit]
e^pi-1 has quit [Quit: WeeChat 4.3.0]
Tinos has quit [Ping timeout: 250 seconds]
e^pi-1 has joined #ffmpeg
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg
Suchiman has joined #ffmpeg
kts has quit [Ping timeout: 264 seconds]
HerbY_NL has joined #ffmpeg
kts has joined #ffmpeg
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
fling has joined #ffmpeg
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MetaNova has quit [Quit: quit]
MetaNova has joined #ffmpeg
Sl4yer has joined #ffmpeg
jagannatharjun has quit [Quit: Connection closed for inactivity]
Livio has quit [Ping timeout: 264 seconds]
jagannatharjun has joined #ffmpeg
iconoclasthero has joined #ffmpeg
kts has quit [Ping timeout: 268 seconds]
e^pi-1 has quit [Quit: WeeChat 4.3.0]
<iconoclasthero>
furq, with that dts that we remuxed into the mp4 container (I'm actually rockin war pigs atm), i was thinking about what you said...
<iconoclasthero>
<furq> specifically it's to fool dts decoders that are hooked up to cd players over optical / <furq> it's just everything else that gets confused / <furq> a small price to pay for a 99.3% compression ratio
<iconoclasthero>
so...i was poking around with this last week and just did a straight conversion to flac. and it was an enormous 24-bit 6-channel flac...which seems a bit much coming from a lossy format and I really don't think i'll ever have the audio equipment
<iconoclasthero>
(inside my head or not) to appreciate the difference b/w 16 & 24 bit.
<iconoclasthero>
what would be a reasonably efficient way to get a 6-ch flac that doesn't give up much in terms of the quality that we spent a fair amount of time to extract from the way the files were packaged initially?
beaver has quit [Remote host closed the connection]