Turns out leading P frames were not the only problem with my stream. But I would still like an architect's opinion, shouldn't h264parse ensure the stream is spec compliant? I've read the source and see there is some logic to detect the I frame, but it does not appear to trash the P frames until the I frames start like I would expect. <div> <br></div><div><br clear="all"><b>Mike Mitchell</b><br><br><br> <br><br><div class="gmail_quote">On Tue, Oct 4, 2011 at 2:26 PM, Mike Mitchell <span dir="ltr"><<a href="mailto:mike.mitchell@panometric.net">mike.mitchell@panometric.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div>Videos I record from an IP camera with h264 using rtp to mp4mux are slightly corrupted:</div><div>1. On flash players like jwplayer or flowplayer, they play but with no video. </div><div>2. On native players like vlc, mplayer, They play but do start poorly with a gray screen until the first Iframe comes through. </div> <div><br></div><div>My best clue is that VLC, ffmpeg and tcprobe all report: "Missing reference picture decode_slice_header error". This seems to be related to the fact that the h264 stream contains several P Slices before it contains the first I slice. Some players just ignore this, but to flash it seems to ruin the whole stream.</div> <div><br></div><div>Since I'm forced to accept flash for compatibility reasons, and really want to avoid transcoding everything, I'd like to fix the file by cleaning up these useless P Slices at the front of the stream. </div> <div><br></div><div>Can anyone suggest a gstreamer element that could do drop P Slices until the first I Slice? </div><div><br></div><div>Or do I need to code this myself.... If I were going to add this functionality, is h264parse the correct place to do it?</div> <div><br></div><font color="#888888"><br clear="all"><b>Mike Mitchell</b><br><br><br><br> </font></blockquote></div><br></div>