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.<br>
<br><div class="gmail_quote">On Wed, Mar 6, 2013 at 9:47 AM, Chuck Crisler <span dir="ltr"><<a href="mailto:ccrisler@mutualink.net" target="_blank">ccrisler@mutualink.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5">On Tue, Mar 5, 2013 at 6:27 PM, pfarmer <span dir="ltr"><<a href="mailto:flacone@gmx.de" target="_blank">flacone@gmx.de</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<div><div>
  
    
  
  
    <div>On 03/05/2013 10:45 PM, Chuck Crisler-2
      [via GStreamer-devel] wrote:<br>
    </div>
    </div></div><blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite"><div><div> 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?<br>
      <br>
      My pipeline is like this: udpsrc -> mpegtsdemux -> h264parse
      -> ffdec_h264 -> x264enc -> rtph264pay -> udpsink<br>
      <br>
      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.<br>
      <br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      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<br>
      <br>
      Thank you for any comments or help.<br>
      <br>
      Chuck Crisler<br>
      <br>
      <br></div></div>
      _______________________________________________
      <br>
      gstreamer-devel mailing list
      <br>
      <a href="http://user/SendEmail.jtp?type=node&node=4658903&i=0" rel="nofollow" link="external" target="_blank">[hidden email]</a>
      <br>
      <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="nofollow" link="external" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
      <br>
      <br>
      <hr color="#cccccc" noshade size="1">
      <div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif">
        <div style="font-weight:bold">If you reply to this email, your
          message will be added to the discussion below:</div>
        <a href="http://gstreamer-devel.966125.n4.nabble.com/problems-generating-an-H264-stream-tp4658903.html" rel="nofollow" link="external" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/problems-generating-an-H264-stream-tp4658903.html</a>
      </div>
      <div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">
        To start a new topic under GStreamer-devel, email
        <a href="http://user/SendEmail.jtp?type=node&node=4658908&i=0" rel="nofollow" link="external" target="_blank">[hidden email]</a> <br>
        To unsubscribe from GStreamer-devel, <a rel="nofollow" link="external">click
          here</a>.<br>
        <a href="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" rel="nofollow" style="font:9px serif" link="external" target="_blank">NAML</a> </div>


    </blockquote></div></div><div>
    "What parameter(s) do I specify to get those?" <font color="#ff0000">FU-A fragmentation headers included, *NOT* setting the MARK bit on every packet and also not getting 'NAL unit - Access Unit Delimiter' packets.</font><br>

</div>
    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? <font color="#ff0000">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).</font><div class="im">
<br>

  



        
        
        
<br><hr width="300" align="left">
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/problems-generating-an-H264-stream-tp4658903p4658908.html" target="_blank">Re: problems generating an H264 stream</a><br>
Sent from the <a href="http://gstreamer-devel.966125.n4.nabble.com/" target="_blank">GStreamer-devel mailing list archive</a> at Nabble.com.<br><br></div>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br>