if (foo) {
} else {
}if (foo) {
} else {
}if(m_socket >= 0) {closesocket(m_socket); m_socket = -1;};if (m_socket >= 0)
{
closesocket(m_socket);
m_socket = -1;
}hINet = InternetOpen("Mozilla/4.0", INTERNET_OPEN_TYPE_DIRECT, NULL, NULL, 0 );+ if ( hData ) {
+ if (!HttpSendRequest( hData, NULL, -1, NULL, 0)) {
+ }+ // If nothing recieved wait 100ms and read once more
+ if (len == 0) {
+ Sleep(100);
+ resp = InternetReadFile( hData, pData, cbData, (LPDWORD)&len ) ;// This buffer will hold the data only for a short time. Its nessecary because we need to skip the first 12 bytes unsigned int firstTimestamp;
unsigned int lastTimestamp;
bool isContinous;
int processedBytes = rtpHandler.getPacketData(pData, cbData, firstTimestamp, lastTimestamp, isContinous); REFERENCE_TIME rtStart = 0; //firstTimestamp;
REFERENCE_TIME rtStop = 0; //lastTimestamp;void ZeroURL(URL_COMPONENTS *url) {
url->lpszScheme = NULL;
url->lpszExtraInfo = NULL;
url->lpszHostName = NULL;
url->lpszPassword = NULL;
url->lpszUrlPath = NULL;
url->lpszUserName = NULL;
url->dwSchemeLength = -1;
url->dwHostNameLength = -1;
url->dwUrlPathLength = -1;
url->dwExtraInfoLength = -1;
};
) char pBuff[2048];
memset(pBuff,0,2048);
memcpy(pBuff,fn,strlen(fn)+1);#define IPTV_BUFFER_SIZE 10 * 1024 //By default 32KB buffer size* Copyright (C) 2006-2009 Team MediaPortal packetItem *temp = firstItem;
firstItem = firstItem->next;
delete temp->data;
delete temp;
...
newItem->data = new char[length];
memcpy(newItem->data, data, length);
newItem->size = length;
newItem->next = NULL;
newItem->sequenceNr = sequenceNr;
newItem->timestamp = timestamp; // If buffer is greater than IPTV_RTP_INTERNAL_BUFFER_SIZE deliver data
if (packetSizeTotal >= IPTV_RTP_INTERNAL_BUFFER_SIZE) return true;When I started to work on the filter I set up VS to meet the coding conventions. But while coding I didn't pay much attention on that. I'm used to a different style (more the Java way).
I found the code in the original version and many socket examples show it the same way. But after your post I searched a bit in msdn. It seems that there is a possibility to register a callback. I think that callback method would run in a different thread. Then we need to synchronize it with the main thread, at least in the rtp part. Do you think it's worth the work?
The socket writes the received data into that array. I don't think it's possible to tell the socket to use a 12 byte offset. The comment is not as accurate as it should be. The first 12 byte are the rtp header. The filter uses the header to check if it is a rtp packet and to detect dropped packets. I think we need the short-time array, or do I missunderstand you completely
I don't get warings with VS 2005. But besides this any variables should be initialized. Who knows how the next compiler version handles it...
Jap, and this is a long story. In the beginning my inet connection was very bad when it comes to IPTV (main reason was that my isp used wrong settings on my cable). That was very bad for watching TV but good to test the filter in terms of error correction. RTP uses udp for transmission and so I got lots of packet losts. I tried different ways to handle the losts packets. I played with the discontinuity flag of the MediaSample, set the timestamp, submitted only continuous data in one mediaSample, inserted missing data with last arrived data as well as with zeros and some other things.... I tested it all with ffdshow dxva, CoreAVC and MS DTV codec. The results were exactly the same when I set the timestamp and when I didn't. Do the dx filters really care about the timestamp? I got the best results without setting the discontinuity flag and without setting the timestamp and with filling the "holes" in the datastream with zeroes. Thats why I set up the filter to work this way.
I think I don't get what you mean. ZeroURL is used to initialize the url structure. What conatent do you mean? Anyway, thank for the hint with alloctracing.h. Will check the filter with that.
Oops. You're absolutely right.9) Possible heap corruption. fn lenght could be over 2kb (not in normal cases most likely, but could allow someone to use buffer overflow attacks - there might be few similar places in MP's exsting code but we shouldn't at least add more
Oops, again. Changed the value often while doing the testings and forgot the comment...
Wanted to keep packetItem as lightweight as possible. But you're probably right, it's better the way you suggest.
13) Quite useless comment
That sounds good in my ears. I think there are some people out there who would like to have this patch in the official code.
again for looking into it, tourettes