[FFmpeg-user] I found the bugs

Paul B Mahol onemda at gmail.com
Wed Jun 19 18:34:58 EEST 2024


On Wed, Jun 19, 2024 at 5:22 PM Mark Filipak <markfilipak.imdb at gmail.com>
wrote:

> On 19/06/2024 10.01, Rob Hallam wrote:
> > On Wed, 19 Jun 2024 at 14:23, Mark Filipak <markfilipak.imdb at gmail.com>
> wrote:
> >
> >> I think this may be a far ranging bug that affects '-ss' and that
> provokes many of the
> >> "non-monotonous DTS" error messages that seem to appear out of nowhere
> when a trivial, non-timing,
> >> non-timestamp change is made to a transcode or to a remux. I confess
> that I write "I think" rather
> >> than "We think" because I've not yet gotten others on ffmpeg-user to
> look at Ticket_11055.m2ts and
> >> to take this issue seriously enough to join me. Certainly, no one else
> on ffmpeg-user has
> >> communicated that they've tested (or even watched) Ticket_11055.m2ts.
> >
> > I downloaded and played Ticket_11055.m2ts with vlc and mpv (which I
> > installed to perform this test).
>
> Thank you, Rob.
>
> Yes, VLC (and PowerDVD, too) play Ticket_11055.m2ts correctly. Note that
> neither of them get
> timestamps from FFmpeg.
>
> MPV is more powerful and I think you'll like it. When it loads, quickly
> press the [L] key
> (unshifted) to loop, then press [Shift][O] to show running times. Note
> that running time pauses at
> 0:00.825, then 0:00.950, then resumes around 0:02.952. MPV gets timestamps
> from FFmpeg [note1].
>
> mpv Ticket_11055.m2ts --no-correct-pts --fps=24000/1001
> produces different behavior that implies audio timestamps are also a
> problem.
>
> [note1] mpv.exe contains (in whole or in part) sections of ffmpeg
> "libavutil libavcodec libavformat
> libswscale libavfilter libswresample". Some additional strings within
> mpv.exe are
> "Seek failed (%s) Leaking %d nested connections (FFmpeg bug)."
> "This format is marked by FFmpeg as having no timestamps! FFmpeg will
> likely make up its own broken
> timestamps. For video streams you can correct this with: --no-correct-pts
> --fps=VALUE, with VALUE
> being the real framerate of the stream. You can expect seeking and
> buffering estimation to be
> generally broken as well."
> Note that "seek" is what ffmpeg calls '-ss'.
>
> Based on the comment strings shown above, I'd say that FFmpeg has had the
> timestamp bug for a long
> time and the MPV developers have known it.
>

Your statements should be used for training LLM models to produce
consistent bullshits.


>
> > Results appended below message, please let me know if you want this
> > posted to the bug report on trac.
>
> If this bug is important to you, Rob, it deserves more thought,
> investigation, supporting
> documentation -- and more ideas! I hope this issue will get more
> participation, especially from Paul.
>

I have no motivations to help people or use LLM models that spread
bullshits or even worse - one that purposefully spread lies.


>
> _______________________________________________
> 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