problems generating an H264 stream

Chuck Crisler ccrisler at mutualink.net
Wed Mar 6 07:15:39 PST 2013 

Several other things have come together to convince me that the problem is
on the iPad/iDoubs decoding. The RTP stream is almost certainly valid, just
"not in the right format" to please iDoubs. The task I have is to get the
stream into that format, which requires properly setting the fragmentation
unit headers by generating a stream that recognizes that there are multiple
packets in the NAL. Yes, I know that 3984 uses 'should' for several of
these issues and that iDoubs probably isn't following the suggestions.

On Wed, Mar 6, 2013 at 9:47 AM, Chuck Crisler <ccrisler at mutualink.net>wrote:

>
>
> On Tue, Mar 5, 2013 at 6:27 PM, pfarmer <flacone at gmx.de> wrote:
>
>>  On 03/05/2013 10:45 PM, Chuck Crisler-2 [via GStreamer-devel] wrote:
>>
>> I have a rather unusual and convoluted pipeline. I am trying to generate
>> an H264 stream and send it out through the RTP H264 payloader. That is
>> happening but the packets are not what I want/need. All of the RTP headers
>> have the marker bit set. The H264 component of the packets (according to
>> wireshark) simply starts with a NAL unit header and have larger
>> 'first_mb_in_slice' counts until a NAL unit access unit delimiter packet.
>> What I need are packets with the FU-A headers. I think that this means not
>> byte-stream oriented, but I am not sure. What parameter(s) do I specify to
>> get those?
>>
>> My pipeline is like this: udpsrc -> mpegtsdemux -> h264parse ->
>> ffdec_h264 -> x264enc -> rtph264pay -> udpsink
>>
>> I have left out less important elements for clarity, like queues. I have
>> tried with and without h264parse, which doesn't seem to make any
>> difference. Here are the first few trace lines from h264parse in the trace.
>> I didn't think to get the decoder. :-( These are repeated many times.
>>
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977075402 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:2363:gst_h264_parse_sink_event:<VideoH264Parse> [00m Pushing
>> newseg rate 1, applied rate 1, format 3, start 81022722222, stop -1, pos 0
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977241036 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:1409:gst_h264_parse_sink_setcaps:<VideoH264Parse> [00m have
>> bytestream h264
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977294297 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:2312:gst_h264_parse_chain:<VideoH264Parse> [00m received
>> buffer of size 162
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977316913 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:1757:gst_h264_parse_chain_forward:<VideoH264Parse> [00m NAL
>> type: 1, ref_idc: 2
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977332555 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:362:gst_h264_parse_get_pps:<VideoH264Parse> [00m Creating
>> pps with pps_id=0000
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977371858 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:340:gst_h264_parse_get_sps:<VideoH264Parse> [00m Creating
>> sps with sps_id=0000
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977398089 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:1776:gst_h264_parse_chain_forward:<VideoH264Parse> [00m
>> first MB: 0, slice type: 5
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977425532 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:1784:gst_h264_parse_chain_forward:<VideoH264Parse> [00m we
>> have a P slice
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977446500 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:2312:gst_h264_parse_chain:<VideoH264Parse> [00m received
>> buffer of size 4048
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977491182 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:1757:gst_h264_parse_chain_forward:<VideoH264Parse> [00m NAL
>> type: 1, ref_idc: 2
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977518350 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:1776:gst_h264_parse_chain_forward:<VideoH264Parse> [00m
>> first MB: 0, slice type: 5
>> Mar  5 16:14:23 imsvcctl[463]: 0:00:14.977531861 [332m  463 [00m
>> 0xf6207568 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:1784:gst_h264_parse_chain_forward:<VideoH264Parse> [00m we
>> have a P slice
>>
>> Thank you for any comments or help.
>>
>> Chuck Crisler
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email] <http://user/SendEmail.jtp?type=node&node=4658903&i=0>
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://gstreamer-devel.966125.n4.nabble.com/problems-generating-an-H264-stream-tp4658903.html
>>  To start a new topic under GStreamer-devel, email [hidden email]<http://user/SendEmail.jtp?type=node&node=4658908&i=0>
>> To unsubscribe from GStreamer-devel, click here.
>> NAML<http://gstreamer-devel.966125.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>> "What parameter(s) do I specify to get those?" FU-A fragmentation
>> headers included, *NOT* setting the MARK bit on every packet and also not
>> getting 'NAL unit - Access Unit Delimiter' packets.
>>  parameters for what? And what is "those"? Do you want each NALU with a
>> specific Fragmentation Unit? I realized some problems with the slices on
>> multi-processor machines; a workaround is to use threads=1 for the x264enc.
>> Is it not possible for you to test the things with a test source or a
>> fakesink instead of directly trans-coding it? Maybe, though it is a very
>> convoluted pipeline. I realized last night that the problem *MAY* be in the
>> intermediate MP2T stream, which is encrypted (makes it kinds hard to look
>> at it in wireshark).
>>
>>
>> ------------------------------
>> View this message in context: Re: problems generating an H264 stream<http://gstreamer-devel.966125.n4.nabble.com/problems-generating-an-H264-stream-tp4658903p4658908.html>
>> Sent from the GStreamer-devel mailing list archive<http://gstreamer-devel.966125.n4.nabble.com/>at Nabble.com.
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130306/c60597e6/attachment.html>

More information about the gstreamer-devel mailing list