headers
Michael Niedermayer | 1 Nov 2006 02:22
Picon
Picon

Re: Improved remove-logo filter

Hi

On Tue, Oct 31, 2006 at 01:13:29PM -0800, Trent Piepho wrote:
> On Tue, 31 Oct 2006, Guillaume POIRIER wrote:
> 
> > Hi Trent,
> >
> > Were you able to work on improving your patch?
> 
> What was there to do?  Change the asm to use "+" constraints
> even though it doesn't always work with gcc 2.7.2?

does gcc 2.7.2 compile mplayer at all?

[...]
> > > > > : "=m" (accumulator), "=r" (i), "=g" (j), "=r" (mask), "=r" (image)
> > > > > : "m" (accumulator), "1" (i), "2" (j), "3" (mask), "4" (image),
> > > > >   "g" (logo_mask->width), "g" (stride)
> > > >
> > > >    : "+m" (accumulator), "+r" (i), "+g" (j), "+r" (mask), "+r" (image)
> > > >    : "g" (logo_mask->width), "g" (stride)
> > >
> > > I've read several places that you can't use "+" to indicate an input/output
> > > arguments in inline asm, it only works in machine descriptions.  I think it
> > > may have changed for newer versions of gcc.
> > >
> > > I've tried it, before and gcc doesn't complain about it, but it doesn't
> > > always work.  With broken constraints you will often get lucky and have
> > > everything work, and then some random change to some peice of unrelated
> > > code will have the optimizer make a choice that breaks the asm.  So, it's
(Continue reading)

Permalink | Reply | 32 comments |
headers
John Donaghy | 1 Nov 2006 05:27
Picon

Re: [PATCH] further dvr-ms playback improvements

I know this is getting ridiculous but I've discovered that the last
patch I submitted doesn't always work very well because in some cases
the audio tends to drift out of sync. It worked for a lot of my files
but for some it didnt. So I'd like to save Nico the trouble of
reviewing it and withdraw it. Later I'll submit something else,
probably in smaller chunks to make it easier to review.

The attached graph illustrates why the approach I tried can fail if
you're interested. What it comes down to is that you cant calculate an
accurate enough average frame time without reading ahead significantly
in the stream. So the average frame time based on the first few frames
can be badly wrong which is enough to make the video drift out of sync
with the audio.  There are ways I could improve the situation to
minimize the likelihood of this but I haven't found a good enough way
yet to guarantee the video wont drift out over time.

The current version in SVN is fine for straight playback because it
reads the average frame time from the container. This value is
normally perfect in in all the recordings I have but it was wrong in
my one HD sample, which is why I tried instead to calculate it. (In
the file in question the average frame time was set to 0.0166833 in
what I think is a PAL format HD recording. That value is half the
frametime of what an NTSC frame should be so maybe the recording was
actually NTSC progressive scan but I dont know. And I dont know what
the average frame time should be for progressive scan - presumably it
is half??? I need more samples where I can be sure of the source).

Seeking will still not work correctly with the current version because
you really need the frame number after the seek to set the correct PTS
value based on the average frame time. I dont know if there's a way to
(Continue reading)

Permalink | Reply | 8 comments |
headers
tony li | 1 Nov 2006 08:48
Picon

Failed in Compling RC1 under uclinux of blackfin

bfin-uclinux-gcc -o mplayer mplayer.o m_property.o mp_msg.o
asxparser.o codec-cfg.o cpudetect.o edl.o find_sub.o m_config.o
m_option.o m_struct.o parser-cfg.o playtree.o playtreeparser.o
spudec.o sub_cc.o subreader.o vobsub.o  unrarlib.o mixer.o
Hi, all,

I am porting MPLAYER RC1 into uclinux of blackfin, failed in compiling
it successfully. Anyone have some idea on this.

parser-mpcmd.o subopt-helper.o  libvo/libvo.a libao2/libao2.a
input/libinput.a   libmpcodecs/libmpcodecs.a libaf/libaf.a
libmpdemux/libmpdemux.a stream/stream.a libswscale/libswscale.a
osdep/libosdep.a libavformat/libavformat.a  libavcodec/libavcodec.a
libavutil/libavutil.a  libpostproc/libpostproc.a -Wl,-z,noexecstack
    -static         -lm            -lpthread       libfaad2/libfaad2.a
 liba52/liba52.a libmpeg2/libmpeg2.a tremor/libvorbisidec.a
