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 615051 - h264depay: STAP are handled the wrong way
h264depay: STAP are handled the wrong way
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal critical
: 0.10.22
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-07 13:08 UTC by Marco Ballesio
Modified: 2010-04-13 13:07 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
proposed patch (1.13 KB, patch)
2010-04-07 13:08 UTC, Marco Ballesio 		none Details | Review

Description Marco Ballesio 2010-04-07 13:08:22 UTC 
Created attachment 158118 [details] [review]
proposed patch

in rtph264depay.c, lines 577-576, NALU-type 24 (Single-Time Aggregation Packet) is handled in fall-through as NALU-type 26 (unhandled).

This leads high quality h264 streams such as:

rtsp://stream.yle.mobi/yle/areena/MEDIA_E0342657_p3.mp4

to fail with "NAL unit type 24 not supported yet" (but it's actually supported), and thus to close any stream which contains STAPs.

The proposed one-liner patch fixes the issue.

NOTE: this is a regression from former releases, thus the critical severity.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2010-04-07 13:29:17 UTC 
commit 2ff1558a87a9bd6fc745765ed016758b765b887a
Author: Marco Ballesio <marco.ballesio@nokia.com>
Date:   Wed Apr 7 16:06:54 2010 +0300

    h264depay: handle properly STAPs
    
    in rtph264depay.c, lines 577-576, NALU-type 24 (Single-Time Aggregation
    Packet) is handled in fall-through as NALU-type 26 (unhandled).
    
    This leads high quality h264 streams such as:
    
    rtsp://stream.yle.mobi/yle/areena/MEDIA_E0342657_p3.mp4
    
    to fail with "NAL unit type 24 not supported yet" (but it's actually
    supported), and thus to close any stream which contains STAPs.
    
    The proposed one-liner patch fixes the issue.
    Fixes #615051.
Comment 2 Marco Ballesio 2010-04-13 12:37:53 UTC 
Another aspect of the issue has been found about the handling of codec-data with STAPs.

Reopening bug.
Comment 3 Marco Ballesio 2010-04-13 13:07:48 UTC 
Ok, after a chat with Mark Nauwelaerts looks like the codec-data separation is already granted, so closing again.