similar to: assert in nouveau_vp3_video_vp.c ?

Create the ref_bo without any storage type flags set for now. The issue probably arises from our use of the additional buffer space at the end of the ref_bo. It should probably be split up in the future. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Tested-by: Martin Peres <martin.peres at labri.fr> Cc: "10.0" <mesa-stable at lists.freedesktop.org> ---

As it turns out, with the proprietary firmware, the VP3 and VP4 interfaces are identical. Furthermore, this is all already implemented for nvc0. So these patches (a) move the easily sharable bits of the nvc0 implementation into the nouveau directory, and then (b) implement the other parts in nv50. The non-shared parts are still largely copies, but there are some differences, not the least of which

On Sat, 30 Nov 2013 12:54:45 -0800 Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Thu, Nov 21, 2013 at 5:22 PM, Ilia Mirkin <imirkin at alum.mit.edu> > wrote: > > On Thu, Nov 21, 2013 at 5:07 PM, Benjamin Morris > > <bmorris at nvidia.com> wrote: > >> On 11/19/2013 08:16 PM, Ilia Mirkin wrote: > >>> Hello, > >>> >

On Fri, Dec 6, 2013 at 7:36 PM, Benjamin Morris <bmorris at nvidia.com> wrote: > I've gathered a few hints regarding H264 video decoding on our hardware. Hopefully some of them will be useful. Very useful! > > First off, regarding naming in general. Our internal names for our video engines differ from the names you've been using. Below is a translation map between the

Adds H.264 and MPEG2 codec support via VP2, using firmware from the blob. Acceleration is supported at the bitstream level for H.264 and IDCT level for MPEG2. Known issues: - H.264 interlaced doesn't render properly - H.264 shows very occasional artifacts on a small fraction of videos - MPEG2 + VDPAU shows frequent but small artifacts, which aren't there when using XvMC on the same

Hi Maarten, I'm seeing these prints, which feel like they're accompanied by bad frames: 0x7f7fcb29ab70 is not a real ref: -0.011 72712/72709 0% 35% 1.0% 0 0 This comes from if (dec->refs[idx].vidbuf != refs[i]) { debug_printf("%p is not a real ref\n", refs[i]); // FIXME: Maybe do m2mf copy here if a application really depends on it?

Adds H.264 and MPEG2 codec support via VP2, using firmware from the blob. Acceleration is supported at the bitstream level for H.264 and IDCT level for MPEG2. Known issues: - H.264 interlaced doesn't render properly - H.264 shows very occasional artifacts on a small fraction of videos - MPEG2 + VDPAU shows frequent but small artifacts, which aren't there when using XvMC on the same

On Thu, Nov 21, 2013 at 5:22 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Thu, Nov 21, 2013 at 5:07 PM, Benjamin Morris <bmorris at nvidia.com> wrote: >> On 11/19/2013 08:16 PM, Ilia Mirkin wrote: >>> Hello, >>> >>> I hope this is an appropriate style of request for this forum. I added >>> code to support video decoding on the tesla

On Sun, Dec 5, 2010 at 8:43 AM, Lanny Marcus <lmmailinglists at gmail.com> wrote: > There are updates available, for the below multimedia packages (CentOS > 5.5, 32 bit), but I'm getting missing dependency errors from yum > update for these. <snip> >From the time the problem began, it had to do with Error: Missing Dependency: libx264.so.68 is needed by package

Hi CentOS, I just completed the yum update to 4.2, hoping to get included with libstdc++.so.6(GLIBCXX_3.4.4) for the x86_64. I need the libs to run cinelerra: [ryan at dorje]# cinelerra cinelerra: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by cinelerra) An: "rpm -q -i --provides -l libstdc++-3.4.4-2" returns: (A bunch of stuff....)

https://bugs.freedesktop.org/show_bug.cgi?id=101000 Bug ID: 101000 Summary: Cinelerra crashes with OpenGL output on mesa git Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee:

...Where do I go? Hi please forgive me if I missed something obvious, but I've been reading and searching for a couple days to no avail. I'm trying to get the latest cinelerra running on CentOS4.1 on a dual Xeon machine. I need: cinelerra: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by cinelerra) (x86_64) and apparently the latest available is:

Hi everyone. I have used cinelerra for several years and love the application, so thanks to all for the hard work. I recently started to edit 4K footage from a Canon 1DX Mk 2. This is obviously very slow even with a six core processor. So I am required to use proxy files to speed things up. This worked with fedora 28. However I have changed to Centos 7.5 and now have an issue, the proxy files

So now I'm to looking to implement NVDec and as far as I know the game submits a series of commands to the service. This commands are processed by Falcon and then it does its magic. Do you guys got any RE on Falcon commands and how they execute different workloads ? -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have just built cinelerra on CentOS 5 x86_64 and thought I should share my notes here for people who need it but cannot wait for the package to become available on rpmforge/dag. - Install the src.rpm for FC6 - Edit the .spec file and change the line BuildRequires: OpenEXR-devel to BuildRequires: openexr-devel - Create a symlink: ln -s /usr/include/OpenEXR /usr/include/openexr - Run

Is anybody out there who has ever tried to install any kind of DV-Codec running wine to process dv/avi files generated by Kino/Cinelerra (like using TMPEG for compression) and is interested in sharing experiences? I'm just asking before posting to the list... On my side, TMPEG/VirtualDub work like a charme for most formats, but i can't get the lil' bastard to open dv-stuff.

Has anyone on the list used one of these w/Linux? We currently use Linux + Cinelerra for editing uncompressed video (and a few dual G5 macs running Final Cut Pro). Current editing stations are getting a bit long in the tooth so I've been mulling over a mass upgrade. 8-) These cards are interesting to me because they are PCI-X and support 4 SATAII drives per multilane/infiniband

vorbis@xiph.org wrote: >Hello, this is the mailing list anti-spam filter at Xiph.Org. >We need you to confirm your e-mail message with the subject of >"Re: Please confirm your message". > >Please send a message to the following address, or simply use your >mailer's "Reply" feature. > > vorbis+confirm+1047633476.23331.c524c3@xiph.org >

vorbis@xiph.org wrote: >Hello, this is the mailing list anti-spam filter at Xiph.Org. >We need you to confirm your e-mail message with the subject of >"Re: Ogg Vorbis tracks in QT files". > >Please send a message to the following address, or simply use your >mailer's "Reply" feature. > > vorbis+confirm+1047633300.22723.3e382f@xiph.org >

D Richard Felker III wrote: > On Thu, Mar 13, 2003 at 07:26:21PM +0000, Mark Hills wrote: >>>I tried to bind the 'OggS' 4CC to the vorbis codec in mov.c, but it >>>doesn't seem to like it... anyway, in QuickTime AFAIK the vorbis track >>>is embeded in an Ogg container... so we have those alternatives: >>The example you give from Cinerlerra is the