h264parse bug?: Files unplayable in flash because P Slices before I Slice

[Mike Mitchell]

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.


*Mike Mitchell*




On Tue, Oct 4, 2011 at 2:26 PM, Mike Mitchell
<mike.mitchell at panometric.net>wrote:

> Videos I record from an IP camera with h264 using rtp to mp4mux
> are slightly corrupted:
> 1. On flash players like jwplayer or flowplayer, they play but with no
> video.
> 2. On native players like vlc, mplayer,  They play but do start poorly with
> a gray screen until the first Iframe comes through.
>
> 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.
>
> 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.
>
> Can anyone suggest a gstreamer element that could do drop P Slices until
> the first I Slice?
>
> Or do I need to code this myself.... If I were going to add this
> functionality, is h264parse the correct place to do it?
>
>
> *Mike Mitchell*
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20111007/a046ce9d/attachment.htm>