Possible regression with “vlc:option” set to “no-video” in XSPF playlists with VLC 3.x

[marcow]

In XSPF playlists, which have long been supported by VLC, you can use VLC-specific extensions.

One of these extensions allows you to suppress video content for a playlist item (and thus play audio only):
   

Code: Select all

<vlc:option>no-video</vlc:option>

   
This has worked perfectly up until VLC version 2.2.8. But with versions 3.0.0 through 3.0.4, it seems a regression might have been introduced:

If the
   

Code: Select all

<location>…</location>

   
of the playlist item references a large file (e.g. ≥ 8 GB) and the
   

Code: Select all

<vlc:option>start-time=…</vlc:option>

   
for the item is well into the file (e.g. ≥ 30 minutes), VLC will “freeze” for quite some time before proceeding with playback of the item. The blue progress/seek bar is replaced with an orange bar that gradually moves from 0 % to 100 %, i.e. completes the full width. After that, playback continues.

This behavior has not been present in versions 2.2.8 or before. And if I switch back to VLC 2.2.8 now, the problem instantly disappears, as expected. It’s only the 3.x versions that have been released so far.

Did anyone else notice this or can anybody reproduce this?

Full example:
   

Code: Select all

<?xml version="1.0" encoding="utf-8"?> <playlist version="1" xmlns="http://xspf.org/ns/0/" xmlns:vlc="http://www.videolan.org/vlc/playlist/ns/0/"> <trackList> <track> <location>Test.mkv</location> <extension application="http://www.videolan.org/vlc/playlist/0"> <vlc:option>start-time=1828.346</vlc:option> <vlc:option>stop-time=1833.203</vlc:option> <vlc:option>no-video</vlc:option> </extension> </track> </trackList> </playlist>

   
(All this has been tested on an up-to-date Windows 7 only, because that is unfortunately the only machine available to me.)

[marcow]

Video codec: H264 – MPEG-4 AVC
Audio codec: DTS Audio
Graphic card: AMD/ATI Radeon HD 8570M

Disabling hardware acceleration in VLC does not change anything.

So perhaps it could be the DTS Audio, too, which causes problems with 3.0.0 through 3.0.4 but not with 2.2.8.

Otherwise, it could be related to the following issues:

forum.videolan.org/viewtopic.php?p=479105#p479105
forum.videolan.org/viewtopic.php?p=480567#p480567
forum.videolan.org/viewtopic.php?p=480906#p480906
https://forum.videolan.org/viewtopic.ph ... 55#p481455
https://forum.videolan.org/viewtopic.ph ... 62#p481462
https://forum.videolan.org/viewtopic.ph ... 86#p481986
https://forum.videolan.org/viewtopic.ph ... 35#p482335
https://forum.videolan.org/viewtopic.ph ... 64#p482464
https://forum.videolan.org/viewtopic.ph ... 44#p482944
https://forum.videolan.org/viewtopic.ph ... 67#p483267
https://forum.videolan.org/viewtopic.ph ... 08#p483908

[marcow]

I have verified that the problem persists with the latest version 3.0.5, so that’s 3.0.0 through 3.0.5 where the extremely slow buffering with the slowly moving orange bar appears – for the same input that has instant playback on 2.2.8 and before.

But it’s not the audio codec of the input (DTS Audio) that is causing the issues. I have verified this by generating a variant of the input file using
 

Code: Select all

ffmpeg -acodec mp3 -vcodec copy

 
and the problem still occurs.

It’s not even the video codec of the input (H264 – MPEG-4 AVC), which I have confirmed using a variant produced by
 

Code: Select all

ffmpeg -vcodec mpeg4

 
where the problem shows up, too.

The large file size (7.5 GB) is not the cause, either, because re-encoded variants with practically the same file size (99.85 %) do not show the problem.

Instead, it really seems to be the container format (MKV) and its interpretation by VLC which is causing the issue:

When producing a variant of the input file using
 

Code: Select all

ffmpeg -acodec copy -vcodec copy output.mp4

 
(i.e. keeping the video and audio data but changing the container format) the problems disappear instantly!

[unidan]

Hi,

it might be a buffering issue, would you have logs?

To help you, we need messages, to completely understand what your problems is.
To fix this, please be sure before you start the playback to:

1. Open: Tools -> Messages.
2. Set Verbosity to 2
3. Start playback to reproduce your issue
4. Save text in a file or copy into clipboard
5. Then paste the full resulting log here between [​code]and[​/code] (or use Pastebin.com if it's too long)

Also don't forget to name your Operating System and provide the VLC media player version.

[marcow]

Thank you for your reply!

Here are the logs:

• VLC 3.0.5 on Windows 7 (“not working”)
• VLC 2.2.8 on Windows 7 (“working”)

Unfortunately, it’s not possible to efficiently diff the two logs, because the logging format and the logged information has changed a lot between the two versions, apparently.

Doing that manually, I have not found anything remarkable, but I don’t really know where to pay special attention, either.

While the orange bar is visible on 3.0.5, gradually moving from 0 % to 100 %, the “Messages” window only fills with buffering entries that show the current progress and appear very slowly. On 2.2.8, all this happens instantly, and all the log messages are there more or less right away.

Again, the problems on 3.0.5 only occur with MKV files. If I re-encode the files to MP4, everything works perfectly. But if I re-encode to MKV again, the problems come back. So it really seems to be specific to MKV.