#10233: Compile with libraries with MSVC
-------------------------------------+-------------------------------------
Reporter: dimasafonis | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: build
| system
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by ArseGnomes):
Replying to [comment:1 Balling]:
>
> And anyway, MSVC produces worse binaries than gcc for windows.
I'm not going to disagree fully because I don't have the data, but based
on experience, I kinda doubt it... on the condition that ffmpeg doesn't
use any of the emulation APIs (pthreads, etc) that most GPL stuff tends
towards. I'm sure those build worse on MSVC since they're not meant for it
in the first place. There should really be a movement to start eliminating
all of that stuff and conditionally using Windows APIs regardless of how
painful it'll be (even switching to something like cmake to eliminate the
need for autotools; possibly the only thing more archaic than cmake;
would be a great jump forward), but it's not worth bringing up windows
anywhere near a GPL codebase, usually. FFMPEG is better than most
projects about it, some don't care, others you'll get a slew of "just
switch to linux id10T" style responses.
If I ever get bored enough to get it working I'll know for sure, but I
highly doubt I'll have the time. Here's my bit of data though:
While initially testing to see what I could do about getting x265
encoding speeds higher on my old workstation, besides the huge boost from
killing off the spectre / meltdown mitigations in the registry, I needed
to do encodes on files with HDR metadata / Dolby Vision prior to ffmpeg
supporting one or the other of those.
While testing 10-bit x265 encoding, I found that piping y4m frames from
ffmpeg to an external MSVC-built x265 was ~20% faster than using the
internal static linked x265. I tracked down a newer PGO build of x265
that put it more in the 20-30% range depending on options and resolution.
x265 is something like 70% assembly language so something else ugly is
going on. I suspect either thread-related or memory management related
because piping that much data to another process shouldn't be faster than
statically linked code. That's the only data I have on it really, maybe
it's just libx265, who knows.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10233#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
