Jump to content

Technische Frage bezueglich EIT tables


Mr. Pommeroy

Recommended Posts

Ich bin neu im Forum und generell neu auf dem Gebiet DVB, also erstmal Hallo allerseits!

 

Meine Diplomarbeit beschaeftigt sich mit dem Extrahieren von Informationen aus DVB Datenstroemen und nun bin ich dabei ein Programm zur Infromationsextraktion zu schreiben.

 

Besonders interessant scheinen die EIT tables zu sein und ich bin auch schon in der Lage die Informationen einer EIT Table zu extrahieren. Ich weiss, dass die Infos zu einem Event in Sections eingeteilt sind und diese auf mehrere Stream packets verteilt sein koennen. Nur weiss ich nicht, wie ich die Fortsetzung zu einer EIT finden kann, also z.B. habe ich eine EIT mit einem short_event_descriptor und einem extended_event_descriptor darin. Da das Packet ja nur 188 Bytes gross ist, endet die extended Description mittendrin. Wo finde ich nun den Anschluss zu dem Text? Im folgenden Packet steht es nicht und das naechste EIT-Packet enthaelt ganz andere Informationen.

 

Waere fuer Hilfe sehr dankbar!

Link to comment

Danke schonmal fuer den Link, den kannte ich noch nicht.

 

Die Infos auf der Page sind sehr hilfreich! Leider habe ich den DVBViewer nicht und muss mit einem Hex-Editor vorlieb nehmen. Trotzdem bin ich schonmal einen Schritt weiter. Danke!!

Edited by Mr. Pommeroy
Link to comment
Nur weiss ich nicht, wie ich die Fortsetzung zu einer EIT finden kann, also z.B. habe ich eine EIT mit einem short_event_descriptor und einem extended_event_descriptor darin. Da das Packet ja nur 188 Bytes gross ist, endet die extended Description mittendrin. Wo finde ich nun den Anschluss zu dem Text? Im folgenden Packet steht es nicht und das naechste EIT-Packet enthaelt ganz andere Informationen.

Es kann mehr als einen extended descriptor in einem event (eine untermenge einer section) geben.

Fortlaufender text in einem extended descriptor darf niemals die section grenze überschreiten.

So kann man einfach über alle extended descriptoren eines events loopen (sie liegen immer in der richtigen reihenfolge vor, wenn die section korrekt geparst wurde) und die extended description zusammensetzen.

Link to comment

so ich muss das jetzt etwas präzisieren. es kann mehr als einen extended und auch mehrere short eventdescriptoren geben. Die short event descriptoren sind in sich abgeschlossen und es kann pro sprache nur einen geben.

 

Die extended event descriptoren sind nicht zwangsläufig in sich abgeschlossen und es können auch mehrere sprachvarianten auftreten, die man dann entsprechend zuordnen muss.

 

Ein event darf die sectionsgrenze nicht überschreiten.

Link to comment

Ich versuche gerade das Problem zu loesen Informationen zu einem Event eindeutig zuzuordnen. Ich war davon ausgegangen, dass die Event Id eindeutig waere, aber die kann ja mehrmals vorkommen.

 

Ist es also richtig, dass die Event Id je Service Id eindeutig ist? Oder muss zusaetzlich auch die TransportStreamId uebereinstimmen?

Link to comment

Die EventID ist mit sicherheit eindeutig für

 

Table ID + Service ID + Transportstream ID + Org. Network ID + Versionsnummer der Section

 

Laut ETSI soll die ja per Service ID eindeutig sein, aber darauf würde ich nicht soviel geben. :bye:

 

Kabel austria zum beispiel geizt extrem mit eventIDs mit jeder neuen version der section werden alte events durch neue (unterschiedliche!) mit gleicher EventID überschrieben.

Link to comment

Okay, ich kann nun einen Event eindeutig zuordnen.

 

Ich habe aber immernoch das Problem, dass ich die Fortsetzung zu einer extended_event_description nicht finde. Ich bekomme den ersten Teil, der aufgrund der Packetgroesse von 188 Bytes mitten im Satz abgeschnitten ist. Ich kann den Rest aber nicht finden. Es muesste doch in einem weiteren Packet der Text von dieser Stelle an fortgesetzt werden, oder?

 

Das Bild zeigt was ich bisher habe...

Edited by Mr. Pommeroy
Link to comment

Klammer dich nicht an 188 byte pakete. Eine EIT section kann bis zu 4096 byte gross sein, das sind einige 188 byte pakete.

