H.263 Stream analysieren?

[7.e.Q]

Hi Leute,

1. ist hier jemand, der sich mal 'nen H.263 Video Trace (Ethereal) anschauen kann? Ich seh nicht, was daran falsch ist... Ich weiß nur, daß ein SIP Client auf der Gegenseite das Video aus irgendeinem Grund nicht anzeigt.

2. Gibt es eine Möglichkeit, einen Stream zu analysieren, auf Daten-Fehler zu prüfen? Momentan kann ich nur sehen, ob das Video angezeigt wird oder nicht. Also nur "richtig" oder "falsch". Aber nicht den Grund, weshalb es nicht angezeigt wird. Gibt es Analyse-Tools, die mir den Grund sagen können?

Danke

Gruß,
Hendrik

[7.e.Q]

Hier mal die PCAP Datei (Ethereal) einer SIP Video Session. Kann mir mal bitte (!) jemand sagen, was da in den H.263 Paketen falsch ist? Ich kriege hier einen leichten Anfall von Tod, wenn ich das nicht bald hinbekomme... :ugly: :eek: :mad:

PCAP File, 194kb, SIP/H.263 Video Session (http://downloads.syncro-community.de/captured_sip_session.cap)

Das File ist jetzt nach SIP und H.263 Paketen gefiltert. Wenn noch andere Pakete zur Problem-Analyse benötigt werden, teilt es mir bitte mit!

Ich weiß nicht weiter. Für mein Verständnis sieht der Stream so okay aus...

[Teetrinker]

Ich kann dir auch nicht sagen was bei deinem Stream nicht stimmt. Ich müßte mich auch erst in die Materie einarbeiten. Dazu habe ich keine Lußt - ist ja auch nicht meine Aufgabe.

Ich kann dir nur empfehlen falls du es noch nicht gemacht hast diese beiden RFCs zu studieren:
http://tools.ietf.org/html/3261
http://tools.ietf.org/html/2327

Hoffe das hilft dir weiter.

[7.e.Q]

Immerhin mal 'ne Antwort. Aber mit SIP hat das anscheinend nicht viel zu tun. Die Session wird ja erfolgreich initiiert.

Ich habe hier einen Log Auszug aus dem SIP Client:



[Info]247379.183 CSuaAdaptiveJitterBuffer::StartIncomingStream() (123) 18128 0
[Info]247379.183 CSuaAdaptiveJitterBuffer::StartIncomingStream() (188) Initial buffer size is 2
[Info]247379.184 CSuaAdaptiveJitterBuffer::StartIncomingStream() (123) 18132 1
[Info]247379.184 CSuaAdaptiveJitterBuffer::StartIncomingStream() (188) Initial buffer size is 2
[Info]247379.727 CSuaVideoMixer::AddToBradyMixer() (579) Adding person to brady mixer 18132 18133
[Info]247379.731 CSuaVideoCodecManager::StartEncoder() (161) Starting video encoder (34) for stream 18133
[Info]247379.732 CSuaVideoCodecManager::StartDecoder() (255) Starting video decoder (34) for stream 18132
[Info]247384.245 CSuaAdaptiveJitterBuffer::OnTimer() (820) Resetting buffer due to fragments in buffer
[Info]247392.159 CSuaAdaptiveJitterBuffer::StopIncomingStream() (239) 18128 | Size: 2 | Delay: 20 | Var: 1 | Out of order: 0 | Packets: 232 | Lost: 0
[Info]247392.159 CSuaAdaptiveJitterBuffer::StopIncomingStream() (245) 18128 Total Timer Ticks: 646 | Timer Fire Accuracy : 20.0015
[Info]247392.159 CSuaAdaptiveJitterBuffer::StopIncomingStream() (245) 18132 Total Timer Ticks: 647 | Timer Fire Accuracy : 20.0015
[Info]247392.166 CSuaVideoCodecManager::StopDecoder() (312) Stopping video decoder for stream 18132
[Info]247392.173 CSuaVideoMixer::StopTransmitOutputStream() (1157) Stream: 18133
[Info]247392.173 CSuaVideoMixer::EnableTransmit() (1682) Stream: 18133 0
[Info]247392.180 CSuaVideoMixer::EnableTransmit() (1713) Transmitting mute frame for stream 18133
[Info]247392.189 CSuaVideoCodecManager::StopEncoder() (226) Stopping video encoder for stream 18133


Kann da jemand was zu sagen? Mir kommt das mit dem "Resetting Buffer..." irgendwie spanisch vor.

[7.e.Q]

Aha... also der Fehler war doch etwas trivialer, als angenommen. Aber man geht ja immer vom Schlimmsten aus.

Falsch war der Ziel-Port. Unsere Video-Daten sind auf dem Audio-Port des SIP Clients gelandet. Jetzt geht's zumindest schonmal soweit, daß man was sieht.

Dickes Aber!

Was man sieht, ist eine grüne Dia-Show mit lauter Artefakten... Also ist da im Stream tatsächlich noch irgendwas falsch. Die Frage ist nur, was?

[7.e.Q]

Wenn ich die GOP-Size auf 1 stelle, sieht das Video im SIP Client so aus. Immerhin ist da schon mal etwas zu sehen. Aber eben noch nicht korrekt... hier mal die Einstellungen des Encoder-Context:



pCodecCtx = avcodec_alloc_context();

pCodecCtx->width = CodecCtx->width;
pCodecCtx->height = CodecCtx->height;
pCodecCtx->gop_size = CST_OPTION(PARAM_GOP_SIZE, CodecCtx->gop_size, int);

pCodecCtx->max_b_frames = CodecCtx->max_b_frames;

pCodecCtx->bit_rate = CST_OPTION(PARAM_BITRATE, 128000, int);
pCodecCtx->bit_rate_tolerance = CodecCtx->bit_rate_tolerance;
pCodecCtx->pix_fmt = PIX_FMT_YUV420P;

pCodecCtx->time_base = (AVRational){timebase_num, timebase_den};

// pCodecCtx->flags = 0;
// pCodecCtx->workaround_bugs = 0;

pCodecCtx->flags |= CODEC_FLAG_H263P_AIC;
pCodecCtx->flags |= CODEC_FLAG_H263P_UMV;

pCodecCtx->rtp_mode = 1;
pCodecCtx->rtp_payload_size = CST_OPTION(PARAM_PAYLOAD_SIZE, 1000, int);
pCodecCtx->rtp_callback = &h263_rtp_callback;

pCodecCtx->workaround_bugs = FF_BUG_AUTODETECT;


CST_OPTION(x,y,z) setzt den Wert des in x angegebenen Parameters PARAM_??? ein, oder wenn dieser nicht gesetzt ist, den Standard-Wert, der als y angegeben ist (gecastet nach z).

In PARAM_GOP_SIZE habe ich in diesem Beispiel den Wert 1 übergeben.

Vielleicht kann damit jemand etwas anfangen und mir sagen, welche Einstellungen falsch oder überflüssig sind oder fehlen...

[7.e.Q]

... größere GOP Sizes führen zu solch zweifelhaften Ergebnissen...