[FFmpeg-user] FFmpeg Architecture

Paul B Mahol onemda at gmail.com
Tue Feb 13 20:39:54 EET 2024


On Tue, Feb 13, 2024 at 7:21 PM Mark Filipak <markfilipak.imdb at gmail.com>
wrote:

> On 13/02/2024 03.24, Paul B Mahol wrote:
> > On Tue, Feb 13, 2024 at 12:37 AM Carl Zwanzig <cpz at tuunq.com> wrote:
>
> Paul, Carl, I assume you are both familiar with the source code. I'm not.
>
> Fact: '-ss'-before-'-i' and '-i'-before-'-ss' _do_ give different results.
> I suggested that the
> difference might result from the way that FFmpeg is designed.
>

Not fact, your logic and math skills are really poor, reconsider additional
real educational summer camp.


>
> I mentioned dynamic versus static architectures. When thinking about
> dynamic versus static think
> "build up/tear down" versus "call". "Build up/tear down" versus "call" has
> to do with implementation
> -- how FFmpeg runs jobs -- not whether the job is streaming or real-time.
> In H.222, ISO & ITU imply
> (to me) that they had "build up/tear down" in mind when they created the
> system model they created.
>
> The question is this: Should '-ss'-before-'-i' and '-i'-before-'-ss' give
> different results? They
> _do_, but _should_ they?
>

No, it might or might not give different results.


>
> Set aside for the moment that '-ss'-before-'-i' and '-i'-before-'-ss' make
> differing cuts (at
> differing PTSs) that are hundreds of frames different.
> Set aside for the moment that '-ss'-before-'-i' honors '-muxdelay 0' but
> '-i'-before-'-ss' doesn't.
> Set aside for the moment that both of them cut the 'earliest' audio
> packets but both leave some
> 'too-early' audio packets in their results.
> Set aside for the moment that both of them include video packets that have
> 'too-early' PTSs that
> should have been cut.
>
> None of that matters for now.
>
> I can't submit a bug ticket unless I know whether '-ss'-before-'-i' and
> '-i'-before-'-ss' should
> give the same results. After that is established and I submit a ticket,
> assuming the answer is that
> they should be the same, then all the other details will be hashed out and
> all the fighting will
> occur in ... github? Is it github? I think so.
>

There is nothing to fix, bug is not here.


>
> Please help with this if you can.
>
> --Mark.
>
> _______________________________________________
> 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