[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