NSV file format

[Jay]

As some of you know I have been trying to trace down exactly how to regulate NSV files by reading frame headers in the file format and passing them to the server at the correct speed so that I may release a script that will be able to essentially do what nsvscsrc does but better and on multiple platforms.

I finally got around to really sitting down and tracking down the way the format works thanks to the technical paper located here

http://www.pcisys.net/~melanson/codecs/nsv-format.txt

I wrote up a script that seems very successful at decoding the file format and displaying the correct frame information, however the technical paper (of course 'cause NSV is beta) is incomplete and doesn't answer alot of questions.

Some problems I have hit that are not covered by this technical document are:

1. Meta Data Embedding: now of course I am fairly confident that this one can only be answered by the nullsoft, but is it possible to embed a NSVf Meta Data chunk inside the file and not just at the beginning?
This would seem like the way it should work considering it is a streaming format and this content can change, File Titles and the like?

2. I know alot about how NSVf and NSVs works, however I cannot get past the fact that in files larger then 5 seconds, the NSVs Chunk stops and restarts? Is this for syncing purposes? what's at the tail end of the chunk? when BEEF doesn't show? I am sure it's a frame of some sort, but the rules prescribed by this document do not apply and BEEF mysteriously is a several bytes ahead of the point we thought it would be using the size given by the previous frame header.

Anyhow I am sure no one can really help I just thought I would try to see if I could get someone who may have more insight into the format or someone who might know where i can find more information.

Thanks

[Jay]

nm got it nailed I think, (and this is all based on assumption but it works on my test stream).

1. meta data must be passed between NSVs chunks (haven't tried this yet but this must be the reason there are multiple NSVs chunks in a single file, the logic on this baffles me though.

2. The reason for the loss of sync is appearently there is a possible condition of no beef and size header, so when you reach the end of a frame mentioned by the previous frame header and you see no BEEF, you assume the last known frame size.

Once again this is not official but it works, for those interested.

[EDIT]
Incidentally if anyone knows why audio/video slowly looses sync after you stack a few files together I would love to know.

[della]

oi,

thanx, your file there helped me making my app do nsv :)

I looked at some files and streams and found the servers dont send a NSVf chunk at all (they are only in files?)

I don't send any beef at all, instead I send a NSVs hdr along with any
one or 2 packets (depends on how much audio/vid i get) when streaming.
Some have only audio or vid, some have both, tho always the same fcc-handlers.

about the 5 seconds..

Since the shoutcast servers arent addepted to stream nsv the encoders have to put in some extra data here and there to make sure the players understand the format (thas ya 5 seconds / NSVs chunk)

Making sure ya server handle these nsv streams bij sending appropriate chunks and beefs (and timing along) if possible would overcome this.

[della]

the sync loss might be caused by the memory leaks ?

found some leaks in winamp 3.0d and the web-plugin, 8 to 16 kb/s..goes whoop after a while

[Jay]

well I noticed that it only starts going out of sync on a next file, so it must be something disproportional that the winamp player is doing, or the NSVenc encoder is doing.

[della]

ooohhh :/

My memleak seems to be caused by faulthy vid-chunks,
audio runs fine, just the vid slowing down as time passes (gonna try and buffer a few vid-frames ahead, mebbe it helps).
(actually, me pretty sure almost all is right, if it'd miss
an audio buffer caused by a bad beef or header it'd heard it,
also checked all network buffers etc, all seems fine...just a few steps from my point and click multiplestream encoder :))

*snip*:

bytes 0-3 'NSVs' signature
....
bytes 17-18 unknown


Anybody happen to know what those 2 unknown bytes are in the NSVs chunk? (they mean something, just cant guess what :)

[Jay]

there are alot of unknowns in the NSVs header, I am still working out these facts, I plan on releasing a new technical writeup with my results as soon as I finish this project that recognize my discovery plus some differences that getid3.org has on the NSVs header.

[della]

me a very happy della....

got it working now, matter of muxing and buffering the audio (had 200 byte mp3 buffers, winamp dont like..lol

http://137.224.241.250/images/LiveChunk.231b.jpg

cheers, working on that ;)

[della]

ps,

the 2 unknown bytes are just BEEF that is rotten a bit ;)
cheers

[ZeosPantera]

Ok First you get a prog called Camtasia studio..or any other software that will capture audio and video right off the desktop. Then all you have to do is set it to capture the actuall video off the screen(Overlay Off) and it will appear as a capture source. I recomend playing the video in winamp and capturing @ 320x240. this system works well because theres no converting needed and any file you can play in winamp will be instantly captured and streamed...

[Jay]

that's horrible, I wouldn't even consider doing this on a Linux machine, this is not resource safe, plus static files can be at any quality and not skip or freak out the machine. More peace of mind this way I believe.

[della]

for those interested,

the title and aspect fields in the NSVf chunk
are not always delimited by ` (char(60)) characters as the format-doc states. I also encountered some using ". So be cautious :)