[gstreamer-bugs] [Bug 440389] [API 0.11] Add GST_LEVEL_FIXME

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=440389

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #2 from Benjamin Otte (Company)  2007-05-23 08:11 UTC -------
(In reply to comment #1)
> If a decoder properly handles a broken file, I don't think it should be
> spitting out GST_ERROR()s.  It can either do a GST_ELEMENT_ERROR() and bail
> out, or fix up the output and send a discontinuity.  It should probably also
> send a message indicating that the stream is broken.
> 
I'll construct an example. Because it works so well for these kinds of issues,
I'll use ID3v2, see http://www.id3.org/id3v2.4.0-structure for the standard.
And I'll mostly use the nice method of unsynchronization (see chapter 6).

Let's assume the following cases in a decoder:
- The header sets the unsync flag, but the ID3 tag contains a frame without the
sync flag set.
- A frame has the unsync flag set, but encounters 2 consecutive bytes with data
0xFF.
- For whatever reason, you didn't implement unsync yet but encounter a frame
that has the unsync flag set.
- The current frame is encrypted. The encoding specified (see
http://www.id3.org/id3v2.4.0-frames 4.25) however is not implemented by your
demuxer.
- You encounter a frame that isn't matched with a corresponding GStreamer tag.
What would you suggest to do in each of them?

> As for GST_FIXME, I think the label "FIXME" is independent of the severity of
> the issue, so it shouldn't be a specific severity.  For example, the message
> "This code is not yet complete and could cause segfaults" would be a GST_ERROR,
> but "Somebody should spend a week sometime and fix this corner case that is
> really mostly correct right now anyway" is not.
>
The first would be a bug. No code should ever crash, no matter if it's complete
or correct.
The point is that you want to hint at the developer what to do if a user files
a bug because a user's file doesn't play back. If there's a /* FIXME: What to
do if this flag is set? */ in the code somewhere, you'll probably never figure
out the problem unless you step through the code with gdb. If the debug log
contains a "FIXME: foo_bar_decode (245): What to do if this flag is set?" it'll
be very easy to figure out what the problem is.

> Also, having a FIXME is a natural occurrence in code.  I wouldn't want to spew
> crap to the terminal all the time.
> 
It's not for every FIXME. It's for issues that you want to be notified about
when they occur in the wild. Things such as /* FIXME: ugly */ or /* FIXME: slow
*/ can stay comments.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=440389.