Re: [FFmpeg-devel] [PATCH] avcodec/svq1: fix interframe mean VLC symbols

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2871 bytes --]

On Mon, Oct 17, 2022 at 08:33:28PM +1100, Peter Ross wrote:
> On Mon, Oct 17, 2022 at 05:04:29AM +0200, Andreas Rheinhardt wrote:
> > Peter Ross:
> > > Fixes ticket #128.
> > > 
> > > The SVQ1 interframe mean VLC symbols -128 and 128 are incorrectly swapped
> > > in our SVQ1 implementation, resulting in visible artifacts for some videos.
> > > This patch unswaps the order of these two symbols.
> > > 
> > > The most noticable example of the artiacts caused by this error can be observed in
> > > https://trac.ffmpeg.org/attachment/ticket/128/svq1_set.7z '352_288_k_50.mov'.
> > > The artifacts are not observed when using the reference decoder
> > > (QuickTime 7.7.9 x86 binary).
> > > 
> > > As a result of this patch, the reference data for the fate-svq1 test
> > > ($SAMPLES/svq1/marymary-shackles.mov) must be modified. For this file, our
> > > decoder output is now bitwise identical to the reference decoder. I have
> > > tested patch with various other samples and they are all now bitwise identical.
> > 
> > Seems like this is not the only test whose reference needs to be
> > updated. There are also the fate-vsynth%-svq1 tests.
> 
> Right, the encoder. This change will cause previous videos created by the FFmpeg
> encoder to playback *with* artifacts in newer builds of FFmpeg with this patch
> applied. There is not much we can do about this, since there isn't place for a
> version string in the SVQ3 bitstream (unlike MPEG-4 etc).

it is possible i think to avoid this

we just need anything that differs reasonably consistently between the binary
encoder and the ffmpeg encoder
the first thing that comes to mind is the temporal reference values, we seem
to always store 0 but there may be other things we do that differ

This fix will need some caution so everything keeps working 
1. we need the decoder to detect the official and our old buggy encoder and 
   handle each appropriately
2. when we fix our encoder there are at least 3 ways
2a. avoid the ambigous codes, these will decode fine in all cases
2b. whatever we used to detect the official encoder we can mimic that too
    while fixing this. but that may be a one shot opertunity
2c. find a cleaner way to store our version first, implment that in the
    decoder and then use it in the encoder when we fix this. This would
    need some testing to make sure it works with the official decoder
    I see a few things that might work for the version. the decoder decodes
    some "embedded message", theres the temporal reference which seems not
    mattering
    there are various encoder choices that allow embeding some message if one
    really wanted

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope

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