Question

Been pulling my hair out over what should have been a quick and easy task.

I have a self-hosted WCF service in which I need to implement real-time video transcoding, the transcoding isn’t a problem as such, using FFMpeg to a local temp file.

Quick sample of what my code looks like;

public Stream StreamMedia(int a)
{
    String input = @"\media\" + a + ".mkv";
    String output = @"\temp\transcoded\" + a + DateTime.Now.Ticks.ToString() + ".wmv";

    ProcessStartInfo pi = new ProcessStartInfo("ffmpeg.exe");
    pi.Arguments = "-i " + input + " -y -ab 64k -vcodec wmv2 -b 800k -mbd 2 -cmp 2 -subcmp 2 -s 320x180 -f asf " + output;
    Process p = new Process;
    p.StartInfo = pi;
    p.Start();

    Thread.Sleep(2500);

    return new FileStream(output, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
}

The problem I am facing is that the returned Stream only gives me what was written to the file when it is returned – resulting in a rather short video file 🙂

I’ve played around with the obvious here, but no matter what I do it will only return what’s available there and then.

What I need to happen is for the Stream to be returned with no respect to the actual current lenght of the output file – there is other code involved which makes sure the data is never sent to the client faster than what FFMpeg manages to encode, so basically I just need an open-ended stream.

Any takers?

Answer 1

One solution would be to create your custom Stream class which would wrap around the file from disk; BUT, there’s also the concurrency issue, meaning that you need some locking mechanism as for the writing process (video transcoder) to properly share the file with your FileStream.

Is it possible for your transcoder to create multi-volume output? If so, then your lucky and this would work with (almost) no pain at all, just do the streaming of the volume N, then the transcoder writes the volume N + 1, and you’ll not have any file access concurrency issues.

happy coding!
– Adrian