VLC strange Time Value (offset) for ""View Network Stream"

[steve333]

Sorry if I'm being stupid, but I can't see how VLC is getting the time when I am using "View Network Stream" (live or recording).

I have an IP Camera.
The time on the Camera, Router and PC are all set to local time GMT (+1 hour, still DST in UK for a few days).
They are synchronising using the same server (Windows Time).

When I view the stream using VLC it shows a time which is roughly 2 hours 10min ahead of this (ie GMT+3h10min at present).
The odd 10min extra is puzzling as it seems to be constant (initially I thought it could be due to a frame-rate error but now that looks unlikely).

In any case I would like to at least get the timezone correct.
I did close VLC and re-open it, but it still picked up the same time offset (including the odd 10minutes which seems strange).

I can see the Preferences "Network Synchronisation" setting to select a "Network Master Clock" or "Master Server IP Address".
But I really just want it to synchronise with the PC (or Camera).
Presently both fields are blank (default).

I won't always be connected to the Internet when using VLC to record the camera so don't really want to have to set an Internet TIme server.
- Is there an option to tell it to use the local PC time?
That would be good enough for me and the PC gets it from the Internet when it's connected.

I suspect that maybe it's supposed to be doing this already, but for some reason it's added a strange fixed offset.
I can't see any preference to set the timezone, or debug messages about the time / timezone / offset.

I note that the recorded ".avi" file timestamp starts at zero in all cases.
- Is there an option to put the real time on the recorded file?

Can anyone help?

[Rémi Denis-Courmont]

As far as I know, timestamp always starts from 0 (implicitly) in AVI files.

As for where VLC gets the time from, that depends what time you mean.

[steve333]

Thank you for your reply.

Having done some more recordings it seems that if I open VLC and view a new stream then it starts the AVI at 0 as you mentioned.
What was confusing me is that if I stop the recording, stop viewing the stream and change the recording file the time displayed on the user interface continues from where it left off previously.

But each new AVI file seems to have it's own recording timestamp starting at zero.

When I was recording earlier the user interface seemed to be following realtime with an offset which was confusing me (due to the time of day when I started it).

It would be better if the user inerface and the AVI file showed the same timestamp.
Actually it would be a nice option if VLC could use the local system time (PC time) for the user-interface and AVI timestamp.

Even nicer would be if VLC could add a timestamp (clock) to the video ......

[steve333]

When a network stream is being viewed (or displayed while transcoding) VLC shows an arbitrary "time" value on the GUI.
This bears no relationship to any "real" time from the PC or otherwise.

This starts at 0:0:0 after a reboot (and disk / tempfile cleanup).
Each new session (closing and re-opening VLC) continues with the "time" which was shown at the end of the previous session, so it's remembering the "time" somewhere internally.

The displayed values are therefore entirely arbitrary, but sequential.

The time value recorded into the file (if recording / transcoding) starts at 0:0:0 for each new recording and is generally sensible (though there are some strange quirks if you record for long enough, have variable frame rates or chose the wrong output container format - see my feedback on transcoding in a seperate post).

[Rémi Denis-Courmont]

As said, the timestamps depend on the source.

Most file formats are zero-based. MPEG-TS has an arbitrary timestamps that is set by the broadcaster. VLC generates timestamp from the monotonic clock for most live capture devices (microphones, cameras); that happens to be the boot time of the operating system in most cases.

[steve333]

I understand.

It would be a nice feature if VLC put the timestamp into the TS file which it created.
(Presently it leaves the time blank ie. no time shown on playback, no total time value shown.
Note that if I re-mux the TS file then VLC will correctly show timestamps which are created by a third-party tool).

And it would be nice to be able to define a starting time point, or to ask VLC to use local system time (clock).

Maybe this could be considered for a future enhancement.

[Rémi Denis-Courmont]

VLC does output timestamps into TS. There is no way to write TS files without timestamps.

[steve333]

Well yes, I know that the TS format has PTS (and DTS) fields.

However when I use VLC to transcode my network stream to TS and then play it back using VLC all I get in the GUI is "-:-:-/-:-:-".

So there's something strange happening either in the recorded file or the VLC playback.

To my knowledge this had always been the situation (since my first transcoding attempts using VLC 0.8 and WIndows XP 32, I'm now using 1.1.11 and Win 7 64).
But I have not tried to use VLC to transcode to TS very often, so I can't comment on most of the intermediate releases.

In the past I was editing TS and re-muxing so I didn't often need other processing and didn't care about timecodes displayed in VLC in any intermediate steps.

If I edited / demuxed the output TS file (eg. using Project-X) and then re-muxed it (eg. using DVDauthor) then I would get proper time information displayed when I played it back with VLC (ie: something of the form "0:12:47/1:06:15").

Now I'd like to use TS as a recording format for my network stream instead of AVI, because AVI has problems when the file size gets too big (some kind of 2GB limit, I guess).

(In this recent case I have disabled audio, but previously have tried with standard audio/video TS. Of course it shouldn't affect the TS either way.)

[Jean-Baptiste Kempf]

However when I use VLC to transcode my network stream to TS and then play it back using VLC all I get in the GUI is "-:-:-/-:-:-".

This is normal in VLC 1.1 and will be fixed in 1.2

[steve333]

Thank you.