MPEG-2 Sections and Tables Byte Order

by admin 2. July 2006 07:33

I've slowly been continuing development on my BDA library (see Introduction To Scanning DVB-T Digital TV). Recently I've been working on getting program guide data from the Event Information Table (EIT). In directshow all of these MPEG-2 data tables are provided through the IMpeg2Data interface of the MPEG-2 Sections and Tables filter.

There's 3 methods that provide data GetTable, GetSections and GetStreamOfSections. Originally I was using GetTable and all was working fine, though I did notice I was getting some strange data through which I assumed was just part of the actual broadcasted data. I wanted to move over to using GetStreamOfSections as it provides a more asynchronous approach.

After some playing I got GetStreamOfSections working in .NET and suddenly discovered that the quality of my data suddenly improved. That strange data that I'd assumed was in the broadcast disappeared. This was excellent! Unfortunately I soon discovered that GetStreamOfSections seemed to break when the graph was retuned to a new frequency. I'll try to blog soon about that issue and what I did about it. For the moment all you need to know is that I ended up returning to the synchronous methods.

When I returned to using GetSection (I still don't really know the difference between GetTable and GetSection as they seem to return very similar data) I decided I would try to get to the bottom of the strange data issue. After stepping through the methods that parsed the MPEG-2 tables I discovered the length field being read from the data was significantly more than the length of data actually read. This explained the strange data - I was reading past the end of the data - but why was this wrong when it had been correct in the GetStreamOfSections case? A quick glance at the two values quickly showed that the byte order of the field read was incorrect!

Bingo! This would fix all my problems in one swoop.

But unfortunately further investigation discovered that it actually depended on which table I was reading as to whether the field was in the correct order or not! And furthermore sometimes the field and the data length supplied to me had no relation at all.

So unfortunately, that is where I'm at. I have guide data reading correctly. I have channel scanning working. But the data is still not reading 100% unless I use GetStreamOfSections which has its own issues (see non-existant future blog post for details). If anybody has any idea why this would be I'd love to hear it.

Comments are closed

About Us

RikWare is a software development company based in Brisbane, Australia. Led by director, Richard Mason, RikWare focusses on solving challenging business problems promptly and effectively.

RikWare is also the owner of Aussie Bushwalking, a free, wiki-like collaboration site for bushwalkers and the creator of RikMigrations, a migration framework for .NET.

Aussie Bushwalking

Want to discover some new bushwalking ideas? Share a few of your own? Aussie Bushwalking is like Wikipedia... but for bushwalkers. Head on over. Anybody can see the walks and it's free to sign up and share your own.



RikMigrations is a database migration library for .NET based on the migrations facility provided by Ruby on Rails. It allows simple upgrading and downgrading of databases using .NET code (such as VB or C#) either from the command line or built into your application. Unlike many other migration frameworks, RikMigrations is a stand-alone library which does not rely on a large surrounding framework.