[FFmpeg-trac] #3651(avcodec:open): UT Video Codec is inefficient compared to libutvideo
FFmpeg
trac at avcodec.org
Sun May 25 23:12:13 CEST 2014
#3651: UT Video Codec is inefficient compared to libutvideo
-------------------------------------+-----------------------------------
Reporter: Zerowalker | Owner:
Type: enhancement | Status: open
Priority: wish | Component: avcodec
Version: git-master | Resolution:
Keywords: utvideo | Blocked By:
Blocking: | Reproduced by developer: 1
Analyzed by developer: 0 |
-------------------------------------+-----------------------------------
Comment (by Zerowalker):
Actually at comment:5, you say the opposite from what i mean.
I am saying, doesn't the Native decoder use less threads and is much
faster, compared to ffmpeg?
Actually heard, or read about this, ppl pointed out the issues that it may
not always be correct when decoding, but i could never get a real answer
from it, so it ended up being ("a bug that probably has been solved").
But now that you confirm it, this makes things a bit, scary even as i use
Lagarith a bit.
I knew Floating Point was superfast but lacking in precision in cases (not
a programmer here;P), but i didn't know the difference in speed could be
this big.
But just to confirm this now, my CPU is an i5 760, Intel with x64.
Is this a non-x86 or not (I know it's x64, but i also think it's in the
x86 system, so if you could please clarify).
Cause if i use the Native decoder, will i always get the expected results
if i have this CPU, and it's only occuring on other builds, and other
systems (i am guessing, ARM etc?).
If so, that is "okay" for me, but indeed not alright for a lossless codec,
but it's hard to give up on the Codec, in some cases it yields
unparalleled results (Pixelated Game Capture), but it's pretty much only
there.
Sorry for many extra questions, but you certainly bring it up in a good
way, hope i am not wasting to much of your time!
--
Ticket URL: <https://trac.ffmpeg.org/ticket/3651#comment:14>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list