libavcodec/libavcodec.a(mpegaudiodec.o)(.text+0x4d6): In function
`_decode_init':
mpegaudiodec.c: undefined reference to `_llrint'
libavcodec/libavcodec.a(imc.o)(.text+0x1da): In function `_imc_decode_init':
imc.c: undefined reference to `_log2'
libavcodec/libavcodec.a(imc.o)(.text+0x7da): In function `_imc_decode_frame':
imc.c: undefined reference to `_log2'
libavcodec/libavcodec.a(imc.o)(.text+0xd9a):imc.c: undefined reference
to `_log2'
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1
[root <at> localhost mplayer]#
Permalink | Reply | 1 comment |
headers
Attila Kinali | 1 Nov 2006 09:03
Picon

The path to RC2

Moin,

According to our "release schedule" ( 20060506085930.01576587.attila <at> kinali.ch
resp http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-May/042796.html )
we wanted to release 1.0 this year. As we just released RC1 and because
there are still some open issues, we will not be able to do so.

In order to speed things a little bit up, i would like to
ask what you think is needed for RC2 and how we could
achieve it. If possible, i'd like to have an RC2 by the end of
the year, so that we could make RC3 or 1.0 in spring or early summer.

			Attila Kinali

--

-- 
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
                         -- Deed of Morred
Permalink | Reply | 20 comments |
headers
Nico Sabbi | 1 Nov 2006 09:54
Picon

Re: [PATCH] further dvr-ms playback improvements

John Donaghy wrote:

>
> The current version in SVN is fine for straight playback because it
> reads the average frame time from the container. This value is
> normally perfect in in all the recordings I have but it was wrong in
> my one HD sample, which is why I tried instead to calculate it. (In
> the file in question the average frame time was set to 0.0166833 in

59.94 fps

> what I think is a PAL format HD recording. That value is half the
> frametime of what an NTSC frame should be so maybe the recording was
> actually NTSC progressive scan but I dont know. And I dont know what
> the average frame time should be for progressive scan - presumably it
> is half??? I need more samples where I can be sure of the source).

the frame time doesn't depend on the progressiveness/interlacing
of the video, but on the framerate. For some time now, for some obscure 
reason,
many american broadcasters have been transmitting ntsc content
tricked (changing the repeat-* in the sequence headers) so as to make
the video stream look like encoded ad double the framerate.
The decoder will have to deal with this change somehow in order it to show
it correctly on tv (that accepts 59.94 _fields_ per second, not _frames_ 
per
second as  indicated by the sequence headers), and repeat the other field
when indicated in the stream, so what's the benefit of this abomination
is really beyond my understanding.
I guess you stumbled on a transmission of this kind
(Continue reading)

Permalink | Reply | 7 comments |
headers
Reimar Döffinger | 1 Nov 2006 11:56
Picon
Picon

Re: [PATCH] vf_expand cripples aspect upon reconfiguring

> > Please test this, it seems simpler to me, and there is no need to store
> > the adjusted aspect, it seems to be used nowhere else.
> 
> Should have tested at least compilation. Fixed patch.

applied.
Permalink | Reply | 0 comments |
headers
Dominik 'Rathann' Mierzejewski | 1 Nov 2006 12:27

Re: The path to RC2

On Wednesday, 01 November 2006 at 09:03, Attila Kinali wrote:
> Moin,
> 
> According to our "release schedule" ( 20060506085930.01576587.attila <at> kinali.ch
> resp http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-May/042796.html )
> we wanted to release 1.0 this year. As we just released RC1 and because
> there are still some open issues, we will not be able to do so.
> 
> In order to speed things a little bit up, i would like to
> ask what you think is needed for RC2 and how we could
> achieve it. If possible, i'd like to have an RC2 by the end of
> the year, so that we could make RC3 or 1.0 in spring or early summer.

Well, DVDNav was supposed to be in 1.0, so it most certainly needs to go
through at least one RCx.

The latest channel reordering patch for multichannel audio is a "must have"
feature for me, now that I have four speakers.

It would be nice for the SSA/ASS renderer to be feature-complete by the
time we release 1.0.

It would also be a killer feature to make the h264 decoder at least as fast
as CoreAVC's. ;)

That's from the top of my head. For the rest, look at TODO and
wishlist.txt. ;)

Regards,
R.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Trent Piepho | 1 Nov 2006 12:42
Picon

Re: Improved remove-logo filter

On Wed, 1 Nov 2006, Michael Niedermayer wrote:
> On Tue, Oct 31, 2006 at 01:13:29PM -0800, Trent Piepho wrote:
> > On Tue, 31 Oct 2006, Guillaume POIRIER wrote:
> >
> > > Hi Trent,
> > >
> > > Were you able to work on improving your patch?
> >
> > What was there to do?  Change the asm to use "+" constraints
> > even though it doesn't always work with gcc 2.7.2?
>
> does gcc 2.7.2 compile mplayer at all?

Sorry, I meant 2.95, but I'm not sure if that's the case.  Some older gcc
docs explictly say you can't use "+", newer ones say you can, but with
various conditions (which change from version to version).

You might also want to look at these threads:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107475162200773&w=2
http://lkml.org/lkml/2006/7/8/251

Using "+m" vs "=m"/"m" is a complex issue.

>
> and if you use "=something" then you should also be aware of that for example
>  "=r"(a)
> :"r"(b)
>
> does not prevent %0 == %1 if you want an output to not be able to use the
> same register or memory location as an random input then you must use "=&..."
(Continue reading)

Permalink | Reply | 31 comments |
headers
Attila Kinali | 1 Nov 2006 12:59
Picon

Re: Failed in Compling RC1 under uclinux of blackfin

Hi,

On Wed, 1 Nov 2006 15:48:30 +0800
"tony li" <tonyli10 <at> gmail.com> wrote:

> bfin-uclinux-gcc -o mplayer mplayer.o m_property.o mp_msg.o
> asxparser.o codec-cfg.o cpudetect.o edl.o find_sub.o m_config.o
> m_option.o m_struct.o parser-cfg.o playtree.o playtreeparser.o
> spudec.o sub_cc.o subreader.o vobsub.o  unrarlib.o mixer.o
> Hi, all,
> 
> I am porting MPLAYER RC1 into uclinux of blackfin, failed in compiling
> it successfully. Anyone have some idea on this.

You are really learn-resitant.
Again: if your question is not about a specifc line of
code or does not contain a patch it DOES NOT belong to
-dev-eng.

It's not even a bugreport as you didn't follow
the guidelines in bugreports.html.

As it is now the third or forth time that i tell you not
to send your mails to -dev-eng i will apply some
measures if you send again an inappropriate mail
to -dev-eng.
Most likely i will set you on moderated, so that every
mail you send has to first go through a review process.
Or i just unsubscribe you (depending on my mood at that time).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trent Piepho | 1 Nov 2006 13:05
Picon

Re: [PATCH] further dvr-ms playback improvements

On Wed, 1 Nov 2006, Nico Sabbi wrote:
> > the file in question the average frame time was set to 0.0166833 in
>
> 59.94 fps
>
> > what I think is a PAL format HD recording. That value is half the
> > frametime of what an NTSC frame should be so maybe the recording was
> > actually NTSC progressive scan but I dont know. And I dont know what
> > the average frame time should be for progressive scan - presumably it
> > is half??? I need more samples where I can be sure of the source).
>
> the frame time doesn't depend on the progressiveness/interlacing
> of the video, but on the framerate. For some time now, for some obscure
> reason,
> many american broadcasters have been transmitting ntsc content
> tricked (changing the repeat-* in the sequence headers) so as to make
> the video stream look like encoded ad double the framerate.

Broadcasters stick with one resolution/framerate all the time.  They don't
switch back and forth from commercials to programs, video source to film
source, native HD to up-convert, and so on.

One of the ATSC standards they have to choose from is 1280x720 at
60000/1001 _frames_ per second.  Yes, frames, not fields.  Yes, that is
double the NTSC frame rate (and it's not interlaced either).

> The decoder will have to deal with this change somehow in order it to show
> it correctly on tv (that accepts 59.94 _fields_ per second, not _frames_
> per
(Continue reading)

Permalink | Reply | 0 comments |

Gmane