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 712605 - h264parse: Broken conversion avc/au to byte-stream/nal
h264parse: Broken conversion avc/au to byte-stream/nal
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.2.1
Other Linux
: Normal critical
: 1.2.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-18 15:39 UTC by Aurélien Zanelli
Modified: 2013-11-28 15:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sintel-720p broken conversion backtrace (1.78 KB, text/plain)
2013-11-18 15:39 UTC, Aurélien Zanelli
Details

Description Aurélien Zanelli 2013-11-18 15:39:42 UTC
Created attachment 260140 [details]
Sintel-720p broken conversion backtrace

I try to play Sintel-720p (http://ftp.nluug.nl/pub/graphics/blender/demo/movies/Sintel.2010.720p.mkv) using the following pipeline:

$ gst-launch-1.0 filesrc location=/mnt/nfs/Sintel.2010.720p.mkv ! matroskademux ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=nal ! fakesink

and i get a SIGSEGV in h264parse (backtrace is attached).

The cause seems to be this block of code:
(from gst/videoparsers/gsth264parse.c:gst_h264_parse_handle_frame_packetized() )

> while (parse_res == GST_H264_PARSER_OK) {
>   GST_DEBUG_OBJECT (h264parse, "AVC nal offset %d", nalu.offset + nalu.size);
>
>   /* either way, have a look at it */
>   gst_h264_parse_process_nal (h264parse, &nalu);
>
>   /* dispatch per NALU if needed */
>   if (h264parse->split_packetized) {
>     /* note we don't need to come up with a sub-buffer, since
>      * subsequent code only considers input buffer's metadata.
>      * Real data is either taken from input by baseclass or
>      * a replacement output buffer is provided anyway. */
>     gst_h264_parse_parse_frame (parse, frame);
>     ret = gst_base_parse_finish_frame (parse, frame, nl + nalu.size);
>     left -= nl + nalu.size;
>   }
> 
>   parse_res = gst_h264_parser_identify_nalu_avc (h264parse->nalparser,
>       map.data, nalu.offset + nalu.size, map.size, nl, &nalu);
> }

The first call of gst_base_parse_finish_frame() clear the frame->buffer field.
The second iteration causes the segfault by calling gst_h264_parse_parse_frame() with frame->buffer = NULL.

At this moment, i'm not sure how to solve the problem,
Comment 1 Tim-Philipp Müller 2013-11-18 15:50:09 UTC
Oops, indeed. Luckily it doesn't look like that code path is triggered when one simply does h264parse ! mpegtsmux and similar thing.
Comment 2 Tim-Philipp Müller 2013-11-28 14:50:50 UTC
I think this is fixed now:

 commit 1b747bfecb6d36854aa19fbc6293676cc5eef390
 Author: Sebastian Dröge <sebastian@centricular.com>
 Date:   Thu Nov 28 15:10:16 2013 +0100

    h264parse: Fix splitting of multiple NALU per buffer
    
    Conversion to byte-stream/nal crashes without that because the
    baseparse frame of all NALUs is finished for the first NALU, then
    used again for parsing the second NALU. Just that now the buffer
    of the frame is already gone. Instead we create temporary frames
    for every NALU.

Thanks for the bug report! The fix will be in the upcoming 1.2.2 release.
Comment 3 Aurélien Zanelli 2013-11-28 15:53:47 UTC
Yes i confirm, it's works. Thanks for the fix.