![]() ![]() > performance, you really need to handle both output formats. > (and something else which escapes me right now) native. > nv12, ouch if you can do it at the GPU level with a shader. > the 70015 is native YUYV, outputting NV12 will incur a cpu conversion to On Wed, at 09:02:03AM -0800, Philip Langdale wrote: My test case is some DVD video where it plays great for a few secondsĪnd then goes input-full and then lags and av sync goes out ![]() Would it be safe to try and extract both fields back to backĪnd then return the frame immediately? That would probably help avoid Then hold it and return to mplayer saying that I don't have a fullįrame yet - then it comes back with more input and I get the secondįield. That might reduce the amount of time I spend waiting.Īnd to go back to interlaced content. I can optimise it by extracting a frame and then retrying the input. Right now it loops and hopes for the best I have to loop inside the decode call, waiting for space to free up or Submitting input, but because mplayer doesn't support that error I've tried my best to do this - I check for space before > The only time you should see input buffer full is when the output is being pulled slower than it is being generated or if the bitrate of the input clip is very low and so the TX to the hw runs many times faster than RT. And if the input fills up you can't block on the demux since otherwise the output won't run. So the demux can run way faster than normal sw decoders. For example for 720p it can run as much as 6xRT. > As Scott mentioned once the pipeline fills up the hw can run many times faster than realtime. > With single threaded mode of operation it is important for the application to check if there enough room in the HW before sending it data. The only time you should see input buffer full is when the output is being pulled slower than it is being generated or if the bitrate of the input clip is very low and so the TX to the hw runs many times faster than RT. With single threaded mode of operation it is important for the application to check if there enough room in the HW before sending it data.Īs Scott mentioned once the pipeline fills up the hw can run many times faster than realtime. In windows what we do is to connect to the renderer as both P and I and then to mark each individual sample as a frame or as interleaved field as appropriate. Interlaced support on linux was always a problem because of the lack of a standard way to signal it.īut some of the issues being seen here are strange. I am on the road and will look at the code in the next couple of days. There is now code contributed by adobe which converts YUY2 to NV12 using SSE2 and take a very minimal hit on the CPU (less than 5% on an Atom). The 70012 natively supports NV12 and YUY2. The latest code has the NV12 support for the 70015. Perfection and crystalhd while very good, it just does not work likeĪlso Naren (from Broadcom) subscribes to this list and should pop in I highly doubt that this wouldĮver get into ffmpeg proper. Also XBMC is pretty much the only app that does theĭtsProcOutputNoCopy. Soįor best possible performance, you really need to handle both outputįormats. Is NV12 (and something else which escapes me right now) native. To nv12, ouch if you can do it at the GPU level with a shader. ![]() The 70015 is native YUYV, outputting NV12 will incur a cpu conversion >enabling NV12 on the 70015? I saw some comments in the archive for I'd love to get a little more insight into these issues maybe I'm But I've seen the gstreamer plugin work well before, it's always grumpyĪnd slow and can't keep up. Is this just how it is?ģ) The 70012 doesn't seem to work very well with my code. I usually have to call ProcInput over 20 times before any frames come backĪnd simply waiting before ProcOutput doesn't help. On the 70012, these values seem to be much more believable.Ģ) It seems to take a really long time to get any frames out of the decoder. On successive frames, which completely messes up my handling. It seems that the source is a field pair but instead the TOP_FIELD flag is set Where it returns 0x70 flags (implying UNKNOWN_SRC) and for a couple of them, Interlaced frame reporting is very strange at times. There is no timestamp returned even when I set valid values on ProcInput.ĪspectRatio seems to be wrong - always 0 or 255. Some of which are unavoidably troublesome:ġ) PIB information returned on 70015 is dubious in many cases. I've encountered a few problems, some of which I've been able to work around and My first reasonably functional patch to the mplayer list: I've been working on mplayer support for crystalhd over the past few ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |