Re: [FFmpeg-devel] [PATCH] mlp_parser: fetch a new timestamp when major sync is found

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] mlp_parser: fetch a new timestamp when major sync is found
Date: Mon, 7 Mar 2022 18:10:19 +0100
Message-ID: <20220307171019.GK2829255@pb2> (raw)
In-Reply-To: <20220306223259.9491-1-jeebjp@gmail.com>

[-- Attachment #1.1.1: Type: text/plain, Size: 1535 bytes --]

On Mon, Mar 07, 2022 at 12:32:59AM +0200, Jan Ekström wrote:
> From: Hendrik Leppkes <h.leppkes@gmail.com>
> 
> Decoding can only start on a major sync

> and the parser discards
> any data received until that point.

Thats a bug and its inconsistant
For example video codec parsers do not drop frames until a keyframe
And droping that in a video codec would if someone suggested it
lead to people opposing as that would drop actual data
that can partly be decoded. Its better to drop it in the decoder
if its unwanted.
So why is this considered to be "ok" in audio codecs?
Because we dont visually see that data is lost ?

So let me show it vissually :)
i deleted frame 1, we have 3 decoder outputs
1. complete data
2. no frame 1 but instead frame 17 duplicated in frame 1s place
3. no frame 1

The decoder produces a few errors in case 2 but there seems more
data coming out which seems resembling the data that is droped
its not 1:1 identical but it looks like there is recoverable data
see attached screenshoot from audacity
Maybe its a coincidence

but i dont think we should just build on top of this droping
logic without some argumentation why this droped data can really
not be used ever in any way (it may become harder to fix it the
more is build on top)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri

[-- Attachment #1.1.2: truehd.ec1.png --]
[-- Type: image/png, Size: 69950 bytes --]

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".