TL;DR — GStreamer 1.0 is the major version that changed how audio formats are defined. Released on 24 September 2012, it replaced the old audio/x-raw-int and audio/x-raw-float media types with a single audio/x-raw media type carrying a format string that maps to the GstAudioFormat enum (S16LE, U8, F32LE, and so on). If you also arrived here because of a "type conflict" error mentioning GObject, read the correction below: no GStreamer version ever redefined GObject.Object, and the real error is a GstObject clash from mixing 0.10 and 1.x in one process.

The short answer: GStreamer 1.0

If you searched for the GStreamer major version that changed the AudioFormat definition, the answer is the 0.10 → 1.0 transition. GStreamer 1.0.0 was the first release of the API- and ABI-stable 1.x series, and it deliberately broke compatibility with the 0.10 series to clean up a decade of accumulated design debt. The official release announcement explicitly lists "simpler and more descriptive audio and video caps" among the headline changes.

A few facts worth pinning down:

• Version: GStreamer 1.0.0
• Date: 24 September 2012
• Compatibility: Not API/ABI compatible with 0.10.x, but installable side by side
• Scope: A plugin-API-level change — most application code ported over with modest effort

Everything below explains what actually changed, why it changed, and how to fix code that still emits 0.10-style audio caps.

What actually changed in the AudioFormat definition (0.10 → 1.0)

In GStreamer, an audio "format" lives in caps (capabilities) — the structured description negotiated between elements on a pipeline. The 1.0 rewrite completely reorganized how raw audio caps describe a sample format.

Before: GStreamer 0.10 audio caps

The 0.10 series split raw audio across two media types and described the sample layout with a handful of separate fields:

• audio/x-raw-int — integer PCM, described with width, depth, signed, and endianness
• audio/x-raw-float — floating-point PCM, described with width and endianness

So a signed 16-bit little-endian stream looked roughly like:

audio/x-raw-int, width=16, depth=16, signed=true, endianness=1234, rate=44100, channels=2

This was verbose, error-prone, and made it awkward to enumerate or match "one specific format" in a single field.

After: GStreamer 1.0 audio caps (GstAudioFormat)

GStreamer 1.0 folded both media types into one and introduced a single format string, whose legal values come from the GstAudioFormat enum. The same signed 16-bit little-endian stereo stream becomes:

audio/x-raw, format=S16LE, layout=interleaved, rate=44100, channels=2

Key points about the new model:

1. One media type. audio/x-raw covers both integer and float PCM.
2. One format field. format is a string such as S16LE, U8, S24_32LE, or F32LE, mapping directly to GstAudioFormat.
3. New mandatory layout field. Values are interleaved (LRLRLR) or non-interleaved (LLL…RRR).
4. Helper API. Use GstAudioInfo (gst_audio_info_from_caps(), gst_audio_info_set_format()) to build and parse audio caps instead of hand-assembling fields.
5. Native-endianness helper. GST_AUDIO_NE(S16) expands to S16LE or S16BE depending on the host architecture — handy when you don't want to hard-code byte order.

The equivalent video change happened at the same time: video/x-raw-yuv and video/x-raw-rgb collapsed into video/x-raw with a format field.

0.10 vs 1.0 raw audio caps at a glance

Correcting the premise: GStreamer did not change GObject.Object

Some versions of this question are phrased as "the GStreamer major version that altered the definition of GObject.Object and caused the type conflict." That framing contains a false premise, and it's worth untangling because the confusion sends developers chasing the wrong fix.

No GStreamer release ever redefined GObject.Object. GObject is the base object system provided by GLib, a lower-level library that GStreamer depends on but does not own or modify. GStreamer builds on top of GObject: it registers its own type hierarchy — GstObject, GstElement, GstBin, and friends — into GObject's type system. Changing GStreamer's major version changes GStreamer's types; it does not rewrite GLib's GObject.

GObject vs GstObject — easy to conflate, important to separate

The error people actually see is about GstObject, GStreamer's own base class, not GObject. The two names look alike and sit next to each other in stack traces, which is almost certainly the source of the "GObject.Object" phrasing.

• GObject (a.k.a. GObject.Object in introspection/Python bindings): GLib's universal base class. Owned by GLib.
• GstObject: GStreamer's base class for pipeline objects, derived from GObject. Owned by GStreamer.

So the 1.0 transition did change GstObject and the rest of GStreamer's types — but it left GLib's GObject alone.

The real "type conflict": mixing GStreamer 0.10 and 1.x

There is a genuine, well-documented "type conflict," and it is related to the 1.0 major version — just not in the way the premise suggests. It shows up at runtime as warnings like:

