[gstreamer-bugs] [Bug 599585] New: gstrtph263pay does not allow H263 Mode B

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=599585
  GStreamer | gst-plugins-good | 0.10.16

           Summary: gstrtph263pay does not allow H263 Mode B
    Classification: Desktop
           Product: GStreamer
           Version: 0.10.16
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: leon.72 at hotmail.de
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


I use as streaming queue something like the following:

   ... ! ffenc_h263 ! rtph263enc ! ...

The following code inside gstrtph263pay.c is wrong:

##############################<begin code>##################################
(line 1711)
    for (i = 0; i < format_props[context->piclayer->ptype_srcformat][0]; i++) {
      GST_DEBUG ("Searching for gob %d", i);
      bound = gst_rtp_h263_pay_gobfinder (rtph263pay, bound);
      if (!bound) {
        GST_WARNING
            ("No GOB's were found in data stream! Please enable RTP mode in
encoder. Forcing mode A for now.");
        ret = gst_rtp_h263_send_entire_frame (rtph263pay, context);
        goto end;
      }
##############################<end code>###################################

It checks the picture for the GOBs contained. Even if it already found a bunch
of GOBs (e.g. "i" is 10 or even higher) and it does not find another GOB, its
says that "NO" GOB is found and sends the entire frame in "Mode A".

When I set

  export GST_DEBUG=rtph263pay:5

This wrong behaviour can seen very good. Due to that programming error it never
sends a "Mode B" package. which is very bad, because the "Mode A" packages get
fragmented, because they have (at my computer) a size of 16 Kilobyte or more,
but the MTU is only about 1.4 kilobyte.

I tried to fix the above if clause to the following:

   if (i==0 && !bound) {

then indeed real "Mode B" packages get send, but the program then aborts at the
following place:

##############################<begin code>##################################
(line 1030)
    //Step 3 decode CBPY I
    cbpy_type_index = gst_rtp_h263_pay_decode_cbpy (context->window, cbpy_I);

    GST_DEBUG ("CBPY index: %d", cbpy_type_index);
    if (cbpy_type_index == -1) {
      GST_ERROR ("CBPY index shouldn't be -1 in window: %08x",
context->window);
      return NULL;
    }
##############################<end code>###################################

It tries to decode a "0x0180" but in the cbpy_I table is no such code.

While looking for a reason of that I found something other strange:

##############################<begin code>#################################
(line 1206)
      //check if the block has TCOEF
      if (i > 3) {
        ind = mcbpc_P[mb_type_index][i - 1];
      } else {
        if (mcbpc_P[mb_type_index][5] > 2) {
          ind = cbpy_I[cbpy_type_index][i + 3];
        } else {
          ind = cbpy_P[cbpy_type_index][i + 3];
        }
      }
#############################<end code>####################################

It uses the table cbpy_I (the suffix _I means that it is for I-Frames), but it
is a in the else part relevant for only P-Frames.

-- 
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.