[FFmpeg-devel] [PATCH][RFC - DO NOT MERGE] Revert "mov: Discard invalid CTTS."

[Michael Niedermayer]

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 bugs. That would be really alot of duplicated code
> > 
> > This is a HARD disagree from me. A demuxe should not be 'fixing' timstamps. This is
> > an applciation level problem.
> 
> I entirely agree with this. Libavformat should export what is stored in
> the file as accurately as possible. It does not have enough information
> about the context/use case to fix timestamps, nor whether fixing is even
> required.
> 
> We can and eventually should provide optional code for timestamps
> generation/manipulation, e.g. in the form of a bitstream filter which
> would have access to accurate reordering information. But it should be
> entirely separate from the demuxer.

1. (doesnt apply for this case probably but can to other bugs)
you assume that what is stored can even be read and exported without 
modifying/fixing it in the process.
There certainly have been encoder/muxer bugs where this is not true

2. (also doesnt apply here but its by a hair only, if this was dts
instead of cts that is off, it would)
Timestamps can be used for deciding which packet to return next
from the demuxer. That is interleaving. If that is not fixed at the
demuxer level the output would be very hard to use, requiring potential
massive buffering to compensate

3. Timestamps are used for seeking. If the timestamps are all off then
not only would the demuxer output have to have its timestamps fixed
but also any seek requests would need to have them unfixed as the
demuxers internal timestamp list has not been fixed. And then there
is no real gurantee that a bug results in a list without duplicates
so seeking to a time 10 in a damaged list might not be unique. There
might be multiple 10 in there

4. There are other time related fields, like duration, start time and so on
if a +i*8 error is not removed close to where its read than it may
require some care so that demuxer interaction with duration 
and user interaction with duration behaves as intended. 

5. When dts and pts diverge massivly due to apparently a muxer bug as in
this case here. How do we ensure all applications handle this correctly ?
How does code after the demuxer be that a filter or the user app know
what is correct ?
At the level of the demuxer we can check for metadata and other hints
about the buggy muxer, we have access to all timestamps of all packets
of all streams. We can even seek to any point of the input file if we
need to to identify the buggy muxer. Then this information will tell us
if dts or pts is correct and what to do with the other.
after the demuxer a filter would generally have 1 packet at a time,
the first error it will see is a error of 8ms in the pts which then will
grow with each packet. Iam not so sure how one would detect this,
at the start this could be correct. just when the pts drift seconds away
from the dts it becomes clear that something is wrong.

So i dont know, but to me fixing this sort of bug at the demuxer level
seems alot easier. But iam absolutely not against any other way of fixing
this and timestamp (error) correction and bug workaround filters certainly
are very usefull too

all above are intended as suggestions and comments to help, nothing 
is intended as an objection or demand

Thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210311/cdf48d3e/attachment.sig>