headers
Ingo Brückl | 29 May 2012 17:59
Picon

Crash with unsharp filter and x264 mp4 files

Since a short time ago (can't exactly say since when) I'm noticing a strange
behaviour with x264 encoded mp4 video files which I blamed the files for,
thinking they were buggy, but they aren't.

When playing those files with the unsharp filter (l7x7:1.7), there are some
greenish stripes at the top of the video and after a while MPlayer crashes
after printing "Ran out of numbered images, expect crash. Filter before vo
is broken." Without the filter, everything is fine.

You can experience this with one of our sample files, namely
http://samples.mplayerhq.hu/V-codecs/h264/mp4_h264/h264_parser.mp4
although this sample is too short to cause the crash.

I've had an issue with this filter once before (some alignment issue on
ffmpeg's side if I remember correctly). Any idea what it might be this time
(side effect of recent changes concerning frames / direct rendering?) or
what I should do to track it down?

Ingo
Permalink | Reply |
headers
Reimar Döffinger | 29 May 2012 19:48
Picon
Picon

Re: Crash with unsharp filter and x264 mp4 files

On Tue, May 29, 2012 at 05:59:25PM +0200, Ingo Brückl wrote:
> When playing those files with the unsharp filter (l7x7:1.7), there are some
> greenish stripes at the top of the video

That means it passes on the wrong size to get_image when doing direct
rendering, see the recent change to vf_ass.c

> and after a while MPlayer crashes
> after printing "Ran out of numbered images, expect crash. Filter before vo
> is broken." Without the filter, everything is fine.

Does that still happen? It means that the usage count tracking is
incorrect, however I haven't been able to trigger that case anymore
with latest SVN.
I guess this means we should rather disable the nonref_dr feature for
the release...
Permalink | Reply |
headers
Ingo Brückl | 30 May 2012 18:21
Picon

Re: Crash with unsharp filter and x264 mp4 files

Reimar Döffinger wrote on Tue, 29 May 2012 19:48:48 +0200:

> On Tue, May 29, 2012 at 05:59:25PM +0200, Ingo Brückl wrote:
>> When playing those files with the unsharp filter (l7x7:1.7), there are some
>> greenish stripes at the top of the video

> That means it passes on the wrong size to get_image when doing direct
> rendering, see the recent change to vf_ass.c

The attached patch (by analogy with vf_ass.c) fixes the greenish stripes (if
it's ok I'd like to commit), but...

>> and after a while MPlayer crashes after printing "Ran out of numbered
>> images, expect crash. Filter before vo is broken." Without the filter,
>> everything is fine.

...it doesn't fix this crash.

> Does that still happen? It means that the usage count tracking is
> incorrect, however I haven't been able to trigger that case anymore
> with latest SVN.

Reverting r34949 fixes the crash.

Prior to r34949, number in vf.c's vf_get_image() is always 0, causing the
usage of just the first vf->imgctx.numbered_images. After r34949, number is
always -1, causing the search for a "free" vf->imgctx.numbered_images. This
is very often the first one (index 0) as well, but sometimes the first ones
aren't "free" and the longer the video plays, this number increases. (I have
actually no idea what I'm talking about here.)
(Continue reading)

Permalink | Reply |
headers
Reimar Döffinger | 30 May 2012 20:57
Picon
Picon

Re: Crash with unsharp filter and x264 mp4 files

On Wed, May 30, 2012 at 06:21:03PM +0200, Ingo Brückl wrote:
> Reimar Döffinger wrote on Tue, 29 May 2012 19:48:48 +0200:
> 
> > On Tue, May 29, 2012 at 05:59:25PM +0200, Ingo Brückl wrote:
> >> When playing those files with the unsharp filter (l7x7:1.7), there are some
> >> greenish stripes at the top of the video
> 
> > That means it passes on the wrong size to get_image when doing direct
> > rendering, see the recent change to vf_ass.c
> 
> The attached patch (by analogy with vf_ass.c) fixes the greenish stripes (if
> it's ok I'd like to commit), but...

There is no need for max, mpi->width must/will always be >= mpi->w
(basically, width is the allocate dimension and w the used dimension).

> >> and after a while MPlayer crashes after printing "Ran out of numbered
> >> images, expect crash. Filter before vo is broken." Without the filter,
> >> everything is fine.
> 
> ...it doesn't fix this crash.
> 
> > Does that still happen? It means that the usage count tracking is
> > incorrect, however I haven't been able to trigger that case anymore
> > with latest SVN.
> 
> Reverting r34949 fixes the crash.
> 
> Prior to r34949, number in vf.c's vf_get_image() is always 0, causing the
> usage of just the first vf->imgctx.numbered_images.
(Continue reading)

Permalink | Reply |
headers
Ingo Brückl | 30 May 2012 21:55
Picon

Re: Crash with unsharp filter and x264 mp4 files

Reimar Döffinger wrote on Wed, 30 May 2012 20:57:26 +0200:

> There is no need for max, mpi->width must/will always be >= mpi->w
> (basically, width is the allocate dimension and w the used dimension).

So this patch should be ok?

> Obviously resulting in completely wrong output.
> I know kind of what is going on, but not why.
> My problem is that I can't reproduce it, can you please give exact
> instructions for reproducing?

I've sent you a small sample (as email). Play it with 'mplayer -vf-add
unsharp=l7x7:1.7' and soon it will crash.

Ingo
Attachment (vf_unsharp.patch): text/x-diff, 609 bytes
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Permalink | Reply |
headers
Reimar Döffinger | 30 May 2012 22:17
Picon
Picon

Re: Crash with unsharp filter and x264 mp4 files

On Wed, May 30, 2012 at 09:55:41PM +0200, Ingo Brückl wrote:
> Reimar Döffinger wrote on Wed, 30 May 2012 20:57:26 +0200:
> 
> > There is no need for max, mpi->width must/will always be >= mpi->w
> > (basically, width is the allocate dimension and w the used dimension).
> 
> So this patch should be ok?

I believe so.

> > Obviously resulting in completely wrong output.
> > I know kind of what is going on, but not why.
> > My problem is that I can't reproduce it, can you please give exact
> > instructions for reproducing?
> 
> I've sent you a small sample (as email). Play it with 'mplayer -vf-add
> unsharp=l7x7:1.7' and soon it will crash.

I can reproduce it now.
I have a suspicion that vf_clone_mpi_attributes might be the bad guy
here.
Permalink | Reply |
headers
Reimar Döffinger | 30 May 2012 23:04
Picon
Picon

Re: Crash with unsharp filter and x264 mp4 files

On Wed, May 30, 2012 at 10:17:51PM +0200, Reimar Döffinger wrote:
> On Wed, May 30, 2012 at 09:55:41PM +0200, Ingo Brückl wrote:
> > Reimar Döffinger wrote on Wed, 30 May 2012 20:57:26 +0200:
> > 
> > > There is no need for max, mpi->width must/will always be >= mpi->w
> > > (basically, width is the allocate dimension and w the used dimension).
> > 
> > So this patch should be ok?
> 
> I believe so.

Note that you should get better performance if you also change the other
one. If you play with -v you should see lots of "REALLOCATE" warnings
due to it.
Permalink | Reply |

Gmane