Announcement

Collapse
No announcement yet.

AMD working on XvMC for r300g?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ghost_o
    replied
    The "bird test" is meant to be a joke in case anyone was wondering. It has been re-encoded at over 100mb/s at points.. Max for "any" currently supported codec is still 40mb/s at 1080p..

    That has been a joke "benchmark" floating around for quite some time..

    If you re-encode it to proper levels, it will play just fine.

    Leave a comment:


  • pingufunkybeat
    replied
    I've watched stuff such as Transporter 3 in full HD on a single core of my Phenom II.

    The birds still totally slaughtered me.

    There can be considerable difference between different HD content. Don't underestimate it. I don't think that any processor our there can do all of this in software on a single core.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by popper View Post
    many problems with what you say but ....

    " lol with XV even my old pc athlon x2 3800 was able to play H264 1080p videos without lost sync "
    B.O.L.L.O.C.K.S is a very good word for that.

    try decoding this PlanetEarthBirds.mkv 2 minute clip




    if your going to make claims like that jrch2k8 at least make sure to use quality 1080 High Profile Cabac x264 Encodes and not some bullish AVIVO Encoded junk Encode from a dix you want to call HD H264 1080p videos.
    ok i admit is not that file i played, i tested it with a torrented movie in h264 "the rise of the lycans" but is true i dont know exactly how it was ripped (not a video professional) but is true that it played just fine(and it looked extremly nice in my hdtv) so i kept that pc as HTPC since then.

    now i think is very nice transcoded (eye comparison not profesional in anyway) cuz i have the BD of that movie and an sony BD player and if there is any difference in the quality is not visible to me, but like i said im not a video professional

    Leave a comment:


  • pvtcupcakes
    replied
    Originally posted by droidhacker View Post
    One of the keys to playing HD content with a software decoder is intelligent frame dropping. If the A/V goes out of sync, it is quite a severe decoder problem. I notice that ffmpeg has this problem. Anybody know if there's a way to force it to keep in sync?
    For mplayer (which uses ffmpeg IIRC) I use:
    Code:
    mplayer -lavdopts skipframe=nonref:skiploopfilter=all file.avi
    There is a -framedrop option, but it didn't work for me.
    Using the above command let me play a 720p video on my Eee PC at about 17-20fps without the audio getting way ahead of the video.

    Leave a comment:


  • droidhacker
    replied
    One of the keys to playing HD content with a software decoder is intelligent frame dropping. If the A/V goes out of sync, it is quite a severe decoder problem. I notice that ffmpeg has this problem. Anybody know if there's a way to force it to keep in sync?

    And yeah, an X2-3800 seems to be the bare minimum for mostly-smooth decoding of 1080. Note: MUST lock the CPU to maximum -- if it is under max, then you are subject the the scaling delay, which *does* screw with playback.

    Leave a comment:


  • popper
    replied
    the boards edit time kicked in so i could edit this into the above.

    this is your real HD that all others are measured against inthe x264 Encoder world , ao use it to see If You Measure Up, most dont.

    "General
    Complete name : C:\PlanetEarthBirds.mkv
    Format : Matroska
    File size : 216 MiB
    Duration : 2mn 2s
    Overall bit rate : 14.8 Mbps
    Encoded date : UTC 2010-01-05 17:47:54
    Writing application : mkvmerge v2.9.8 ('C'est le bon') built on Aug 13 2009 12:49:06
    Writing library : libebml v0.7.7 + libmatroska v0.8.1

    Video
    ID : 1
    Format : AVC
    Format/Info : Advanced Video Codec
    Format profile : [email protected]
    Format settings, CABAC : Yes
    Format settings, ReFrames : 4 frames
    Muxing mode : Container [email protected]
    Codec ID : V_MPEG4/ISO/AVC
    Duration : 2mn 2s
    Bit rate : 14.0 Mbps
    Width : 1 920 pixels
    Height : 1 080 pixels
    Display aspect ratio : 16:9
    Frame rate : 23.976 fps
    Resolution : 8 bits
    Colorimetry : 4:2:0
    Scan type : Progressive
    Bits/(Pixel*Frame) : 0.282
    Stream size : 205 MiB (95%)
    Language : English

    Audio
    ID : 2
    Format : AC-3
    Format/Info : Audio Coding 3
    Codec ID : A_AC3
    Duration : 2mn 2s
    Bit rate mode : Constant
    Bit rate : 448 Kbps
    Channel(s) : 6 channels
    Channel positions : Front: L C R, Surround: L R, LFE
    Sampling rate : 48.0 KHz
    Video delay : 12ms
    Stream size : 6.55 MiB (3%)
    Title : Main
    Language : English"

    Leave a comment:


  • popper
    replied
    Originally posted by jrch2k8 View Post
    i think this wont happen any time soon, at least not until gallium get full openGL 3.2 support, why?

    1.) UVD2 is not that good to begin with and well and i doubt it will leave AMD documents review office soon

    2.) i think this far in time UVD2 or VA-API or VDPAU arent necessary anymore in the opensource world

    3.) all postproc code need to be ajusted for either one you choose or they have to be coded inside the library for the method you choose

    about number "2.)" think about it, support any of those will require an specific set of developer to maintain the code, this technologies are all propietaries to begin with and there is no way AMD support VDPAU api or nVIDIA support UVD2 to have some sort of standarization and VA-API is still too young and unsupported in almost all video players (at least not without have some patch and fix fun).

    so whatever of those 3 you choose will just add more overheat to the code and another VO devices (like we dont have enough already lol) in our favorite media player, beside the normal average joe dont need more complexity to watch videos.

    now is true that linux need hardware accelerated VO too, in my view the perfect solution should be XV output.

    1.)XV is tested and very well know, is fully supported everywhere, rigth now is better than anything in windows (at least in my experience) except when vdpau and UVD come to play, lol with XV even my old pc athlon x2 3800 was able to play H264 1080p videos without lost sync (i know is a nice cpu ofc XD but windows without gpu accel loose the sync in that pc )

    2.) Tear free video is a reality in xv in almost any configuration (intel, AMD and nvidia in all my pc's play tear free videos just perfectly, but is true that my pc's arent netbooks or toys like that)

    so you dont think that give a nice upgrade the current XV code would be the nicest solution? see my ideas

    1.) allow current XV code to load plugins instead of pure Xorg code, so when you initialize the overlay XV choose whatever engine fit best, note that this plugins will be only in the lower layer of the code, the one that actually process the frame not the external api to maintainiit transparent for the player

    2.) give XV 3 basic plugins: Xorg current code plugins, a fully shader 1.50 rendering plugin and a vdpau rendering plugin (in future could openCL instead of shaders ofc)

    3.) give XV a simple method to choose the output automatically based on the postproc and the video size/codec for example or simple a sub item in xv configuration inside video players

    4.) any postproc library you use woulndt need any modification or in the worst case only a minimal adjustment or optimization

    is a fact that this solution probably wouldnt be a match 100% with the vdpau performance but would be close enough in any decent card + the ability of being transparent and almost no need to do any recode in another library like postproc for example (ofc haveing this probably add shader rutines to postproc library would help a lot too)
    many problems with what you say but ....

    " lol with XV even my old pc athlon x2 3800 was able to play H264 1080p videos without lost sync "
    B.O.L.L.O.C.K.S is a very good word for that.

    try decoding this PlanetEarthBirds.mkv 2 minute clip




    if your going to make claims like that jrch2k8 at least make sure to use quality 1080 High Profile Cabac x264 Encodes and not some bullish AVIVO Encoded junk Encode from a dix you want to call HD H264 1080p videos.

    Leave a comment:


  • jrch2k8
    replied
    yes you are rigth but i still think that is more efficient to keep XV as and shader/openCL accelerated video ouput with plugins and add an library that handle the decode/decrypt the video at codec lvl and optimize libpostproc to use shader/openCL as a third library instead a big fat chunk doing it all and handle the output too and like i said you can avoid first the mass rewrite in application cuz XV would be almost transparent like always

    beside if we can make an accelerated decoder outside the video output anyone can use it for other stuff like dunno transcoding to another supported codec for example,etc (anyone said bindings :O )

    and ofc and standard accelerated postproc library would be awesome, cuz dev can focus in postproc techniques instead of debug the whole chunk like vdpau is and the fact it can be used by other application dunno gimp gap, cinelerra, whatever

    but well im a fan of modularity thats why i love KDE ;D

    Leave a comment:


  • agd5f
    replied
    The problem with Xv is that it only accelerates colorspace conversion and scaling (i.e., rendering of the decoded frame). The decode process (getting from compressed stream to frame for rendering) is still done in software which is where things like XvMC/VDPAU/VA-API come in.

    Leave a comment:


  • jrch2k8
    replied
    this can be done (i think) if you have an nvidia card, at least for now XD ofc until super gallium come to play

    Leave a comment:

Working...
X