Die Pakete (bzw. deren payload) sollten solange zwischengebuffert werden, bis du die sectionlength erreicht hast, dann erst die section interpretieren, so findest Du auch alle descriptoren, die die 188 byte u.U. überschreiten.

188 byte pakete einzeln zu durchkramen ist nicht ratsam.

post-5310-1190386970_thumb.jpg

Link to comment

Hmm, da muss ich meinen kompletten Programmaufbau vorerst ueber den Haufen schmeissen... ich dachte gesendete Packete waeren immer 188 Bytes gross.

 

Das heisst ich sammle Byte fuer Byte und entscheide dann aufgrund der Tabellenart und der Sectionlaenge wie lang das Packet tatsaechlich ist?

Link to comment

Die pakete sind immer 188 byte gross, aber die payload ist kleiner und kann varieren. Ausserdem kann es zu fehlenden paketen (discontinuities) kommen. Sowas ist bei einer per paket betrachtung unangenehm.

 

Wenn man die jeweilige payload in einen buffer schiebt, kann man schnell bei fehlern den buffer verwerfen und neu anfangen... Und sobald die datenlänge im buffer grösser oder gleich der section_length ist, verarbeitet man eine section in einem rutsch.

 

Das ganze ist natürlich etwas vereinfacht dargestellt. :rolleyes:

Link to comment

Stell Dir DVB wie ein Netzwerk protokoll vor (vom prinzip ist es ja sowas in der art).

 

Es gibt eine feste paket grösse mit header und fehlerkorrektur usw und einen datenteil. Die ganzen höheren DVB-Strukturen (Tables) werden in den datenteil geschrieben. Sie können im idealfall in ein paket passen, aber meistens werden daraus mehrere pakete, die der empfänger wieder richtig zusammen setzen muss.

Link to comment

Ich baue mir nun also eine Section zusammen und immer wenn wieder ein Packet kommt, das zu der Section gehoert, packe ich es dazu.

Nun hab ich mal ein komplettes ts-File in den Hex-Editor geladen, um das besagte Endstueck zu finden. Dabei werde ich immer noch nicht schlau, wie ich das dann zu der angefangenen Section zuordnen kann, zumal der Header nun nur noch aus SYN-Byte, Flags+PID und einem weiteren Byte besteht (s.Bild).

 

EDIT: kann ich etwa davon ausgehen, dass das naechste empfangene EIT-Packet nahtlos an das letzte fortsetzt, also zur gleichen Section gehoeren muss?

Edited by Mr. Pommeroy
Link to comment
Solange continuity counter stimmt und kein transport error flag gesetzt ist ja. Denk daran nur die payload zu verwenden und nicht das ganze paket.

 

Super, dann mach ich mich mal ans umstricken. Danke!

Link to comment

Falls Du Beispielcode suchst, kannst Du Dir ja auch mal mein DVB.NET anschauen, da gibt es einen Teil, der sich nur mit der Analyse von SI Tabellen und allen voran dem EPG auseinander setzt.

 

Jochen

 

<Zusatz>Ups, vergessen: zum Umpaketieren von TS in SI Tabellen gibt es auch was in einem anderen Bereich von DVB.NET.</Zusatz>

 

<Zusatz>Noch einer: der EPG Reader ist ein Tool in DVB.NET, das unter anderem eine TS Datei liest und das EPG extrahiert. Da kann man sehr schön sehen, wie die einzelnen Klassen zusammenspielen, um die Events zu liefern.</Zusatz>

Edited by JMS
Link to comment
Solange continuity counter stimmt und kein transport error flag gesetzt ist ja. Denk daran nur die payload zu verwenden und nicht das ganze paket.

 

Erstmal danke fuer die Antworten, hat mir wirklich weitergeholfen!

 

Ich habe mein Proggy nun umgebaut. Es wird die Section gebuffert, bis die Section length erreicht ist. Dann wird die Section geparst.

Das funktioniert auch weitestgehend. Nur ist es jetzt so, dass wenn ich jede Section im Buffer verwerfe, falls der ContinuityCounter nicht stimmt (das heisst er ist nicht um 1 hoeher als beim letzten Packet mit der PID 18), ich nicht mehr viele Events einfange. Anscheinend gehen bei der Uebertragung recht viele Packete verloren, denn wenn ich mir den Continuity Counter der EIT-Packete anzeigen lasse, so sieht das etwa so aus:

 

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 5 7 9 10 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 4 6 7 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 15

0 2 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 11 12 13 14 15

0 1 2 3 4 5 6 7 8 10 11 12 13 14 15

