h264parse: nal.size of incoming frame is corrupted

[Vivia Nikolaidou]

Hi,

This looks like a bug in h264parse. Please file a bug here:
https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer (should be
gst-plugins-bad)

Make sure you include the debug output of one OK and one NG case (run
with the env var GST_DEBUG=*:6 and GST_DEBUG_NO_COLOR=1)

Thank you very much!

Best regards,

Vivia

On 17 March 2017 at 08:57, Makoto Harada <makotouu at gmail.com> wrote:
>> (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
>>
>>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel