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 749542 - On Windows most combinations of muxers/encoders do not work
On Windows most combinations of muxers/encoders do not work
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: dont know
1.4.5
Other Windows
: Normal major
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-18 12:50 UTC by Harry
Modified: 2017-07-12 00:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Harry 2015-05-18 12:50:01 UTC
I'm trying to convert on Windows a general-purpose C program for handling video files of all popular formats, from a commercial product to GStreamer.
I have managed to successfully implement all the functions, except for the transcoding of video/audio files, because I find that most combinations of muxers/encoders do not work.

The errors come in these flavors :
- Crashes
- Endless "Redistribute latency..."
- "could not link" errors (I can understand these ones as incompatible encoder/muxer, but why are they so frequent?)

An example for a crash :

gst-launch-1.0.exe
filesrc location="from.avi" ! decodebin name=d !
queue ! videoconvert ! x264enc ! queue ! avimux name=mux ! filesink location="to.avi"
d. ! queue ! audioconvert ! avenc_wmav2 ! mux.

An example for endless "Redistribute latency..." :

gst-launch-1.0.exe
filesrc location="from.avi" ! decodebin name=d !
queue ! videoconvert ! x264enc ! avimux name=mux ! filesink location="to.avi"
d. ! queue ! audioconvert ! avenc_ac3 ! mux.

In fact, the only combination I found to work well is OGG/THEORA/VORBIS.
In general, avenc_* encoders don't seem to work, but for most formats they are the only ones available.

Suggestion 1: Add to the documentation tables of compatible file-formats/muxers/encoders combinations that are known to work, by operating-system.

Suggestion 2: Create a new "transcode" plugin/mini-pipeline that works with profiles and even directly with media_type strings, and that supports the GstVideoOverlay interface for preview. It would be perfect if it could take at a minimum only the container media_type string and supply all the missing pieces. If decided, I would gladly add my voice when setting the specs.

This will take the black magic out of transcoding, which I currently find as very painful (at least on Windows). In fact, I'm blocked.

Suggestion 3: Write documentation for compiling on Windows GStreamer version 1.x, currently seemingly only available for version 0.10. This will allow Windows programmers like me to better analyze problems and even contribute.
Comment 1 Tim-Philipp Müller 2015-05-18 13:05:11 UTC
Have you tried any of these pipelines/combinations on Linux or any other operating system? They're probably not windows specific.

If you use x264enc in your pipeline, you need to either make the audio branch queues much bigger or unlimited, or use x264enc tune=zerolatency. This is a common problem with x264enc.
Comment 2 Harry 2015-05-18 14:16:17 UTC
I haven't tried on Linux, just saying that I'm on Windows.

Tried the command below and it still hangs on "Redistribute latency...".
(This is only one example of many combinations that don't work.)

gst-launch-1.0.exe
filesrc location="from.avi" ! decodebin name=d !
queue ! videoconvert ! x264enc tune=zerolatency ! avimux name=mux ! filesink location="to.avi"
d. ! queue max-size-buffers=32768 max-size-bytes=41943040 ! audioconvert ! avenc_ac3 ! mux.

The messages are :

Setting pipeline to PAUSED ...
0:00:00.299597722  7832  0C820640 WARN basesrc gstbasesrc.c:3470:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
Redistribute latency...
Redistribute latency...

The size of the input file is less than 2 MB for 11 minutes of video+audio, but this never finishes.
Comment 3 Harry 2015-05-20 07:37:07 UTC
I note that the above works correctly without the audio branch.

The conclusion is that either the audio source of avimux is non-functional, or avenc_ac3 is non-functional.
Comment 4 Tim-Philipp Müller 2015-05-20 08:20:52 UTC
So apply standard debugging techniques and narrow it down to a minimal pipeline that doesn't work, e.g. does this work?

 gst-launch-1.0 audiotestsrc num-buffers=500 ! avenc_ac3 ! avimux ! filesink location=ac3.avi

 gst-play-1.0 ac3.avi

?
Comment 5 Harry 2015-05-20 09:19:05 UTC
Apologies if I'm not yet up to speed on debugging techniques.
Results for the first :

gst-launch-1.0 audiotestsrc num-buffers=500 ! avenc_ac3 ! avimux ! filesink location=ac3.avi
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.367596792  8808   08F53208 ERROR  libav gstavaudenc.c:540:gst_ffmpegaudenc_encode_audio:<avenc_ac3-0> Failed to encode buffer: -22 - Error number -22 occurred
Got EOS from element "pipeline0".
Execution ended after 0:00:00.050150843
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

The resulting file ac3.avi is 142590 bytes long and is playable : 12 seconds of beeee...eeep.
Mediainfo confirms it as of AVI format and AC3 codec.

I note that gst-play is not included in the Windows release,
Comment 6 Tim-Philipp Müller 2017-07-12 00:21:37 UTC
Thanks for the bug report, but not sure what to do with this, sorry.

Lots of stuff has been fixed in the last two years. Windows documentation has been added.

Please file individual bugs for specific issues if they still happen with 1.12. For general pipeline support the gstreamer-devel mailing list might be best.