GLib-GObject-WARNING **: cannot register existing type 'GstObject'
GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed
GLib-GObject-CRITICAL **: g_type_register_static: assertion 'parent_type > 0' failed

The cause is not a redefinition of any base object. It is that two incompatible major versions of GStreamer (0.10 and 1.x) get loaded into the same process — usually indirectly, through plugins, language bindings, or a dependency that still links the old series. Both libraries then try to register a type of the same name (GstObject, and cascading failures after it) into the single, shared GObject type system, and the second registration fails. GStreamer maintainers have repeatedly diagnosed this exact symptom as a 0.10-and-1.x mixing problem.

Because the GObject type system is per-process and type names must be unique, the first library to register GstObject wins and the second one's registration silently breaks — taking the rest of that library's type hierarchy down with it. This is precisely why the project made 0.10 and 1.x parallel-installable: they are meant to live in separate processes, never share one.

How to diagnose and fix it

1. List what's loaded. Check which GStreamer versions are pulled in: ldd on your binary, or inspect loaded shared objects at runtime for both libgstreamer-0.10 and libgstreamer-1.0.
2. Find the straggler. A plugin, a Qt/GTK multimedia backend, or a third-party library commonly drags in the old 0.10 series behind your back.
3. Pick one series. Rebuild or reconfigure so the whole process uses a single major version — almost always 1.x today.
4. Clear the plugin registry cache. A stale cache (e.g. ~/.cache/gstreamer-1.0/registry.*.bin) can also produce "cannot register existing type" noise; delete it and let it regenerate.
5. Check bindings. In Python, make sure you import the 1.x bindings (gi / gi.repository.Gst) and are not also pulling in the legacy gst-0.10 module.

Quick reference: porting 0.10 audio caps to 1.0

If you're modernizing old code, the audio-caps migration is mostly mechanical:

• Replace audio/x-raw-int and audio/x-raw-float with audio/x-raw.
• Drop width, depth, signed, and endianness; set a single format string instead.
• Add an explicit layout (interleaved unless you truly have planar data).
• Build and read caps through GstAudioInfo rather than poking fields directly.
• Use GST_AUDIO_NE(...) when you want host-native endianness.

Note that assembling caps like audio/x-raw-int, format=U16LE is invalid in both 0.10 and 1.x — it mixes the old media type with the new field. Commit fully to one model.

Volatile fact — verify before quoting. GStreamer's stable line remains the 1.x series. As of early 2026 the current stable branch is 1.26.x, with development snapshots in the 1.29 line. [VERIFY] the exact current point release against the official releases page (https://gstreamer.freedesktop.org/releases/) before publishing, as point releases ship frequently.

Conclusion

To answer the query directly: GStreamer 1.0 is the major version that changed the AudioFormat definition, unifying audio/x-raw-int and audio/x-raw-float into audio/x-raw with a GstAudioFormat-backed format field back in September 2012. If your search was prompted by a GObject/GstObject "type conflict," remember the two corrections here: no GStreamer version rewrote GLib's GObject, and the real error comes from loading 0.10 and 1.x in the same process. Your next step is simple — audit your process for a lingering 0.10 dependency, standardize on 1.x, and migrate any old-style audio caps using the checklist above. For anything version-specific, always confirm against the official GStreamer documentation linked below.

References

1. GStreamer — Porting 0.10 applications to 1.0 (audio/video caps simplification): https://gstreamer.freedesktop.org/documentation/application-development/appendix/porting-1-0.html
2. GStreamer — RELEASE: GStreamer 1.0.0 announcement, 24 Sep 2012: https://lists.freedesktop.org/archives/gstreamer-announce/2012-September/000265.html
3. LWN.net — GStreamer 1.0 released (parallel-installable, not compatible with 0.10): https://lwn.net/Articles/517433/
4. GStreamer — Audio Format reference (GstAudioFormat enum): https://gstreamer.freedesktop.org/documentation/audio/audio-format.html
5. GStreamer — Raw Audio Media Types (audio/x-raw, format, layout, GstAudioInfo): https://gstreamer.freedesktop.org/documentation/additional/design/mediatype-audio-raw.html
6. GNOME Bugzilla #722693 — "cannot register existing type GstObject" diagnosed as mixing 0.10 and 1.x: https://bugzilla.gnome.org/show_bug.cgi?id=722693
7. freedesktop GitLab issue #1790 — pygobject pulling in the wrong GStreamer version, same GstObject symptom: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1790
8. GStreamer — official releases page (current version, volatile): https://gstreamer.freedesktop.org/releases/