The VideoLAN Forums

[Apologies in advance, if this duplicates/overlaps some similar earlier postings/discussions.]
My signature summarizes my workaround for this issue.

I've been using VLC to pre-transcode movie videos for at least the past year. (Before I add marquees to my transcoded,
I used Handbrake to transcode, but VLC is much more capable.)

My current method is to transcode with a VLC cmd-line rather than the GUI, but either method results in with the
problem, using VLC version 2.x (I just tried version 2.1.3 again last week, and the problem is still there.)

When using a standard "--sout=#transcode ..."

and a sub-clause such as: ":marq{marquee="this_movie_name $_ $T / $D",timeout=0,refresh=50,position=5,size=16}

what is SUPPOSED to happen is that $_ will be replaced with a 'line-feed/carrage-return', and $T will be replaced with current-time,
and $D willl get replaced with the video's total duration.

That is exactly what happens if one used VLC version 1.x. (e.g. version 1.1.11)

However, this has been broken...it no longer works in version 2.1.3 (and at least some versions earlier in the 2.x series).

What happens now is that the substition step doesn't happen, and instead you erroneously get just the literal text (e.g. $_, $T, $D, etc).

Is there an process (e.g. URL or whatever) where I can go to formally report this bug myself? (so it can get fixed.)

If not, please consider this posting/thread as a bug report.

If you need further info, please let me know. [This is problem is quite straight-forward to reproduce.]

Cheers and regards...

Sarasota Slim

Hmm no? Only time expansion is documented and implemented in the marquee SPU source at the moment. See also https://wiki.videolan.org/Documentation:Format_String/

Hmm no? Only time expansion is documented and implemented in the marquee SPU source at the moment. See also https://wiki.videolan.org/Documentation:Format_String/

I don't understand. You say 'only time expansion is documented and implemented...at the moment.'

Wouldn't $T and $D (time and duration) be considered to be 'time expansion'?

You say they are implemented. But, they don't work.

So, in my language, that means they're broken and need to be fixed.

So, my earlier question remains: Where and how do I report this bug?

(Or are us users not given an interface to report bugs? If so, then can you
or someone else there please report this bug for me?)

No. Time expansion is strftime() syntax for current time. $-things are metadata expansions.

No. Time expansion is strftime() syntax for current time. $-things are metadata expansions.

Ok...so it's the metadata expansions that are broken now, in version 2.x of VLC.

But, we are OFF-TOPIC again. I ask once more:

Please explain where us VLC users go to REPORT A BUG!

No. Time expansion is strftime() syntax for current time. $-things are metadata expansions.

Ok...so it's the metadata expansions that are broken now, in version 2.x of VLC.

But, we are OFF-TOPIC again. I ask once more:

Please explain where us VLC users go to REPORT A BUG!

Hi SarasotaSlim,

I've been having the exact same issue as you. The marquee was working in previous versions of VLC (prior to 2.x I believe), but the $T, $D etc overlay functionality seems to be broken now.

There was already a bug ticket for this: https://trac.videolan.org/vlc/ticket/9858 , but it seems to have been closed without resolution.

For details on creating a new bug ticket, please see: https://wiki.videolan.org/Report_bugs

Thanks for all that info, vlcuser29!

[It's too bad that I had to learn where to file bugs from another user, rather than the folks who (attempt to)
moderate/operate this forum , but I"m happy to get answers where ever I can. ]

Ok, after having read the previous bug-reports relating to broken marquee functionality, I think I see
now why the problem, in the context I'm seeing it in, hasn't been fixed. So, I'll take it from here, and
file a new bug report on the bug (mine is in an '--sout' context) , and then I think they'll be able to
find and fix it.

Thx again...cheers...

You're welcome, SarasotaSlim.

Once you create a new bug report, please post the URL to the bug report on this thread so that others and I can track. Thank you.

You're welcome, SarasotaSlim.

Once you create a new bug report, please post the URL to the bug report on this thread so that others and I can track. Thank you.

They closed my bug-filing (i.e. #10707), as a duplicate

The currently-open bug is here:
https://trac.videolan.org/vlc/ticket/9514

Vlc version 2.1.5 came out in the past week or so, but it does NOT contain the fix for marquee-substitutions.

That bug report indicates that the projected milestone will be "Milestone changed from Bugs paradize to Features paradize"

Best guess is that the 'paradize' being referenced will never occur, as paradise is the place one goes to after death.

The (still open) ticket to this problem is here:
https://trac.videolan.org/vlc/ticket/9514

(You may noticed it's categorized as 'new enhancement', but that's just an artifact that it had been open
so long that the developers had to change it from 'bug-fix' to 'new enhancement'. But, bottom line is
that this feature broke way back around VLC version# 2.0.6 or #2.0.8 area.)

I don't know whether to be mad or embarrassed

The (still open) ticket to this problem is here:
https://trac.videolan.org/vlc/ticket/9514

(You may noticed it's categorized as 'new enhancement', but that's just an artifact that it had been open
so long that the developers had to change it from 'bug-fix' to 'new enhancement'. But, bottom line is
that this feature broke way back around VLC version# 2.0.6 or #2.0.8 area.)

I don't know whether to be mad or embarrassed

Insulting people will not get you any help.

The issue is not fixed, because it is a bit more complex than you think. If you found another solution, great for you.

The bottom line is that the video output can outlive the input and therefore the marq can crash.

>>>Insulting people will not get you any help.

Yes, I fully realize that.

>>>The issue is not fixed, because it is a bit more complex than you think. If you found another solution, great for you.

I had no preconceived idea of how simple or complex the issue is. I could buy your complexity explanation, if that
had slowed down a solution by 3 months or six months or (maybe even) a year.

But after 3 years, it is ABUNDANTLY clear that no one ever plans to tackle the issue. You're kidding YOURSELF,
Jean, if you believe otherwise. If I hadn't found an alternative solution (i.e. FFMPEG), I would never have even
bothered updating this thread/open bug-report. But, now that I have an alternative solution, I feel free to toss
out a few caustic remarks.

I'm still a skeptic. From my vantage point, I'm willing to bet that in three MORE years, if I come back here
I'll find that the issue still hasn't been fixed. Care to take that bet?

You are right that it could be implemented in less than 3 engineer-months. In fact, it could have been fixed in VLC 2.1.0 if anybody actually cared.

So I take it your insult was aimed at the people who pretend to care about the feature, but won't bother implementing it or supporting the implementation work. In other words, people like you.

How can a non-developer support the implementation? Oh, with money?
Tried that already, in the mailing list and comments on bug report
Offered to fund the fix... no one seemed interested.

It's been literally years, and I doubt the difficulty of fixing it is anywhere near a 3+ year problem.
It's a little bit embarrassing. Though if it has at least been fixed in the documentation and no longer listed as a feature, I guess it could get away with not being called a bug....

I would advise contacting the consulting companies directly. They are listed on the official website (and to be clear, I am not currently affiliated with any of them).

Yep. And I am