h264parse: nal.size of incoming frame is corrupted

Makoto Harada makotouu at gmail.com
Fri Mar 17 06:57:03 UTC 2017


> (NG)
> gst-launch-1.0 filesrc location=test.mp4 typefind=true '!' qtdemux name=demux '!' video/x-h264 '!' h264parse '!' video/x-h264,stream-format=byte-stream '!' mpegtsmux ! appsrc
>
ops.
sorry appsrc should be appsink.

Makoto

On 2017/03/16 20:03, Makoto Harada wrote:
> Hello experts,
>
> I'm now investigating the problem that h264parse does not work as expected in some cases.
>
> My pipelines are as shown below.
>
> (OK)
> gst-launch-1.0 filesrc location=test.mp4 typefind=true '!' qtdemux name=demux '!' video/x-h264 '!' h264parse '!' video/x-h264,stream-format=byte-stream '!' filesink location=test.h264
> gst-launch-1.0 filesrc location=test.mp4 typefind=true '!' qtdemux name=demux '!' video/x-h264 '!' h264parse '!' video/x-h264,stream-format=byte-stream '!' mpegtsmux ! filesink location=test.ts
>
> (NG)
> gst-launch-1.0 filesrc location=test.mp4 typefind=true '!' qtdemux name=demux '!' video/x-h264 '!' h264parse '!' video/x-h264,stream-format=byte-stream '!' mpegtsmux ! appsrc
>
> In OK case, h264parse works as expected and the test.h264/test.ts has correct data. We can decode this data as expected.
> In NG case, h264parse outputs corrupted h264 data.
> I see lot's of the "not processing nal size 1" message, when GST_DEBUG="h264parse:5".
>
> I made debugging and it turned out that nalu.size is corrupted in NG case as shown below.
> Other fields are ok. 
>
> (OK)
>    gst_h264_parse_handle_frame_packetized:<h264parse0> processing packet buffer of size 32
>    gst_h264_parse_handle_frame_packetized:<h264parse0>nal offset : 4, nal size 28           <= ok                                              
>    gst_h264_parse_handle_frame_packetized:<h264parse0>AVC nal offset 32                     
>    gst_h264_parse_process_nal:<h264parse0>processing nal of type 1 Slice, size 28           
>
> (NG)
>    gst_h264_parse_handle_frame_packetized:<h264parse0>processing packet buffer of size 32
>    gst_h264_parse_handle_frame_packetized:<h264parse0>nal offset : 4, nal size 1               <= nal size is corrupted to 1 !!
>    gst_h264_parse_handle_frame_packetized:<h264parse0>AVC nal offset 5
>    gst_h264_parse_process_nal:<h264parse0>  not processing nal size 1
>
> nalu.size is got by the first 32 bit data of buffer in incoming frame to h264pasre plugin.
> I confirmed this first 32 bit is broken at gst_h264_parse_handle_frame () while data size is expected.
>
> version of h264parse I'm using is 1.4.1.
>
> Question:
> 1. Is this known issue ? I could not find out the commit in git.
> 2. Who writes to this nalu.size field (first 32 bit of incoming frame to h264parse ) ?
>     parent class of h264parse or qtdemux ?
>     I could not figure it out the source code which does this yet.
>
> Any feedback is highly appreciated.
>
> Kind Regards,
> Makoto
>
>



More information about the gstreamer-devel mailing list