0 1 3 5 6 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 14 15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

 

Gibt es da einen Weg die Informationen dennoch zu erhalten, oder kann man da nichts machen? Gerade extended_event_informationen gehen mir so leider oftmals floeten.

 

EDIT:

Bei den NIT-Sections habe ich noch ein groesseres Problem mit dem Continuity Counter. Hier bekomme ich gar keine komplette Section zusammen. Der Continuity Counter sieht bei den NIT-Packeten so aus:

 

8 11 4 10 6 15

5 1 10 0 9 12 5 11 4 7 6 15

2 8 10 13 3 6 12 15

5 1 7 10 0 3 9 2 11 14 7 13 0 6 9 2 8 11 1 4 10 13 3 12 15

5 1 10 0 12 5 11 14 4 7 13 0 2 8 11 4 10 13 3 6 15

5 8 1 7 10 0 9 12 5 11 7 13 0 6 9 8 11 1 4 10 3 6 5

 

Gibt es da einen Weg trotzdem Informationen extrahieren zu koennen?

 

Anbei noch ein Screenshot wie mein Proggy bisher aussieht.

Edited by Mr. Pommeroy
Link to comment

Es funktioniert nun. Habe einige Bugs in meinem Programm behoben und bin nun in der Lage die Events richtig zu erfassen.

 

VIELEN DANK FUER EURE HILFE!

 

Eine Frage bleibt mir vorerst noch: muss eine Section immer mit dem Continuity counter 0 starten?

Link to comment

Interesant :jawdrop:

 

Kann man das testen ?

Ich suche noch so ein Tool, was nacheinander alle Transponder analysiert, und die Daten in eine .csv Datei speichert.

Dafür würde ich auch was bezahlen.

Link to comment
Ich suche noch so ein Tool, was nacheinander alle Transponder analysiert, und die Daten in eine .csv Datei speichert.

Dafür würde ich auch was bezahlen.

 

Mein Programm wird die Transponder der Reihe nach abscannen und die Ergebnisse in einer Datenbank ablegen.

Leider liegen die Rechte daran bei dem Unternehmen, bei dem ich meine Diplomarbeit schreibe. Daher kann ich weder Quellcode noch das ausfuehrbare Programm freigeben. Aber soweit ich weiss gibt es auch OpenSource Programme die das koennen. Ich habe mal was von tv_grab_dvb gehoert.

Link to comment

Schade, das Programm hörte sich so interessant an.

 

Der Tip tv_grab_dvb hilft mir leider nicht weiter, da es nur EPG Daten ausließt.

A Linux program to dump DVB EPG info in xmltv format..

Und von Linux hab ich kein Plan :unsure:

 

Ich suche noch ein Tool, was ist zusätzlich zu den Super Tool Transedit nutzen kann.

Was genau so gestartet wird, und dann nacheinander die Transponder scannt, und die CAID und eventuell noch weitere Daten in eine .csv Datei speichert.

 

Leider hab ich bis heute nix gefunden.

Wenn ich sowas programmieren könnte, hätte ich es schon längst gemacht.

Aber ich kenn mich nur mit php/html aus :blink:

Link to comment

Ich bin nun mit meinem Programm an den Service Description Tables (SDT) und brauche erneut Hilfe.

Und zwar habe ich in einer Section zuerst einen Service-Descriptor. Doch danach sind einige Bytes, die ich nicht deuten kann und die mein Programm nicht zu verarbeiten weiss.

Der Hex Code sieht folgendermassen aus: siehe Bild.

 

Das Problem ist also die Stelle mit den blauen ????? nach dem 1. Service Descriptor. Wenn ich die als privaten Descriptor mit hex Value 0x02 deute, dann waere die Laenge ja das folgende Byte (0xBD). was aber nicht stimmt. Wie deute ich diese Bytes also?

 

EDIT: Habe den Fehler soeben gefunden. Es handelt sich um die Service-ID des naechsten Eintrags.

Edited by Mr. Pommeroy
Link to comment
  • 2 weeks later...

Mein Proggy gedeiht inzwischen ganz gut. Bin nun auch in der Lage BAT, SDT, NIT, PAT und PMT tables zu parsen.

Nun wuerde ich gerne einen CRC check einbauen, weiss jedoch nicht, welche bytes ich dafuer zu Rate ziehen muss. Ich weiss, dass die letzten 4 byte der Payload die Checksumme sind, aber wovon? Von der Section oder wird das vorige Packet auch noch miteinbezogen?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...