The VideoLAN Forums

I have been looking into getting similar functionality into libvlc as the "record" button in the vlc gui. This button allows you to automatically save the current media to your Video/Music directory, wihout the need to specify any sout/transcoding options.

As with a lot of other libvlc implementation, it seems like this is simply a matter of using the appropriate vlc variables to trigger functionality.

Indeed, I have implemented in my own libvlc build some new API to query the recording state and start/stop the recording. This was pretty easy to do and seems to work just fine.

There are some limitations to this functionality - and the limitations are there in the vlc GUI as well as my own libvlc API. The limitations are that when recording is enabled it is not possible to pause, skip, change chapter, change time/position and so on - all of those functions become no-ops. Anyway, whilst recording is enabled those are probably understandable restrictions. If I remember correctly you also have to enable recording before playing the media - so it's not quite an on-the-fly solution. Also, I'm not sure whether you can have full control over the generated filenames or not.

So now I have this implemented and working is there any interest in this, and is such functionality (even with its limitations) worthy of being included in the official libvlc? Or would there be some other requirement of such an API to make it fit for inclusion in libvlc?

You should post patches against the current vlc.git on the vlc-devel mailing list. As long as the limitations are clearly documented in Doxygen, I think it's fine.

Thanks Rémi, I'll send a patch soon.

On a positive note, my original comment was incorrect: the recording *does* actually work on the fly.

I would like precise control over the generated filenames, but that seems not so straightforward so I'm not going to address that in the first patch.

Err... you're not supposed to change a LibVLC API once a release has been made.

Err... you're not supposed to change a LibVLC API once a release has been made.

Sure, but you can add additional API can't you.

Presuming I can find a way to do it, which right now I can't.

I find the claim a bit presomptuous. I'd expect the file name as a parameter in the function that starts (or maybe stop) the recording. That's not something you can add after the fact without breaking compatibility.

I'd expect the file name as a parameter in the function that starts (or maybe stop) the recording. That's not something you can add after the fact without breaking compatibility.

Understood. I found enabling/disabling the recording to be straightforward since it's a simple hook into existing functionality. I did not find it straightforward to specify a filename. I will look into it some more.

I think I found a way to specify the filename.

Do you think it is better to specify the filename when you start recording, or when you stop? Specifying it when you start seems more natural.

How do you ensure that the extension is correct then? It might be safer and simpler to just return the name of the recorded file after the fact.

How do you ensure that the extension is correct then? It might be safer and simpler to just return the name of the recorded file after the fact.

Well so far I specify a filename without extension and vlc automatically picks the correct one.

I agree that this is not ideal, since the calling application does not know the full filename (i.e. including extension) in advance, but in principle I think it's nicer to allow the caller to supply at least the filename prefix that they want.

From what you say I think maybe I should fire some sort of event notification after the file has finished being written. I suppose that would be similar in intent to the "snapshot taken" event. Would something like that be acceptable? I will look into this some more, but I don't want to go down the wrong path.

Personally, I am fine either way. I am just not sure applications can be trusted to choose an adequate record path as well as VLC does. We already have OS abstraction for that... Do you really want to replicate that in every application? And vlcj is supposed to be OS-independent, no?

It might be easier to make the record stop function return only when the file is finished. But maybe that would raise deadlock concerns?

Personally, I am fine either way. I am just not sure applications can be trusted to choose an adequate record path as well as VLC does. We already have OS abstraction for that...

I think that's a fair point, especially since already a limitation of what I have so far is that if the supplied filename contains a full path that does not exist then the recording will fail without any error being reported to the application. I could write more code to check all that of course, but I think it may be wasted effort and instead I should simply defer to VLC to handle the record path like you suggest.

But then again, I can see advantages to the calling application to be able to specify where the files should go in the first place - rather than saving to e.g. ~/Videos and then moving to some sort of application-specific library/archive directory. This would fit more with the idea of having something like the existing sout-record-dst-prefix variable actually be configurable.

And vlcj is supposed to be OS-independent, no?

Yes, but my thinking was at some point you have to rely on the calling application to do the right thing - as long as any error condition can be detected.

Having said that, I do think the other approach of relying on VLC to choose the path is safer.

It might be easier to make the record stop function return only when the file is finished. But maybe that would raise deadlock concerns?

I really don't know at the moment how I would implement it that way, due to my lack of VLC knowledge, and even then leaving aside the deadlock concern isn't there another case of what to do if recording stops naturally, e.g. if the media finishes without the calling application stopping the recording first?

I'm thinking right now that at least I have *some* idea how I could send an event notification with a filename after the recording stops, but right now I have no idea how to wait until the recording stops. Clearly whatever I come up with, the client application needs to know for sure when recording has completely finished.

This task has become a bit more than just emulating the record button functionality, but I think it's a nice feature to have and I want to try and see it through.

I was going to implement this in a similar way to the existing implementation for saving video snapshots, i.e. use a new callback on a new variable somewhat like "snapshot-file".

I see that a "record-file" variable is already implemented - but this can't be used because it is set at the *start* of the recording, not at the *end*.

So, the idea was you invoke an API method to start recording, wait a while, invoke an API method to stop recording, some short time later the recording stops and the file gets written, the new variable gets set with the filename that vlc generates, thereby causing a new event to fire through libvlc to the media player event manager.

I think on the face of it that should be quite simple to implement.

However I noted these comments in the libvlc source (media_player.c): And this: But with those comments already in the code I fear that adding more of the same for my new record-file implementation will not be acceptable.

So I am curious to know if anyone knows the thinking behind those comments, and if there was some other preferred way to do this already in mind?

I am not (just yet) considering the other idea of having a stop recording call block until the file gets created. I simply don't know how I would do that at the moment.

Hi Sherington

Did you finally get a patch? I'm really interested in this feature

Thanks in advance

There's a patch on the mailing list from a few months back. It works for my own use-cases quite nicely, but the patch is not entirely correct (see review comments in the mailing list thread) and was therefore rightly not accepted. I won't be revisiting it.