Well i have some serious problems with Fix3, too. With Fix2 i can connect very fast on the stream as first, but second does have really problems. When i use fix3 it took minutes to connect the stream and got these Errors

Playenginefix is donw by compiling, well do i need to rename that shoutcast-h264-fix2 or fix 3 to shoutcast-h264.jar ? Looks like its not special if an Shoutcast-H264 is in lib ? But with Fix3 it tooks so long, even VLC Player has connection problems, with the other fixes 0,1-b,2 VLC connects real fast

Where can i change the Keyframes, we broadcast at 20fps,64kbps aac+ and 136Kbps Video, so what would be the the count then ?

A solution? Sorry dont have one. Howabout, 'dont use VLC'. There is not a lot I am able to do without further reseach and development with VLC. I did suspect my own timestamps on the mp3 however there seems to be no troubles transcoding to silverlight or forwarding streams other servers such as justin tv.

I am leaning towards blaming VLC but I'm open to ideas and more information. When only one player at the party cant keep up with the others, I tend to blame the odd-ball.

Yeah, oLRi. I saw a few blotches on your stream, and maybe I suspect what causes it. No way to know for sure without research, but I'm unable to do so at this time. It maybe due to the nature of the DNAS delivery which is usually in big chunks compared to the normal rtmp trickle. It may also be due to wrong maximum nsv frame size calculation.

Even if there was some paid research time, I don't know if I could provide a glitch-free delivery.

I must admit, I don't know what that even means ... however ... if there is some issue with this ...

Cast your mind back to the nsv specifications, which include a payload maximum for audio and video. If I mis-calculated the amounts, I may drop the frame. I'll wait for the live DJ to come back online and test it again, but I am in doubt this is the case.

Quote:

how could moving to a different video codec fix an issue with some calculation of the container frame size?

You are forgetting that H264 does not have any corruption problem that VPx does. Switching to the better codec eliminates the issue. The frame-size-as-culprit is only a wild guess that my parser is incorrect.

Quote:

No idea where the stream is ... but ... the issue sounds like the discardable vs non-discardable inter frames one ...

Yes, however He is using the fixed version, and I have seen a bit of the distortion in his and mine under certain circumstances.

As i said earlier: I'd love to switch to h264 if somebody could show me a live-transcoder for h264 to vp62 so that the winamp-using people also could see the video (nativly, without plugins / dlls). NSV would be a great format if such things would be supported

google for 'vp6.c' and look though libav or ffmpeg sources. You will find the decoding differences between top-down and top-up DIB imaging. Somebody could theoretically implement 100% compliance or try to reverse engineer the output of other encoders, however, I'm not inclined to do so.