forked from rdp/ffmpeg-windows-build-helpers
-
Notifications
You must be signed in to change notification settings - Fork 1
/
TODO
141 lines (85 loc) · 5.25 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
== actual todos ==
submit a patch? or tell mplayer they shuck (if they ar elosing packets without circ. buffer, then they just shuck LOL)
ffmpeg shared is dead...
after, check with updated opus [?]
mplayer build is dead
== maybe/never do, more on the never ==
vlc is dead with his pthreads? mine?
I prefer his anyway if that way does work better...how can I have mine here tho?
SHARED was hiding the linnnnnk error far far away...and also not even needing it...but should have failed on dll...unless I never used it!
real distro/installer/put it online
release "debug" builds, full static linkable builds [?]
make sure openssl still builds, doesn't conflict, etc. [jan-E]
ask the x264 guys what is a good fprofiled option out there...
were there any other places with suspect non march stuff?
native windows'ify it
then some download with all of it?
linux VM download with all of it
add 10040 to their error message translator
https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt lists some more dependencies, some of which even work with FFmpeg. Some might work with Mplayer. Might as well add them, right?
don't ffmpeg enable runtime cpu detect for march cases? [meh, just for a smaller binary? or does it make it faster?]
clean sandbox build all with libfdk [i.e. can it still build everything everything?]
march without runtime cpu with hard core 1GB y4m fprofiled x264 and amd/intel cpu specified...LOLyeah...ask sherpya if he gets any speedups.
complain to vlc you can't build multi thread make :P
tell mingw-w64 that they should support VARIANT
use libcaca git instead, tell them it still isn't enough...
test all things dvd to make sure they play anything...
mplayer git'ify'
blocked'ish by lack of easy access to their source
vlc git'ify
hopefully no longer blocked, but I'm not pointed at mainline yet... :P
-d should auto select "both 32 and 64 bit" [XXX make it into command line param too?]
command line option "don't update any git repos"
libav work with nonfree? meh
figure out how av_export workz with shared, to be able to tell so and so...
my guess is that it works with ffmpeg because the .lib files instruct it to use a dll? huhwuh?
ok you've got ffmpeg built static, and then .dll.lib.a files, right? so thiiis is a different import structure than pthreads uses, and allows you to use "uni .h" files.......so maybe pthreads win32 should be generating different .lib files or something?
so ffmppeg maybe it creates the .lib.dll.a file different, and so *that* one can work...there may be a way to get it to work
don't "always install libavcodec" [only when building VLC, maybe only ffmpeg too]
or smaller?
VLC, you should use ../plugins/accessibility [?]
you should also not use plugins [?]
after investigate more, does it use them now? meh
complain on anybody that I have to sed their .pc files [yikes!]
check for any other configs zeranoe uses?
fix all that are hard coded revision checkouts...meh
SDL check if has same bug with 2.0, if so then file it...
Qt check if same weirdness with 5.1, if so then file it...
it should notice when configure was originally from some other git commit...anyway today, if you go to ffmpeg, checkout a different branch, it doesn't reconfigure...
x264 pkg-config should specify -libpthread? (repro by compiling ffmpeg with windows threads, you'll see...)
tell them? others that require tweaks also?
out only real speedup hopes: configure ffmpeg --cpu, libx264 profile guided <sigh>
make march work with ffmpeg/x264
compare speeds, plus 64 vs 32 bit for everything
then with profiled LOL
tell those that fail with multi-threaded make
distribute "my own set of [I guess optimized?] binaries" that are processor optimized (if it even matters speed-wise LOL).
though mine do have pthreads...but hopefully I can test and report and get the zeranoe ones built that way...share the workload :)
move all downloads to some place I control...maybe even "all" downloads LOL
old downloads to sourceforge [?]
a distro that's a VM they can just open up and hit "go" in :)
ask a pkg-config mailing list?
make it compilable on windows native...
release a downloadable "click here to run it" to build full libfdk-aac on windows LOL
release "some 10 bit, some not" ?
command line?
release some compiler optimized? does it make a difference? real installer?
ancient debug builds, etc...hmm...sourceforge for legacy? yeah
add openmp, for libsoxr? (any other dependency?)
test fribidi git master (does 0.19.5 fail? it should?) with wine installed
tell orc+schro "you didn't well cross compile!"
more march stuff...today we have the namsy pamsy enable cpu detection stuffs :P
calculate size of each piece, put it on a wiki somewhere...
startup slowdown, too?
support external toolchains
then support "checking if they already have zlib installed into it"
--enable-none --enable-x264 --enable-all-gpl --enable-all-non-free
cleanup ramiro suggested for libgsm [?]
profile guided builds?
major libs
everything
other "-march" like options? fastmath? f full program?
x264 fomit frame pointer for 32 bit?
qt seemed to infer too much about the cpu [possibly?]
somewhere mentioned the old "-fwhole-project" setting again somewhere LOL hmm...for optimizing x264 possibly?
TWOLAME move to .pc?