[kalvis]

Nikerdan vaikselt TS videofailide kallal, et saaks tulevikus MPEG streamis seda otse lõigata. Paraku on TS stream big endianis, intel aga on little endianis. Kas C-s saab kuidagi mälu salvestamist ka sundida, et kasutaks Big Endiani?. Kuigi praegu asi toimib, et kasutan muutujatel _H ja _L ning nende poole pöördumisel swapin baidid ringi on see ikkagi üsna mitte ilus lugemine. Ja kui tahaks koodi kasutad Big Endian prosel, tuleb kood jälle ringi teha.
Teine imelik lisanäht oli ka bittide lugemisel - millegipärast bitiväljadele tehakse kah little endiani, nooremat bitti tuleb lugeda struktuuris just vanemast kohast, samas kui terve bait on õige.
N: header on sync, flags1:3,PID:13,flags2:4,CC:4 kokku 4 baiti, lugeda BIG Endianis
struct TS_header {uint8_t sync, PID_H:5,flags1:3,PID_L,CC:4,flags2:4;}; uint16_t PID=PID_L+256*PID_H; ja nii sai bitid õieti kätte (igaks juhuks sai lisatud atrribuut packed).

Momendil kõik kompileeritud Mingw -s. Eesmärk oleks BIg endianis struktuuri kasutada, kuid tundub, et vist ei saa?

[troglodyte]

Endianness-i saab C-s kindlaks teha ja sellepõhjal otsustada koodis kustpoolt baite lugema tuleb hakata, google ütleb kuidas.

[kalvis]

http://mjfrazer.org/mjfrazer/bitfields/ leidsin ülevaate. Nati sain asja paremaks, st pääsesin koodis lühemate teisendustega (pole vaja enam baidikaupa kokku liita andmeid). Kui defineerisin struktuuri:
typedef struct {
int CC:4,f_AFC:2,f_TSC:2;
int PID:13;
int f_TEI:1,f_PUSI:1,f_TP:1;
int sync:8;
} ts_header_t __attribute__ ((packed));
siis enne aadressi tegin header=__builtin_bswap32(header); ja keerukat viitadega mängimist (bswap tahab uint32_t tüüpi, mitte struktuuri), siis on intel prosel masinal kõik ühe matsuga õiged.
Ainult see võttis mõistuse, kui int välja asemel püüdsin struktuuris kasutada alguses uint8_t ja uint16_t siis oli struktuur kohe metsas ja luges bitivälja kohe valesti. Pidi olema mingi kompilaatorite erisoov.