h264parse: nal.size of incoming frame is corrupted
Vivia Nikolaidou
n.vivia at gmail.com
Mon Mar 20 14:47:57 UTC 2017
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
More information about the gstreamer-devel
mailing list