[gstreamer-bugs] [Bug 606662] h264: add stream-format to output caps

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun Jan 17 12:07:09 PST 2010


https://bugzilla.gnome.org/show_bug.cgi?id=606662
  GStreamer | gst-plugins-ugly | git

--- Comment #19 from David Schleef <ds at schleef.org> 2010-01-17 20:07:08 UTC ---
(In reply to comment #18)
> (In reply to comment #17)
> > ffdec_h264 most definitely handles non-parsed bytestream h.264.
> 
> That's because ffdec_h264 is wrongly adding a parser (only on byte-stream
> mode), see gst_ffmpegdec_open().

"wrongly"?  Not in the current way of doing things.

> It is possible to generate a muxed clip that
> contains trimmed access-units, it would play fine on totem, but not ffplay
> (mplayer, vlc, and pretty much everything out there).

I don't know what this means.  If this means "totem plays broken files better
than ffplay", I'm ok with that.

> This is precisely the reason why rtph264dec+ffdec_h264 only works on bytestream
> mode:

Actually, I think it only works in bytestream mode because H.264 over RTP is
only specified in bytestream mode.  Unless there's an RFC after 3984 that I
don't know about.  It seems unlikely, though, since AVC format is fundamentally
incapable of resynchronization after dropping packets.

> /* FIXME, non-bytestream handling is freaking out ffmpeg. Apparently we need to
>  * group all NAL units belonging to one frame together */

Of course.  That is how AVC format is defined.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list