[FFmpeg-devel] [RFC] How to fix DR+lavfi+vflip crash

[Michael Niedermayer]

On Wed, Dec 01, 2010 at 05:17:55PM -0800, Jason Garrett-Glaser wrote:
> On Wed, Dec 1, 2010 at 5:07 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Dec 01, 2010 at 04:53:59PM -0800, Jason Garrett-Glaser wrote:
> >> On Tue, Nov 30, 2010 at 2:26 PM, Stefano Sabatini
> >> <stefano.sabatini-lala at poste.it> wrote:
> >> > On date Saturday 2010-11-27 16:53:51 +0100, Stefano Sabatini encoded:
> >> >> On date Saturday 2010-11-06 18:21:55 +0100, Stefano Sabatini encoded:
> >> >> > On date Saturday 2010-11-06 18:10:04 +0100, Stefano Sabatini encoded:
> >> >> > > Hi,
> >> >> > >
> >> >> > > as you may know the command:
> >> >> > > ffplay INPUT -vf vflip
> >> >> > >
> >> >> > > crashes with many video codecs. This is a regression introduced by the
> >> >> > > direct rendering feature, since the codec request the frame to use for
> >> >> > > putting the decoded frame, it gets a frame with negative linesizes and
> >> >> > > crash
> >> >> > >
> >> >> > > (BTW the smacker regression also seems to depend on diect
> >> >> > > rendering, and precisely with the way the palette is initialized in
> >> >> > > avfilter_default_get_buffer, which doesn't use ff_systematic_pal()).
> >> >> > >
> >> >> > > A possible first step would be to define a CODEC_CAP_NEG_LINESIZES
> >> >> > > capability (suggest a better name), and set it in all the codecs which
> >> >> > > currently support this feature (I have no idea which of them, do
> >> >> > > you?).
> >> >> > >
> >> >> > > At this point I see two solutions. One solution would be to change
> >> >> > > get_video_buffer(), and make it invert the buffer when it detects the
> >> >> > > negative linesizes && the NEG_LINESIZES capability is not
> >> >> > > supported, *or* auto-add another filter just before the ffplay source.
> >> >> > >
> >> >> > > Such a filter (vflipfix - suggest better name) would work as a null
> >> >> > > filter if the frame is not inverted, and would readjust the frame if
> >> >> > > the linesizes are inverted.
> >> >> > >
> >> >> > > The second solution seems simpler and cleaner.
> >> >> >
> >> >> > To make it even more useful, we may add a capability to the filters,
> >> >> > and auto-add the vflip-fix filter when building the filterchain, and
> >> >> > fix all the filters which doesn't support negative linesizes.
> >> >>
> >> >> Patchset attached.
> >> >
> >> > Ping.
> >>
> >> I don't think this extra complexity is a good idea. ?I'd rather just
> >> modify vflip to do things the slow way (it's NOT an important filter)
> >> and just officially drop support for negative linesizes.
> >>
> >> This extra complexity would be worth it if it affected any use-case
> >> that matters. ?It doesn't.
> >
> > imagine a linear filter chain, apply each 2nd filter bottom to top.
> > This should reduce cache misses.
> 
> Raster-order accesses across a video frame don't cause cache misses on
> any CPU with hardware prefetch.

without checking all datasheets of all cpus i would assume that as the hardware
prefetch is unable to keep up with the CPU reading data it would lead to cache
misses.
But then maybe the execution stalls and waits for the prefetcher.
The end result is the same, the cpu has to wait for the slow memory because the
data was not in the cache
So if iam not missing something then this is a mere terminology disagreement

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101202/97799afb/attachment.pgp>