[FFmpeg-user] FFmpeg Architecture

Paul B Mahol onemda at gmail.com
Wed Feb 14 09:51:36 EET 2024


On Wed, Feb 14, 2024 at 3:11 AM Mark Filipak <markfilipak.imdb at gmail.com>
wrote:

> On 13/02/2024 20.27, amindfv--- via ffmpeg-user wrote:
> >>> params *before* "-i" are *input params*
> >>> params *after* "-i" are *output params*
> >>>
> >>> that has *always* been the case at least for 15 years and so it's
> >>> logical that you can't place a param at a random position by common
> >>> sense and expect the same result
> >>
> >> Thank you, Harald. I knew that but your gentle reminder is welcome. It
> has
> >> helped me to better see the problem.
> >
> > This is documented in the first 2 sections here:
> https://trac.ffmpeg.org/wiki/Seeking
>
> Yes, Tom, and it essentially says they are very different in execution
> time but identical in result,
> which they're not, not even close.
>
> Also, '-i'-before-'-ss' is ignoring '-copyts'.
> Also, 'too-early' video packets are being output instead of cut.
> Also, 'too-early' audio packets are being output instead of cut.
> Also, the first audio packet that is erroneously passed is much smaller
> and has a different CRC than
> it should have even though this is a remuxing operation.
> The evidence of bugs throughout is overwhelming.
>
> Contrary to what's written, '-i this.m2ts -ss 20 -to 60' outputs 40
> seconds, not 60.
>
> Shall I go on?
>
> My question once again, in this thread's first post:
>
> Why are these different?
> ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn
> -muxdelay 0 %TARGET%
> ffmpeg -copyts -i %SOURCE% -map 0 -ss 20.061708333 -c copy -sn -dn
> -muxdelay 0 %TARGET%
>
> Note that "20.061708333" is a time, not a PTS.
>
> Why are they hundreds of frames different?
>

Because order of arguments in FFmpeg matters.


>
> We are over 35 posts in this thread (not counting 2 other threads of
> related stuff) and no one has
> even said whether they should or should not be the same.
>

I wrote it already that your requests are invalid.

Your questions is assuming only 1 possible outcome of only 2 possible cases.

I wrote already, it might or might not be the same.


Why you insist on 'should' is question for you, I doubt we will ever get
the answer.



>
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>


More information about the ffmpeg-user mailing list