Jason Tackaberry wrote: > On Tue, 2007-22-05 at 10:33 +0200, Dirk Meyer wrote: >> It is a special case with self._vo_settings[0] = True. I had the >> straneg bug that aspect changes between two frames between two >> values. I have no idea why. > > I think this can happen with broken xine plugins. There used to be a > problem with expand that would cause varying pixel aspects as you > paused/unpaused. I don't think this should happen anymore. Can you > explain under what circumstances you saw this? If this is a workaround > to some xinelib bug then ok, but I'd like to better understand/document > it.
I will look for the buggy combination of video files and window size
that caused this bug next weekend.
The expand plugin causes a lot of problems, see the note at the
beginning of child.py:
| # The expand post-processing filter messes up changing the aspect
| # during runtime. It results in a black border sometimes, sometimes
| # the aspect change does not even work at all. Removing it fixes this
| # problem. This needs to be fixed!
| USE_EXPAND = False
I also have problems with PARAM_VO_CROP_* (see note on usage of this
in child.py) resulting in a crash. Maybe I use some parts wrong.
>> This includes the aspect. Do you have files where the aspect changes
>> two times between frames?
>
> Yes. I have an mpeg-ps file, a DVB capture. It starts with a 4/3
> aspect, and then the program begins and it switches to 16/9. All part
> of the same stream.
That should work. The only case where the code you commented out makes
a difference is when you have a new width, height or aspect and again
a new aspect _one_ frame later. BTW, content swicthing between 4/3 and
16/9 has some funny effect in mplayer and xine with the exapnd
filter. The picture gets smaller every time the aspect changes.
>> > # keep given video aspect in calculation (in most cases 1.0)
>> > - aspect *= vid_a
>> > + # Why multiply by vid_a? This isn't right.
>> > + # aspect *= vid_a
>>
>> So what is? I had a video where this is what I needed to make it
>> work. We need to calculate with vid_a at some point.
>
> This is admittedly tricky. :) I can say that multiplying by vid_a here
> is definitely wrong. We start with _stream_settings['pixel-aspect']
> being 1.0 which is correct for my display as my display has square
> pixels.
The monitor I used for testing is 1280x1024 with 4/3. These are non
square pixel.
> But then it gets multiplied by the video's pixel aspect.
> Consequently we're telling xine my display has non-square pixels.
I have no idea _what_ the parameter I return are about. You know,
missing and doc and such things. :)
I get an aspect in the function and give one back. I guessed it was an
extra scale aspect from either movie or window aspect.
Dischi
--
Maryann's Law:
You can always find what you're not looking for.
pgpUkjed9Xe91.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
