Closed phyzical closed 2 years ago
@nihil-admirari (not sure if your still contributing but i know you were instrumental in getting the sponsorblock reworks out the door)
This is the SRT:
1
00:00:16,720 --> 00:00:19,109
all right everyone cody here welcome
...
Note that it starts at ~16 seconds.
This is the concat spec:
ffconcat version 1.0
file 'file:processing/20220109.Cody'\''s Algae Panel.en.srt'
inpoint 14.251000
It cuts everything before ~14 seconds, but there is nothing in SRT before 16 seconds, so FFmpeg throws an error. If I manually change 14 -> 17 in concat spec, FFmpeg succeeds.
Expected behaviour in this case is to simply subtract 14.251 from all timestamps in SRT file. Would you please file a bug with FFmpeg?
thanks for that speedy reply @nihil-admirari
happy to, will open one later today.
in the meantime i think last time i remember this occurred with the fact i use an alpine based dockerfile, but we got around it by just using a different format, (though that was related to prepossessing the video not subtitles)
is there anything you can think of that i can do as a workaround until they reply/patch. (maybe i can try using a another subtitle format? though from memory the settings i have was the best chance case of getting subtititles)
or can you replicate this without the alpine distro?
all good if not :)
last time i remember this occurred with the fact i use an alpine based dockerfile, but we got around it by just using a different format
Not really. You've encountered an FFmpeg issue, a patch for which was only recently accepted. You were unable to run a patched version, since it required glibc, which Alpine lacks.
or can you replicate this without the alpine distro?
Yes, it can be replicated without Alpine, and even without yt-dlp.
maybe i can try using a another subtitle format?
I tested all supported formats: VTT, ASS, SRT, LRC. None work. On the other hand, using -ss 14.251
instead of concat format generates a warning:
Cody's Algae Panel [64cEmjtwRgw].en.srt: could not seek to position 14.251
but does what it's supposed to do, i.e. just subtracts 14.251 from all timestamps.
is there anything you can think of that i can do as a workaround until they reply/patch
You can download and cut the video without subtitles, then cut the subtitles manually:
ffmpeg -ss 14.251 -i Cody\'s\ Algae\ Panel\ \[64cEmjtwRgw\].en.srt -c copy _.srt
and then manually merge subtitles with the video:
ffmpeg -i "Cody's Algae Panel [64cEmjtwRgw].mp4" -i _.srt -c copy _.mp4
When you open an issue on ffmpeg, please post link here for reference
@nihil-admirari thanks for taking the time to test everything and all those suggestions/workarounds
just filling out the issue now 👍
https://trac.ffmpeg.org/ticket/9646#ticket, let me know if i didnt include a good enough description and i will update accordingly
I'm afraid they're not gonna be satisfied. They have a list of requirements for bug reports: https://ffmpeg.org/bugreports.html.
master
, not on release branches. Latest builds by BtbN are OK, Alpine's FFmpeg is not.Very verbose logging is required: ffmpeg -v 9 -loglevel 99
, i.e. FFmpeg must be invoked with
ffmpeg -v 9 -loglevel 99 -f concat -safe 0 -i "20220109.Cody's Algae Panel.en.temp.srt.concat" -c copy temp.srt
(other options are superfluous).
Mentioning that -ss
issues a warning but does The Right Thing is a plus:
ffmpeg -v 9 -loglevel 99 -ss 14.251 -i "20220109.Cody's Algae Panel.en.srt" -c copy temp.srt
👍 will do this arvo
@nihil-admirari hmm any idea how i can get the "20220109.Cody's Algae Panel.en.temp.srt.concat" file? it seems all i have left is the original srt the updated video and the original video? (after running yt-dlp on the video in question)
updated the ticket i think given what you gave is hopefully enough to show what it should be doing.
just had a thought.. while i agree it should be the responsibility of ffmpeg to fix the issue we could add logic to just enforce like 0.000001 seconds i.e never allow it to strip right up to the start? i assume the same towards the end of the video?
maybe as a flag (incase others are stuck on ffmpeg builds that could never get the fix)?
(oh and can confirm the workaround works thanks again!)
any idea how i can get the "20220109.Cody's Algae Panel.en.temp.srt.concat" file?
Just save
ffconcat version 1.0
file 'file:20220109.Cody'\''s Algae Panel.en.srt'
inpoint 14.251000
in a file. In the future, https://github.com/yt-dlp/yt-dlp/pull/2793/commits/e068871e2c0c0c6efceecb3b85868fee87d61103 is going to preserve concat spec on --keep-video
.
updated the ticket i think given what you gave is hopefully enough to show what it should be doing.
You've added the logs for -ss
, which is good, but the primary offender is still there without a clean command line and with no logs at all.
ffmpeg -y -loglevel repeat+info -hide_banner -nostdin -f concat -safe 0 -i 'file:CodysLab/processing/20220109.Cody'"'"'s Algae Panel.en.temp.srt.concat' -map 0 -dn -ignore_unknown -c copy -movflags +faststart 'file:CodysLab/processing/20220109.Cody'"'"'s Algae Panel.en.temp.srt'
should be replaced with
ffmpeg -v 9 -loglevel 99 -f concat -safe 0 -i "20220109.Cody's Algae Panel.en.temp.srt.concat" -c copy temp.srt
and the logs of the above command should be added.
then we can manually do it by running
FFmpeg team does not need a workaround.
i can upload the files in question but they total over 1gb
You only need to attach SRT and a concat spec. They won't exceed a 1 MB.
we could add logic to just enforce like 0.000001 seconds i.e never allow it to strip right up to the start?
We cannot. The problem is not about cutting starting from zero, it's about cutting ending before the first subtitle appears. In this case, the difference between the end of the cut and the first subtitle is ~2 seconds, not 0.000001 seconds. If you cut too much, subtitles will get out of sync with the video.
okay i think it should be up to spec now thanks for the hand holding.
but i noticed i got 20220109.Cody's Algae Panel.en.temp.srt.concat: Result too large
or is this just due to increased verbosity?
We cannot. The problem is not about cutting starting from zero, it's about cutting ending before the first subtitle appears. In this case, the difference between the end of the cut and the first subtitle is ~2 seconds, not 0.000001 seconds. If you cut too much, subtitles will get out of sync with the video.
no worries makes sense 👍
okay i think it should be up to spec now thanks for the hand holding.
Almost done.
Please note: once the download is complete, the file will be deleted from our servers.
This is not OK. If you look at a neighbouring issue https://trac.ffmpeg.org/ticket/9167, you'll see that FFmpeg issue tracker has the ability to attach files. Please use it.
Result too large
I'm getting “Numerical result out of range.” Most likely it's a ERANGE
errno
, which has different textual representations on different systems: https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html.
This is not OK. If you look at a neighbouring issue https://trac.ffmpeg.org/ticket/9167, you'll see that FFmpeg issue tracker has the ability to attach files. Please use it.
ugh sorry completely overlooked the add attachment
thanks again :)
Closing this since there doesn't seem to be any workaround we can implement for this.
If anyone has a patch for the ffmpeg issue (and upstream doesn't accept it), please let us know so that we can apply it to https://github.com/yt-dlp/Ffmpeg-Builds
@pukkandan I get Numerical result out of range
, when there is a sponsorblock segment present and when I am trying to merge video, subtitle, thumbnail into one. What should I do?
Can we automatically skip merging the subtitle when this happens?
Checklist
Description
Hey,
i think i'm running into an issue on conversion + rewriting of the subtitles file when there is sponsorblock segments to be removed
url in question: https://www.youtube.com/watch?v=64cEmjtwRgw
my container https://hub.docker.com/r/phyzical/yt-dlp i run the scrapes from (if it helps)
( i thiink i'm running latest i last updated everything 7 days ago)
Verbose log