After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 355584 - gst-ffmpeg / ffenc_flv generates unusable files
gst-ffmpeg / ffenc_flv generates unusable files
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal normal
: 0.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2006-09-12 14:41 UTC by Jyrki Muukkonen
Modified: 2006-10-06 14:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Jyrki Muukkonen 2006-09-12 14:41:42 UTC
I'm trying to generate FLV videos with gstreamer0.10-ffmpeg_0.10.1-2ubuntu1 and latest gst-ffmpeg/ext/ffmpeg/* source files CVS (ffmpegmux support) with a following gst-launch command line:

gst-launch-0.10 filesrc location=input.avi ! decodebin name=dec dec. ! videoscale ! video/x-raw-yuv, width=352, height=288 ! timeoverlay ! ffenc_flv ! queue ! mux. dec. ! audioconvert ! audioresample ! audio/x-raw-int, rate=11025 ! lame bitrate=32 ! queue ! mux. ffmux_flv name=mux ! filesink location=gst.flv

The generated file plays fine with ffplay. However, it is unusable with browsers' flash plugins: playback is way too fast (30sec clip plays through in few seconds). Also, the filesize is way too big. Playing with ffenc_flv's options (eg. bitrate) doesn't help.

Running the resulted file through ffmpeg results in a much smaller file which is also playable with a SWF based FLV player:

ffmpeg -i gst.flv -acodec copy -y foo.flv
FFmpeg version SVN-rUNKNOWN, Copyright (c) 2000-2004 Fabrice Bellard
  configuration:  --prefix=/usr --libdir=${prefix}/lib --shlibdir=${prefix}/lib --incdir=${prefix}/include/ffmpeg --enable-shared --enable-mp3lame --enable-gpl --enable-faad --mandir=${prefix}/share/man --enable-vorbis --enable-pthreads --enable-faac --enable-xvid --enable-dts --enable-amr_nb --enable-amr_wb --enable-pp --enable-libogg --enable-libgsm --enable-x264 --enable-a52 --enable-a52bin --extra-cflags=-Wall -g -fPIC -DPIC
  libavutil version: 49.0.0
  libavcodec version: 51.11.0
  libavformat version: 50.5.0
  built on Aug 24 2006 20:52:05, gcc: 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)
[flv @ 0x555ed230]skipping flv packet: type 5, size 16464, flags 0

Seems that stream 1 comes from film source: 1000.00 (1000/1) -> 30.00 (30/1)
Input #0, flv, from 'gst.flv':
  Duration: 00:00:00.0, bitrate: N/A
  Stream #0.0: Audio: mp3, 11025 Hz, mono
  Stream #0.1: Video: flv, yuv420p, 352x288, 30.00 fps(r)
Output #0, flv, to 'foo.flv':
  Stream #0.0: Video: flv, yuv420p, 352x288, q=2-31, 200 kb/s, 30.00 fps(c)
  Stream #0.1: Audio: mp3, 11025 Hz, mono
Stream mapping:
  Stream #0.1 -> #0.0
  Stream #0.0 -> #0.1
Press [q] to stop encoding
frame=  947 q=31.0 Lsize=    1348kB time=31.6 bitrate= 349.8kbits/s
video:1208kB audio:124kB global headers:0kB muxing overhead 1.163194%

The resulting foo.flv plays fine in the SWF player and its size is only 1.4MB, while the gst.flv generated with gst-ffmpeg is around 40MB.

This happens with all the input types I tried, including videotestsrc. Trying to use videorate to force the framerate doesn't help either.

My efforts to import a more recent ffmpeg snapshot to gst-ffmpeg tree failed miserably :)
Comment 1 Jyrki Muukkonen 2006-09-12 14:48:38 UTC
Oops. While copying the audio stream (ffmpeg ... -acodec copy) the resulted file is still broken. Re-encoding the audio also results in a small enough and usable file.

Still, this doesn't fix the filesize problem. FFmpeg is reporting "30.00 fps(r)" for the original and "q=2-31, 200 kb/s, 30.00 fps(c)" for the re-encoded file.
Comment 2 Edward Hervey 2006-09-13 08:49:58 UTC
what is the difference between fps(r) and fps(c) ?
Comment 3 Edward Hervey 2006-09-13 08:51:28 UTC
mwahahaha, I found the culprit:
Seems that stream 0 comes from film source: 1000.00 (1000/1) -> 30.00 (30/1)

Will have a deeper look at that
Comment 4 Edward Hervey 2006-10-04 17:07:21 UTC
it seems it's not only a fps issue... since the file outputted is MASSIVE.
Comment 5 Edward Hervey 2006-10-06 14:46:39 UTC
Fixed in cvs, Closing bug

2006-10-06  Edward Hervey  <>

	* ext/ffmpeg/gstffmpegenc.c: (gst_ffmpegenc_init):
	Properly initialize ->lmin, ->lmax and ->max_key_interval so we don't
	end up passing completely bogus data to the AVCodecContext.
	Fixes #355584