Time code discrepancy

[katha-kiyanno]

Hello!

This is a great tool, and the interface helps one to also focus on writing/translating (giving the feel of a text file), helping the creation process unhindered. I have used it to create subtitles for several projects and feel the need to return to this simple interface, (even after seeking other tools for their availability of waveform and other features).

I am reporting this issue of time coding discrepancy, which I've been told is possibly a bug. I have used this tool for over 6 months recently and worked on many different files. As I use the designated shortcut keys, I have noted that the functionality of the keys Q, W, E, R (placing before and after) alongside U and K to denote beginning and end of a subtitle, are not accurately pinpointing the exact moment in the video. There are issues with how the final placing happens, when one plays the video. It may seem not to have saved accurately and even appear different when I open the file again, later.

Hope this can be rectified as the interface is so text-friendly and stimulates writing, and I think I will return to it each time I have to do the actual writing/ translating.

[otsaloma]

Hi! I'm not aware of an issue in that functionality, but neither have I used it that much myself. Can you expand on what "not accurately pinpointing the exact moment in the video" means? Do you see some consistency — are the times you get late or rounded or what does it look like?

The relevant lines of code are

gaupol/gaupol/player.py

Lines 157 to 176 in eda83a9

	def get_position(self, mode=None):
	"""Return current position in video stream or ``None``."""
	q = self._playbin.query_position
	for i in range(100):
	# Querying position sometimes fails very unreproducibly,
	# likely due to a particular pipeline state or state change.
	# Try repeated times, hoping to pass the bad state.
	success, pos = q(Gst.Format.TIME)
	if success: break
	time.sleep(1/100)
	if not success: return None
	if mode is None: return pos
	pos = pos / Gst.SECOND
	if mode == aeidon.modes.SECONDS:
	return pos
	if mode == aeidon.modes.TIME:
	return self.calc.to_time(pos)
	if mode == aeidon.modes.FRAME:
	return self.calc.to_frame(pos)
	raise ValueError("Invalid mode: {!r}".format(mode))

There's the weird loop hack of which I don't know how commonly it's triggered, but I think quite rarely. Apart from that, it's just using GStreamer as I think intended.

[katha-kiyanno]

Thank you for the response. I am not sure if I can explain it right. Also I have not noticed a consistency in the issue. What I notice is, that the time code in the video indicates one figure and the press of the U key seems to get another figure (I haven't notice why or when it happens, nor any consistent pattern. It just seems to suddenly refuse to align itself). Then, when one goes back to that location, the subtitle line doesn't seem to be in the exact correct place - not where the speaker's text is, although I have earlier pressed 'U' and aligned it.

This issue occurs once a first draft is done, and I attempt to refine the timing and the text. Therefore, possibly, well over 40 lines of subtitles would be available by this time. So, as I attempt to redo or refine a spot, the time code appears proportionately wrong, to the time given in a line below.

I note some issues, but as there is no clear pattern, I am not certain how to explain them even. I just see that the end result becomes problematic in terms of timing, in certain places, due to these inconsistencies.

[otsaloma]

I just tried it with a random video and seemed to work fine for me. Unfortunately I can't really do anything about this without understanding the problem, or preferrably being able to reproduce it.

Generally speaking, I could imagine that there could be some delay in how the event handlers fire that could then depend on the CPU etc. resources on your system or maybe the amount the CPU needed to render the video (depending also on the video resolution and codecs) but in that case I'd expect the times you get to be consistently late by maybe some tens or low hundreds of milliseconds.

[katha-kiyanno]

Let me firstly give the details of the machine I work on. It's Fedora Linux 42. And I have ensured I have sufficient disk space to work seamlessly.

The video file sizes were around 2-3 GB (20 minutes duration) and had around 300+ lines of entry. (upto 21 kb). If you want specific details to be able to reproduce it, I would very much like to assist the process as I really enjoyed working on it, and would like to help the community.

As stated in my second response, the sort of issues I faced was during extensive corrections at an advanced stage of finalizing. They occur as I try to refine a document, adjusting slight timing issue (before or after exact speech) when viewing, also using a different machine. In these cases, I cannot conclusively state which method I would have used to clear a point for when the subtitle needs to occur. -- It might be the U key or physically entering time, checking with the time code appearing as the video is paused, or the use of Q, W, E, R keys. But the logic of it is that each of these should lead to the same result. But it didn't. And it additionally had seemingly shorter time durations appearing for a subtitle in a mid entry, with a next line showing a longer duration entry, when the timing didn't seem proportionately correct. (I struggled with the issues then and there and got exasperated. I am reporting this issue because a fellow free software user also said that it might be a bug which would be good to report, while it was fresh in my memory.)

The times I did short subtitles of possibly less than 100 lines, I had no noticeable problem. And I'm flagging the above issue after finishing several projects one after another. And later realizing there is possibly an issue, when in this last project, I got to check the outcome on other machines.