[FFmpeg-user] I found the bugs

[Paul B Mahol]

On Sun, Jun 16, 2024 at 10:19 AM Mark Filipak <markfilipak.imdb at gmail.com>
wrote:

> On 16/06/2024 03.51, Jim DeLaHunt wrote:
> > On 2024-06-15 23:04, Mark Filipak wrote:
> >
> >> On 15/06/2024 23.39, Jim DeLaHunt wrote:
> >>> On 2024-06-15 19:27, Mark Filipak wrote:
> >>>
> >>>> It would be nice if folks from here went here:
> >>>> https://trac.ffmpeg.org/ticket/11055
> >>>> and saw what is going on. It's up to 76 comments now, so what I ask
> will take you a while.
> >>>> What's going on is a crime.
> >>>
> >>> What's the crime, detective?  All I see is two people talking past
> each other and not being clear
> >>> about their evidence. I posted a comment with my feedback for you two.
> >>
> >> You posted an irrelevant comment supporting inadmissible info from one
> of the accused: FFprobe
> >> show_frames.
> >
> > _Who_ posted the criminal comment (the comment you describe as "What's
> going on is a crime")?  _I_
> > posted it?  Check again.
>
> No, Jim. I posted "it's a crime" here way before your comment on ticket
> 11055. "It's a crime" that
> MasterQuestionable is ignoring what would be legal proof in a court of law
> and is instead kicking up
> a load of dust. How anyone could argue that actual timestamps from actual
> packets plus actual
> timestamps from framecrc that match them perfectly are somehow
> disqualified or insufficient is
> beyond my comprehension. showinfo and show_frames are wrong and there's no
> two ways about it. The
> actual timestamps and what showinfo and show_frames report are miles
> apart. The bug in some internal
> routine that they use is wrong in this case, of a video with these
> particular properties, and I
> think that's true of '-ss' and '-to' and of transcoders in which AVC/H.264
> is the source.
>
> > Note that the XML file which MasterQuestionable attached is from
> ffprobe's -show_entries, not
> > -show_frames.
>
> Same thing.
>
> > If you want to assert that those are the same thing, and that
> -show_entries data is
> > untrustworthy for the same reason that -show_frames data is, then you
> should have some evidence for
> > that assertion.
>
> It doesn't matter, Jim. Do I have to find EVERY problem? I found two.
> Isn't that enough? Those two
> will lead to the others but it looks like it's going to be closed with no
> action, no code look, no
> testing. This all stinks and I'm sick of it.
>
> I know how to make perfect cuts and splices that play perfectly, open GOPs
> or closed GOPs, DTS-order
> or PTS-order, and I don't give a damn if FFmpeg wants to bury the news and
> leave everything
> unchanged. I'm finished with it. I got no support here and I see the
> picture clearly.
>

I find this situation very funny, finally Mark found someone on same level
of trolling skills.


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