[FFmpeg-trac] #7155(ffmpeg:reopened): Add option to stop writing at position relative to EOF

[FFmpeg]

#7155: Add option to stop writing at position relative to EOF
-------------------------------------+-------------------------------------
             Reporter:  clone206     |                    Owner:  (none)
                 Type:  enhancement  |                   Status:  reopened
             Priority:  wish         |                Component:  ffmpeg
              Version:  git-master   |               Resolution:
             Keywords:  ease_of_use  |               Blocked By:
  EOF                                |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by clone206):

 Replying to [comment:15 GfE]:
 > I was about to file the same feature request.
 > (Almost gave up, after losing over an hour on failing to understand
 where exactly ffmpeg wants FRs to go. Finally found this one, disguised as
 a /bug/.)
 >
 > Alas, 7 years in, -sseof is still missing its -toeof counterpart.
 >
 > Given ffmpeg's oftentimes steep learning curve, -ss, -to, and -sseof are
 amazingly simple and useful options. If exact frame accuracy doesn't
 matter and you e. g. quickly want to remove a fixed-length intro from a
 series of videos,
 > `ffmpeg -y -ss -01:23.456 -i "${indir}"/*.mkv -c:copy "${outdir}"/*.mkv`
 > is as efficient as can be.
 >
 > Doing the same with outros needlessly requires /much/ more studying and
 dedication to ffmpeg concepts and features - if you succeed within your
 time constraints, at all.
 >
 > Granted, solutions to complex problems tend to be complex. Also, complex
 solutions for simple but niche problems might not be worth the
 simplification effort.
 >
 > However, the task of stopping to read input N seconds before its EOF
 isn't any more niche or complex than -sseof.
 >
 > What happened to
 https://gist.github.com/withmorten/ea585798076fa020b757437f23aca768 why
 has it been ignored/stalled/dropped?
 >
 > It's hard to imagine for a dozen lines' patch to provide more usability
 improvement to the less-advanced. People like me would greatly appreciate
 if the patch was
 > * updated as necessary to match the current codebase
 > * then applied/merged

 Yeah tbh I had forgotten about this. What an odd exchange. Don't know if
 I've ever felt so gaslit. I'm actually working on my own audio format
 conversion software, which is on github under the same username, so that I
 can work with more modern c++ and rust code and  hopefully avoid such
 bafflement going forward.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/7155#comment:16>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker