On Thu, Mar 11, 2021 at 07:01:21PM +0100, Anton Khirnov wrote:
> Quoting Derek Buitenhuis (2021-03-11 12:50:03)
> > > the API user should receive valid timestamps and not need to handle that.
> > > it cannot be expected that every API user carries around workarounds for
> > > random
> > > muxer
On Thu, Mar 11, 2021 at 7:01 PM Anton Khirnov wrote:
> Quoting Derek Buitenhuis (2021-03-11 12:50:03)
> > > the API user should receive valid timestamps and not need to handle
> that.
> > > it cannot be expected that every API user carries around workarounds
> for random
> > > muxer bugs. That
Quoting Derek Buitenhuis (2021-03-11 12:50:03)
> > the API user should receive valid timestamps and not need to handle that.
> > it cannot be expected that every API user carries around workarounds for
> > random
> > muxer bugs. That would be really alot of duplicated code
>
> This is a HARD
On 11/03/2021 15:38, Michael Niedermayer wrote:
> You explicitly asked me to comment, and also stated that all options you
> listed suck:
Indeed, I was hoping for an insight that wasn't even worse hacks, though, or
an opinion on which was Least Bad. Maybe I should have been more clear in
my
On Thu, Mar 11, 2021 at 11:50:03AM +, Derek Buitenhuis wrote:
> On 11/03/2021 08:36, Michael Niedermayer wrote:
> > These are not enough to unambigously reverse engeneer the bug in the muxer
> > is it true for every output of the muxer, does it always happen at the
> > same position ?
> > is
On Thu, Mar 11, 2021 at 12:58 PM Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:
> On 11/03/2021 08:36, Michael Niedermayer wrote:
> > These are not enough to unambigously reverse engeneer the bug in the
> muxer
> > is it true for every output of the muxer, does it always happen at the
> >
On 11/03/2021 08:36, Michael Niedermayer wrote:
> These are not enough to unambigously reverse engeneer the bug in the muxer
> is it true for every output of the muxer, does it always happen at the
> same position ?
> is the runaway delta always 8 ?
> does it always coincide with the 2nd entry of
On Wed, Mar 10, 2021 at 05:49:45PM +, Derek Buitenhuis wrote:
> On 10/03/2021 17:24, Michael Niedermayer wrote:
> > what does the muxer exactly do ?
>
> I provided an explanation of what is happening during the broken muxing
> in my original email, as well as a sample, and a text dump of the
On 10/03/2021 17:24, Michael Niedermayer wrote:
> what does the muxer exactly do ?
I provided an explanation of what is happening during the broken muxing
in my original email, as well as a sample, and a text dump of the boxes.
Please see those.
Can you please actually fully read my emails and
On Wed, Mar 10, 2021 at 03:29:46PM +, Derek Buitenhuis wrote:
> On 08/03/2021 17:29, Michael Niedermayer wrote:
> > I would try to detect the specific abberant muxer based on the input.
> > Then have custom code in the demuxer which is based on reverse engnenering
> > the
> > issue to do a
On 08/03/2021 17:29, Michael Niedermayer wrote:
> I would try to detect the specific abberant muxer based on the input.
> Then have custom code in the demuxer which is based on reverse engnenering
> the
> issue to do a best effort to recover as much as is possible. And also print a
> big
>
On Mon, Mar 08, 2021 at 03:55:19PM +, Derek Buitenhuis wrote:
> This reverts commit 4093220029a4d77f272c491e9299680480a08c00.
>
> Signed-off-by: Derek Buitenhuis
> ---
> I have CC'd Michael here, as he is the original author here and the
> "soltuion" is nor clear.
>
> To explain this RFC:
On 08/03/2021 15:55, Derek Buitenhuis wrote:
> So the options are:
> * Revert 1fb9efbda0149c3491529ea5fa92cfdcb8cebfaa and detect them as I
> was already.
Copy-paste fail. This should say 4093220029a4d77f272c491e9299680480a08c00.
- Derek
___
This reverts commit 4093220029a4d77f272c491e9299680480a08c00.
Signed-off-by: Derek Buitenhuis
---
I have CC'd Michael here, as he is the original author here and the "soltuion"
is nor clear.
To explain this RFC:
We (Vimeo) have started seeing an uptick in broken MP4 files (what creates them
14 matches
Mail list logo
