After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 590860 - [mpegtsparse] Incorrect scrambling info processing
[mpegtsparse] Incorrect scrambling info processing
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.13
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-05 14:41 UTC by Ivan
Modified: 2010-02-09 10:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the patch (859 bytes, patch)
2009-08-05 15:17 UTC, Ivan
none Details | Review

Description Ivan 2009-08-05 14:41:57 UTC
Please describe the problem:
The mpegtsparse plug-in determines scrambling control incorrectly. The attached patch resolved the problem in my case

As I understood the problem is that the code
tmp = GST_READ_UINT16_BE (data); 
changes the byte order and scrambling control is read from data[1] instead of data[0]



Steps to reproduce:
In my case a have a scan utility based on mpegtsparse plugin and I compare its result with result with scan utility from dvb-apps package (http://ftp.osuosl.org/pub/nslu2/sources/DVB-20050311.tar.gz)


Actual results:


Expected results:


Does this happen every time?
sometimes

Other information:
less scrambling.patch 
*** distr/gst-plugins-bad-0.10.13/gst/mpegdemux/mpegtspacketizer.c      2009-05-12 01:18:14.000000000 +0400
--- distr/gst-plugins-bad-0.10.13/gst/mpegdemux/mpegtspacketizer_fix.c  2009-08-05 18:14:01.000000000 +0400
***************
*** 1273,1279 ****
      EIT_schedule = (tmp >> 15);
      EIT_present_following = (tmp >> 14) & 0x01;
      running_status = (tmp >> 5) & 0x03;
!     scrambled = (tmp >> 4) & 0x01;
      descriptors_loop_length = tmp & 0x0FFF;
  
      /* TODO send tag event down relevant pad for channel name and provider */
--- 1273,1279 ----
      EIT_schedule = (tmp >> 15);
      EIT_present_following = (tmp >> 14) & 0x01;
      running_status = (tmp >> 5) & 0x03;
!     scrambled = (entry_begin[3] >> 4) & 0x01;
      descriptors_loop_length = tmp & 0x0FFF;
  
      /* TODO send tag event down relevant pad for channel name and provider */
scrambling.patch (END)
Comment 1 Ivan 2009-08-05 15:17:24 UTC
Created attachment 139951 [details] [review]
the patch

The patch fixes the problem on my side
Comment 2 Ivan 2009-08-05 15:54:08 UTC
The following code
scrambled = (tmp >> 12) & 0x01; 
has to determine the scrambling correctly too.

The problem is that the code was written in assumption that tmp is single byte variable but it keeps 2 bytes. And with 4 bits shift we will not have 4 bits but 12 and some of the bits will have descriptors_loop_length info.

BTW: The descriptors_loop_length is determined correctly as 
descriptors_loop_length = tmp & 0x0FFF;
Comment 3 Ivan 2009-08-05 19:27:01 UTC
Some additional info about the SDT format can be gotten from this doc http://actamont.tuke.sk/pdf/2008/n1/23dalmi.pdf
Comment 4 Sebastian Pölsterl 2009-10-09 17:39:14 UTC
This bug is already fixed.