Da schaut man hier mal für ein paar Tage nicht vorbei um ein anderes Problem anzugehen und schon ist es gelöst...... Ich verweise AVM jetzt noch ein letztes mal auf diesen Thread, dann sollen die zusehen was die machen, mir egal.
Du hast nicht zufällig mal versucht einen 5. Stream zu öffnen (also ohne den cableinfo), oder?
Um meinen minisatip entsprechend kompilieren zu können, muss ich natürlich den Aufbau eines streams verstehen:
Ich hoffe ja das da schon Informationen drüber existieren was die einzelnen Parameter bei di_alloc_stream_param bedeuten. Oder das zumindest irgendwer eine Idee hat was das sein könnte.
Bei tune_stream müsste das zweite Parameter die Frequenz sein (als Dezimalzahl wäre sie auch lesbar). AVM Schreibt dazu
mtype gibt warscheinlich die Art der Modulation an (QAM256, QAM64 etc.), aber was inv und sr sein sollen ist mir noch nicht ganz klar. Das ist natürlich essentiell um zu den cableinfo komplett zu ersetzen, gegen einen schönen multithreaded minisatip der im idealfall so viele streams liefert wie der Prozessor schafft.
Allerdings befürchte ich, das PeterPawn recht hatte: di_alloc_stream beinhaltet die folgenden Zeilen:
Stark vereinfacht wird der nächste freie demuxer gesucht. Die maximale Anzahl an Demuxern ist in dword_5C64 gespeichert, was im init durch folgenden Code passiert:
Da wirds dann mit meinen Reverse Engineering Künsten leider auch schon eng, denn wo genau diese Zahl eigentlich herkommt sehe ich da leider nicht, aber vielleicht hat da jemand anders ja mehr Glück/Erfahrung.
Das es die Tuner-Anzahl ist bezweifel ich spätestens seit ich
gesehen hab nicht mehr.
Kleiner Edit: SR ist selbstverständlich die Symbolrate.....Invb müsste specinv aus den Parametern sein, also Spectral Inversion. Dann bleiben noch die ganzen Parameter von di_alloc_stream_param die analysiert werden müssen.
Noch ein Edit: Kann der Segfault beim schließen eines Streams eventuell davon kommen, das di_close_stream nur ein Argument erwartet? IDA zeigt es mir als int __cdecl di_close_stream(_DWORD *a1) an.
Du hast nicht zufällig mal versucht einen 5. Stream zu öffnen (also ohne den cableinfo), oder?
Um meinen minisatip entsprechend kompilieren zu können, muss ich natürlich den Aufbau eines streams verstehen:
Code:
di_alloc_stream_param(0 b728d028 0 c0a80039 1388 d01e 1 b75fe300 10 8065c61) -> b73c1948
di_alloc_stream(b73c1948) -> b728c000
di_close_stream(b728c000 bfbd9a98 80527bb) -> 0
di_tune_stream(b728c000 1f1d1680 694920 0 5 0 5 5) -> 0
di_open_stream(b728c000) -> 0
di_add_pid(b728c000 0) -> 0
di_add_pid(b728c000 10) -> 0
di_add_pid(b728c000 11) -> 0
di_add_pid(b728c000 12) -> 0
di_add_pid(b728c000 14) -> 0
di_add_pid(b728c000 13ec) -> 0
di_add_pid(b728c000 13ed) -> 0
di_add_pid(b728c000 492) -> 0
di_add_pid(b728c000 498) -> 0
di_add_pid(b728c000 87b) -> 0
di_add_pid(b728c000 13ee) -> 0
di_add_pid(b728c000 13ef) -> 0
di_add_pid(b728c000 13f0) -> 0
di_add_pid(b728c000 13f1) -> 0
di_add_pid(b728c000 13f2) -> 0
di_add_pid(b728c000 13f4) -> 0
di_add_pid(b728c000 1434) -> 0
p_di_recvpid_stream(b728c000 ..)
...
di_close_stream(b728c000 bfbd9a98 80527bb) -> 0Ich hoffe ja das da schon Informationen drüber existieren was die einzelnen Parameter bei di_alloc_stream_param bedeuten. Oder das zumindest irgendwer eine Idee hat was das sein könnte.
Bei tune_stream müsste das zweite Parameter die Frequenz sein (als Dezimalzahl wäre sie auch lesbar). AVM Schreibt dazu
Code:
debugmsg(
dword_5BC4,
"%s tuner:%d channel:%d f:%ld mtype:%d sr:%ld inv:%d",
"di_tune_stream",
a1[4],
a1[5],
a2,
a5,
a3,
a4);Allerdings befürchte ich, das PeterPawn recht hatte: di_alloc_stream beinhaltet die folgenden Zeilen:
Code:
debugmsg(dword_5BC4, "%s", "alloc_demux");
v1 = dword_5C64;
if ( dword_5C64 <= 0 )
goto LABEL_20;
v2 = 0;
while ( dword_5C20[v2] || dword_5C40[v2] < 0 )
{
++v2;
v1 = dword_5C64;
if ( v2 >= dword_5C64 )
goto LABEL_20;
}
v3 = slab_dcalloc(1, 412, (int)"dvbif.c", 496);
v4 = (_DWORD *)v3;
dword_5C20[v2] = v3;
if ( !v3 )
{
v1 = dword_5C64;
LABEL_20:
debugmsg(dword_5BC4, "alloc of demux_ts failed, max=%d", v1);
goto LABEL_18;
}
*(_DWORD *)(v3 + 44) = v2;
*(_DWORD *)(v3 + 52) = -1;
if ( dword_5C64 <= v2 )
{
debugmsg(dword_5BC4, "%s: invalid demux_index %d, max=%u", "MapDemuxToNim", v2, dword_5C64);
v4[12] = -1;
goto LABEL_17;
}Stark vereinfacht wird der nächste freie demuxer gesucht. Die maximale Anzahl an Demuxern ist in dword_5C64 gespeichert, was im init durch folgenden Code passiert:
Code:
v14 = LODWORD(v41);
dword_5C64 = 0;
dword_5C60 = LODWORD(v41);
v15 = 0;
v16 = 0;
do
{
if ( _bittest(&v14, v16) )
{
debugmsg(dword_5BC4, "map ch:%d to nim %d", v15, v16);
v17 = dword_5C64;
v14 = dword_5C60;
dword_5C40[dword_5C64] = v16;
v15 = v17 + 1;
dword_5C64 = v15;
}
++v16;
}
while ( v16 != 8 );
debugmsg(dword_5BC4, "channel_mask 0x%08x -> num %d", v14, v15);Da wirds dann mit meinen Reverse Engineering Künsten leider auch schon eng, denn wo genau diese Zahl eigentlich herkommt sehe ich da leider nicht, aber vielleicht hat da jemand anders ja mehr Glück/Erfahrung.
Das es die Tuner-Anzahl ist bezweifel ich spätestens seit ich
Code:
int di_get_number_of_tuners()
{
return dword_5C64;
}Kleiner Edit: SR ist selbstverständlich die Symbolrate.....Invb müsste specinv aus den Parametern sein, also Spectral Inversion. Dann bleiben noch die ganzen Parameter von di_alloc_stream_param die analysiert werden müssen.
Noch ein Edit: Kann der Segfault beim schließen eines Streams eventuell davon kommen, das di_close_stream nur ein Argument erwartet? IDA zeigt es mir als int __cdecl di_close_stream(_DWORD *a1) an.
Zuletzt bearbeitet:
