Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
F
FFmpeg
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
libremedia
Tethys
FFmpeg
Commits
e180129f
Commit
e180129f
authored
19 years ago
by
Diego Biurrun
Browse files
Options
Downloads
Patches
Plain Diff
spelling/grammar/wording
Originally committed as revision 4589 to
svn://svn.ffmpeg.org/ffmpeg/trunk
parent
291dcdb3
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/faq.texi
+15
-15
15 additions, 15 deletions
doc/faq.texi
with
15 additions
and
15 deletions
doc/faq.texi
+
15
−
15
View file @
e180129f
...
...
@@ -182,25 +182,25 @@ The build process creates ffmpeg_g, ffplay_g, etc. which contain full debug
information. Those binaries are strip'd to create ffmpeg, ffplay, etc. If
you need the debug information, used the *
_
g versions.
@section I do not like the LGPL, can I contribute code under the GPL instead
@section I do not like the LGPL, can I contribute code under the GPL instead
?
y
es, as long as the code is optional and can easily and cleanly be placed
under
#ifdef CONFIG
_
GPL without breaking anythng
, s
o for example
a new codec
or filter would be
ok
under GPL while a bugfix to LGPL code wo
nt
Y
es, as long as the code is optional and can easily and cleanly be placed
under
#ifdef CONFIG
_
GPL without breaking anyth
i
ng
. S
o for example
a new codec
or filter would be
OK
under GPL while a bugfix to LGPL code wo
uld not.
@section I want to compile xyz.c alone but my compier produced many errors
@section I want to compile xyz.c alone but my compi
l
er produced many errors
.
c
ommon code is in its own files in libav* and is used by the individual
codecs
, t
hey will not work without the common parts, you have to compile
the whole libav*
and i
f you wish disable some parts with configure
switches, y
ou can also try to hack it and remove more but if you
seriously
wanted to ask the question abov
e then you are not qualified for this
C
ommon code is in its own files in libav* and is used by the individual
codecs
. T
hey will not work without the common parts, you have to compile
the whole libav*
. I
f you wish
,
disable some parts with configure
switches.
Y
ou can also try to hack it and remove more
,
but if you
had problems fixing
the compilation failur
e then you are
probably
not qualified for this
.
@section
v
isual c++ produce
d
many errors
@section
V
isual c++ produce
s
many errors
.
y
ou need a
c
compiler (visual
c
++ is not compliant to the
c
standard)
i
f you wish for whatever weird reason use visual
c
++ for your
project
then you can link the visual
c
++ code with libav* as long as
you compile
the later with a working
c
compiler
Y
ou need a
C
compiler (visual
C
++ is not compliant to the
C
standard)
.
I
f you wish
-
for whatever weird reason
- to
use visual
C
++ for your
project
then you can link the visual
C
++ code with libav* as long as
you compile
the lat
t
er with a working
C
compiler
.
@bye
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment