Why is chromium-codecs-ffmpeg-nonfree called nonfree and not unstripped or restricted?

Asked by Alex Converse

Why is chromium-codecs-ffmpeg-nonfree called nonfree and not unstripped or restricted?

chromium-codecs-ffmpeg-nonfree is kind of a funny name. The Ubuntu ffmpeg packages include those MPEG decoders/demuxers by default. Ubuntu also includes "-unstripped" packages that include *encoders* for various patented MPEG formats.

Most Ubuntu packages that seem to include nonfree in the name either are closed source like (flashplugin-nonfree) or are licensed under terms incompatible with the Debian Free Software Guidelines (like ttf-xfree86-nonfree). FFmpeg as used in chromium-codecs-ffmpeg-nonfree is licensed under the LGPL v2.1.

Question information

Language:
English Edit question
Status:
Answered
For:
Chromium Browser Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Fabien Tassin (fta) said :
#1

i used nonfree as in non-patent-free. iirc, the equivalent codecs are shipped in multiverse.

Revision history for this message
Alex Converse (ajc30) said :
#2

I downloaded jaunty's libavcodec52 package

http://packages.ubuntu.com/jaunty/amd64/libavcodec52/download

strings libavcodec.so.52.20.0 | grep -i aac
aac_decoder
aac_parser
ff_aac_pred_sfb_max
ff_aac_num_swb_1024
ff_aac_num_swb_128
ff_aac_pow2sf_tab
ff_aac_spectral_sizes
ff_aac_codebook_vectors
ff_aac_kbd_short_128
ff_aac_kbd_long_1024
ff_aac_parse_header
ff_aac_spectral_bits
ff_aac_spectral_codes
ff_aac_scalefactor_bits
ff_aac_scalefactor_code
ff_aac_ac3_parse
aac_main
aac_low
aac_ssr
aac_ltp
Prediction is not allowed in AAC-LC.
Read beyond end of ff_aac_codebook_vectors[%d][]. index %d >= %d
More than one AAC RDB per ADTS frame is
Error decoding AAC frame header.
alex@barcelona:~/Desktop$ strings libavcodec.so.52.20.0 | grep -i 264
h264_decoder
h264_parser
h264_mp4toannexb_bsf
ff_h264_lowres_idct_put_c
ff_h264_lowres_idct_add_c
ff_h264_idct_add_c
ff_h264_idct8_add_c
ff_h264_idct_dc_add_c
ff_h264_idct8_dc_add_c
ff_h264_idct_add16_c
ff_h264_idct8_add4_c
ff_h264_idct_add8_c
ff_h264_idct_add16intra_c
ff_h264_lps_range
ff_h264_mlps_state
ff_h264_norm_shift
ff_h264_decode_rbsp_trailing
ff_h264_pred_init
ff_h264_decode_nal
ff_h264_decode_sei
ff_h264_decode_picture_parameter_set
ff_h264_decode_seq_parameter_set
ff_h264_find_frame_end
ff_h264_mps_state
ff_h264_lps_state
vdpau_h264
fast pskip (H.264)
memory management control operations (H.264)
enables constant quality mode, and selects the quality (x264)
minimum interval between IDR-frames (x264)
weighted biprediction for b-frames (H.264)
high profile 8x8 transform (H.264)
access unit delimiters (H.264)
H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
x264 - core %d
h264_mp4toannexb

As you can see both the AAC and H.264 decoders are present in this binary. This package lives in main not multiverse. This is libavcodec52 not libavcodec52-unstripped.

As far as multiverse goes, other multiverse codecs have the -multiverse suffix not -nonfree (like gstreamer0.10-plugins-bad-multiverse).

Revision history for this message
Alexander Sack (asac) said :
#3

personally I agree that -nonfree isn't nice ... however, -unstripped is proably even less meaningful for users. also the gstreamer plugin names are probably not really shining example for naming either: "bad" and "ugly" is not really less funny than -nonfree imo.

Revision history for this message
Reinhard Tartler (siretart) said :
#4

unstripped is even pretty misleading, the name was a mistake to begin with.

since karmic, there are no 'unstripped' ffmpeg packages anmore. The 'base' package includes stuff like aac, various encoders, etc., and is accompanied by ffmpeg-extra which is compiled against various optional 3rd party packages.

Can you help with this problem?

Provide an answer of your own, or ask Alex Converse for more information if necessary.

To post a message you must log in.