Maarten Lankhorst wrote:
For some reason mplayer handles all the above images as progressive with vdpau,
and it sets picture_structure to 3. I can see the interlacing on movement, but
it
doesn't seem like mplayer tells vdpau it is interlaced, sigh. :/
That's a shame. Is there another way
Maarten Lankhorst wrote:
Sadly mplayer tells vdpau to have all videos decoded as progressive so
I can't really do anything. :-(
I just had a look at an old copy of h.262 spec I have.
Unless I am misreading it seems that
picture_structure = 3 (frame) is perfectly valid for interlaced.
It
On 26.11.2011 22:23, Maarten Lankhorst wrote:
Hey Andy,
On 11/26/2011 01:44 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
Testing interlaced videos that decode correctly with nvidia vdpau would help
a lot to figure out what the proper way to handle interlacing would be, so if
someone has
Maarten Lankhorst wrote:
Testing interlaced videos that decode correctly with nvidia vdpau would help
a lot to figure out what the proper way to handle interlacing would be, so if
someone has a bunch that play with nvidia accelerated vdpaumplayer
correctly,
could you please link them? ;)
Hey Andy,
On 11/26/2011 01:44 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
Testing interlaced videos that decode correctly with nvidia vdpau would
help
a lot to figure out what the proper way to handle interlacing would be,
so if
someone has a bunch that play with nvidia accelerated
Hey Christian,
On 11/21/2011 05:49 PM, Christian König wrote:
On 16.11.2011 15:38, Maarten Lankhorst wrote:
Hey,
On 11/16/2011 02:47 PM, Christian König wrote:
On 15.11.2011 17:52, Maarten Lankhorst wrote:
Deleted:
- begin_frame/end_frame: Was only useful for XvMC, should be folded into
2011/11/21 Christian König deathsim...@vodafone.de:
On 16.11.2011 15:38, Maarten Lankhorst wrote:
If the decode_bitstream interface is changed to get all bitstream buffers
at the same time,
there wouldn't be overhead to doing it like this. For a single picture
it's supposed to stay constant,
On 11/22/2011 10:00 PM, Younes Manton wrote:
2011/11/21 Christian König deathsim...@vodafone.de:
On 16.11.2011 15:38, Maarten Lankhorst wrote:
If the decode_bitstream interface is changed to get all bitstream buffers
at the same time,
there wouldn't be overhead to doing it like this. For a
On 16.11.2011 15:38, Maarten Lankhorst wrote:
Hey,
On 11/16/2011 02:47 PM, Christian König wrote:
On 15.11.2011 17:52, Maarten Lankhorst wrote:
Deleted:
- begin_frame/end_frame: Was only useful for XvMC, should be folded into flush..
I'm not completely happy with the current interface also,
On 15.11.2011 17:52, Maarten Lankhorst wrote:
Deleted:
- begin_frame/end_frame: Was only useful for XvMC, should be folded into flush..
I'm not completely happy with the current interface also, but if you
remove the state tracker ability to control how many buffers are used,
which in turn
Hey,
On 11/16/2011 02:47 PM, Christian König wrote:
On 15.11.2011 17:52, Maarten Lankhorst wrote:
Deleted:
- begin_frame/end_frame: Was only useful for XvMC, should be folded into
flush..
I'm not completely happy with the current interface also, but if you remove
the state tracker
Hey all,
I'm convinced that right now the pipe_video_decoder and pipe_video_buffer are
unnecessarily complicated, and require simplification.
struct pipe_video_decoder
{
struct pipe_context *context;
enum pipe_video_profile profile;
enum pipe_video_entrypoint entrypoint;
enum
12 matches
Mail list logo
