H264 Driver
Marion Georgi
Since there are no pre-built drivers to do what I want, I am trying to write my own driver. I found lots of recourses for writing linux drivers but not specifically for webcams. Can you point me to some resources or provide an outline of what I need to do? I never wrote a driver before.
If v4l2-ctl doesn't list anything other than MJPG, it's probably because the camera itself doesn't support H264 raw stream, but only supports H264 embedded in MJPG frames (which is what skype/windows uses for h264 encoding cameras).
FWIW, I am upscaling DVD rips of Star Trek Deep Space Nine. These have always been tricky to upscale because the live action is 24fps, but the CGI is 30fps. In TVEAI 2.6 it took about 2 hours to upscale a 45 minute SD original, but produced an output that stuttered frequently. TVAI 3.0 takes closer to 3 hours, but produces a perfect VFR output. BTW, running two upscales at once took 5 hours, not 6 and running 3 at once took 7.5, not 9 - so if you have multiple files to process there is a definite advantage to running 3 at once.
I just upgraded my driver earlier today. I believe that the minimum is 520, in the popup. This is not available from Nvidia. If you download the driver from Nvidia today, it will fix the problem. If you cannot use the driver, just download the latest version.
So I just got my RTX 4070Ti And I keep getting this error even tho I have installed the latest driver. I think that instead of a game ready driver it requires a studio driver and my friend is telling me to buy a quadro gpu and I cannot afford it since I am trying to save money so, I have came to a conclusion that it requires a good gpu and a good cpu (I think) so it render with no struggle.
For me on my GTX 1080 Ti I am getting around 105% faster encoding/processing speed gain with TVAI v3.5.0 compared to what i am getting o VEAI v2.6.4 with the same video/settings.
But also bear in mind that since v3.0.0 (which you are running with, based on your post title) there were two major releases that focused on performance.
I am having problems watching any movie on my new debian 11 install under Kodi 19.1 and 19.5.
Pressing o says my Video Decoder: ff-h264 (SW). I tried to install everything what i tought can help ffmpeg gstreamer uggly and bad plugin every codec from repository but its not helping.
I tried to install the Nvidia driver to enable h.264 hardware decoding support for video playback and have the VDPAU option in Kodi but I had a big issue after reboot: Oh no! something has gone wrong after installing nvidia-34 driver - #2 by nonobio
Yes, it is not very young. I'm not going to commit too much at the risk of causing more problems because it works pretty well despite the absence of hardware decoding (the processor manages to decode most of my files). A solution would be for me to change my graphics card to a more recent one..., maybe one day
Thank you anyway
You can try running it and see if it works.
The absolute beauty of using the terminal commands to install things is that it is verbose.
It tells you what is going on. It tells you if the install was successful. If something goes wrong, it tells you what went wrong. It even offers suggestions on how to fix it. So much better than other methods that leave you wondering or mystified.
With Premiere now supporting GPU-based decoding of h.264 videos I would assume playback of my timeline (a bunch of 4k h264 videos, no effects applied) would have the load shared with the GPU. While playing back and looking at my task manager, most of the load is on the CPU, the GPU barely wakes up.
After many forums and articles I finally got to my problem. Rather than h.264 as a whole, the problem lied with the 4:2:2 colour space. None of nvidia's GPUs currently support HVEC 10 bit 4:2:2 decoding.
I then tried a different 4K h.264 clip shot on iPhone, one form a canon 70D and one from a DJI Mavic 2 all of which have 4:2:0 colour space and ta-daaaa GPU indeed takes on the work and CPU stays between 1-2%.
For the most part, the system seems to be working fine, but something seems to be grossly wrong with the H.264 encoding. With every I-frame, the shading seems to change, which persists throughout the subsequent P-frames. The next I-frame introduces different shading. Also, there seem to be artifacts in the produced video that are way worse than would be expected at the encoded bit rate.
RRSDK2011Q2 requires the TI DVSDK4, this has the 'platinum' high profile H.264 codec. The H.264 encoding works fine for us and we get nice results at 30fps HD resolution. If the bitrate is restricted we observe the expected blockiness in fast changing scenes, but there's no issue with colour.
We did not have to modify anything in the SDK or the DVSDK to get the codecs to work properly. We did however apply several small modifications to the RRSDK kernel and configuration, to provide extended or missing functionality. One important change is that we replace the MT9P031 driver completely with our own custom driver. We have experienced colour issues with the SDK driver in the past. It may be possible that the standard driver produces flawed video and this prevents the H.264 encoder from working normally.
What we actually do is capture capture and encode the video in our own C application. This was developed using the TI sample capture/previewer/resizer and 'encode' demos as a starting point. We integrated transport of the H.264 by incorporating calls to the GStreamer library which send the encoded H.264 packets via the appsrc element over various transports, to server targets running in parallel on the Leopardboard. (For example send out RTP packets over UDP to Darwin Streaming Server for RTSP delivery, or send straight UDP packets to crtmpserver for RTMP delivery). We followed this approach because it is highly customizable at a low level and allows us to build in specialized realtime features for our requirements.
We need to get H.264 compression in the camera and operate over 1394-S800. Has anyone attempted this before? Does anyone have any ideas or references to point us to? Does DaVinci have the horsepower to do this in real-time? Any replies gratefully appreciated!
2 days ago, something got updated that is preventing VLC from playing MP4 videos (H264 codec). Prior to this update these same files played OK.
What is now happening, is the sound is OK, but the video screen is black. Running VLC from a command produces these messages when playing
an MP4:
Prior to this update these same files played OK.
What is now happening, is the sound is OK, but the video screen is black. Running VLC from a command produces these messages when playing
an MP4:
Well, the video is decoded by the CPU now instead of the graphics card. That means not more not less than playing back videos will be more CPU intensive now (of course only for videos that can be decoded by the GPU).
I have the same problem.
But I have just Intel GPU. I tried all video outputs, but I still have black screen.
I cannot find the previous vlc codecs in Packman, so, I need to know if someone else solved that problem.
I also tried the setting the video output to XVideo (XCB) from Automatic, as suggested above. I did this alone and in combination with the hardware-accelerated decoding setting, failures are the same.
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
Subsystem: Lenovo Device [17aa:21ce]
Kernel driver in use: i915
Then VLC stops responding. The interface works (I can open menus and cick buttons), but nothing happens. If I close the vlc window, the vlc process keeps running until I kill -9 it.
Note the pulseaudio msg. I do not use pulse audio on the desktop, but audio works fine, since I can play mp3 files on VLC with no problem.
I just want to note that this only really applies to nvidia systems. For intel systems, libvdpau_va_gl1 is actually preferred.
But even in this case you might still try to uninstall it, maybe it has problems with your particular graphics chipset.
I'm new to these forums (just joined). I've been contributing to the open source remote desktop system XRDP for some time, and I wanted to ask a couple questions related to getting Intel's QuickSync hardware encoder working with it.
Right now, there is a prototype from Jay Sorg that works with
However, from what I can tell, both libyami and the i965 driver ( -vaapi-driver) look like they aren't really being maintained anymore. I can't seem to find any official announcement on this, but it looks like both are intended to be replaced and folded into -driver/tree/master/media_driver. As I have a brand new i9-12950HX system, I basically have to use something with Gen12 compat, otherwise it looks like these older libraries are not being kept up-to-date with the latest generation. To that effect, I posted this fix: -driver/pull/1544
That was a bit of a tangent, but I'm trying to find a path such that we can replace XRDP's prototype implementation here: _inf/yami_inf.c and here: _merge/xorgxrdp_helper/xorgxrdp_helper_yami.c with something that will work with media-driver.
So my questions are:
1. Are the "yami" and "i965" infrastructures deprecated, and is media-driver intended to fully replace both? If not, what is the supported status?
2. How hard is it to convert from the above YAMI implementation to something that would support media-driver, and are there any examples to get me started in the right direction? I could reverse engineer ffmpeg, but that might be overkill for what I need here.
I would like to let you know that we have a specific forum for this kind of issue and product, it is called the Intel Developer Zone. There you will receive the appropriate support on this and other concerns you may have related to this product.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
c80f0f1006