h264parse does not correctly determine 'nal' alignment if this caps is provided.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58425
**Note**: for this change to work correctly, `h264parse` must be present.
-- v2: winegstreamer: Remove 'au' alignment for h264.
From: Brendan McGrath bmcgrath@codeweavers.com
h264parse does not correct unaligned input if this caps is provided.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58425 --- dlls/winegstreamer/wg_format.c | 1 - dlls/winegstreamer/wg_media_type.c | 1 - 2 files changed, 2 deletions(-)
diff --git a/dlls/winegstreamer/wg_format.c b/dlls/winegstreamer/wg_format.c index 9916a5a9961..bed7ffb2964 100644 --- a/dlls/winegstreamer/wg_format.c +++ b/dlls/winegstreamer/wg_format.c @@ -920,7 +920,6 @@ static GstCaps *wg_format_to_caps_video_h264(const struct wg_format *format) if (!(caps = gst_caps_new_empty_simple("video/x-h264"))) return NULL; gst_caps_set_simple(caps, "stream-format", G_TYPE_STRING, "byte-stream", NULL); - gst_caps_set_simple(caps, "alignment", G_TYPE_STRING, "au", NULL);
if (format->u.video.width) gst_caps_set_simple(caps, "width", G_TYPE_INT, format->u.video.width, NULL); diff --git a/dlls/winegstreamer/wg_media_type.c b/dlls/winegstreamer/wg_media_type.c index 44b39743bc3..b5ce04ef03e 100644 --- a/dlls/winegstreamer/wg_media_type.c +++ b/dlls/winegstreamer/wg_media_type.c @@ -296,7 +296,6 @@ static void init_caps_from_video_h264(GstCaps *caps, const MFVIDEOFORMAT *format gst_structure_remove_field(gst_caps_get_structure(caps, 0), "format"); gst_structure_set_name(gst_caps_get_structure(caps, 0), "video/x-h264"); gst_caps_set_simple(caps, "stream-format", G_TYPE_STRING, "byte-stream", NULL); - gst_caps_set_simple(caps, "alignment", G_TYPE_STRING, "au", NULL);
if (format_size > sizeof(*format) && (buffer = gst_buffer_new_and_alloc(format_size - sizeof(*format)))) {
On Thu Jul 3 21:09:06 2025 +0000, Elizabeth Figura wrote:
Ah, I see, and looking more carefully, there is a "NONE" alignment that's used if the alignment is missing. I don't see any sign that there's an intended caps value for NONE alignment, so leaving the field out is probably indeed best. However, that does mean the commit message is incorrect, and should not say 'nal'.
You are both correct. I've just updated the commit message. It looks like `h264parse` will just pass through the provided alignment if it is set, but will correct and provide the alignment if it is not. I just ran the following tests: ``` mkdir /tmp/video
# create nal aligned test video gst-launch-1.0 videotestsrc num-buffers=300 ! video/x-raw,format=I420,framerate=30/1 ! openh264enc ! h264parse ! video/x-h264,alignment=nal,stream-format=byte-stream ! multifilesink location=/tmp/video/test_nal_aligned_%05d.h264
# create unaligned test video cat /tmp/video/test_nal_aligned_* | split -d -a 5 -b 2048 --additional-suffix=.h264 - /tmp/video/test_unaligned_
# plays 'nal' alignment correctly gst-launch-1.0 multifilesrc location=/tmp/video/test_nal_aligned_%05d.h264 ! video/x-h264,width=320,height=240,framerate=30/1,stream-format=byte-stream,alignment=au ! h264parse ! avdec_h264 ! autovideosink
# plays unaligned incorrectly (expects 'au' alignment) gst-launch-1.0 multifilesrc location=/tmp/video/test_unaligned_%05d.h264 ! video/x-h264,width=320,height=240,framerate=30/1,stream-format=byte-stream,alignment=au ! h264parse ! avdec_h264 ! autovideosink
# plays unaligned correctly (no alignment in caps) gst-launch-1.0 multifilesrc location=/tmp/video/test_unaligned_%05d.h264 ! video/x-h264,width=320,height=240,framerate=30/1,stream-format=byte-stream ! h264parse ! avdec_h264 ! autovideosink ```