Hi Ross, As Promised, here is a patch for our first step for supporting raw video stream : the receiver side. It also contains a correction for the compilation of the mingw config that was broken (my mistake because of my last submission on the keep alive on socket :-D) I have tested it with only one kind of source and on a linux environment.
> Yes, very likely. Do you also plan to implement this for transmitters - > i.e., a subclass of “MultiFramedRTPSink”? I will work on it, linked with the use of a "V_UNCOMPRESSED" track in a matroska file. It should allow us to test the whole chain of live555. But for now it is my turn to be in holidays, and I could not do anything before a while. > After re-reading RFC 4175, I think that it should be possible to implement > most of this payload format fairly easily, by reimplementing the > “processSpecialHeader()” virtual function in your >“MultiFramedRTPSource” > subclass. The big problem, however, is going to be the ‘extended sequence > number’ field. I see no way to implement the handling of ‘extended sequence > numbers’ without >making major changes to the code. The best solution for > now would probably be to ignore this field - which will mean that receivers > will unnecessarily drop some packets if they get excessively delayed. I totally agree with it and as far as I can see, this extended sequence number is not used by our camera. Also I did not used any "BufferedPacket" subclass, but maybe am I missing something? Best regards, Denis.
live_raw.patch
Description: live_raw.patch
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
