why a big difference in playlist transition speed

[tmoran]

I have two half hour shows, each has a 1GB (about) VTS_01_1.VOB and about a .5GB VTS_01_2.VOB, and a playlist.m3u that simply lists VTS_01_1.VOB followed by VTS_01_2.VOB When planing one of the playlists there's an almost imperceptible glitch at the point of transition from _1.VOB to _2.VOB. When playing the other show the video window closes and then re-opens so there's a couple of second transition time. Why? And what can I do about it?
This happens on two different computers, with the files on their local respective hard disks, so it's not a defragment or disk location problem.

[Jean-Baptiste Kempf]

This is normal.

If the next playlist item has the same codec/video size/chroma, then transition is smooth.
If you need to change codecs or any decoding plugin, VLC unloads them and reloads them => delay

[tmoran]

According to ffmpeg -i the only difference (other than length) between VTS_01_1.VOB and VTS_01_2.VOB is that the first has audio in stream 0.0, video in stream 0.1, and the second has the reverse. But that's true for both the quick-transition and the slow-transition shows. The only difference I see between shows is that the slow-transition uses ac3 for audio and the fast-transition uses pcm_s16be. Am I missing something? More important, should I transcode something about the slow-transition version to make it a fast-transition?

[Jean-Baptiste Kempf]

But you said that the transition between _1 and _2 was fast, which is what I explained, didn't I ?

Between slow transitions, you change the codecs, therefore slow.

[tmoran]

For one of the shows the transition between _1 and _2 is fast. The only difference ffmpeg -i shows between _1 and _2 is the swapping fof which stream is audio and which is video. For the other show the _1 to _2 transition is slow. Again, the only apparent difference is the order of audio/video streams. Both shows are mpeg2video for both _1 and _2 files but one show (both its _1 and _2 files) is ac3 audio and the other show (both its _1 and _2 files) is pcm_s16be audio. So I take it there's some other difference between the _1 and _2 files that ffmpeg is not displaying? You mentioned "chroma" - what would that be? Is there a way to get VLC to tell me just what is causing it to shut down and reload in the slow transition?

[Jean-Baptiste Kempf]

I don't understand what you say.

You tell me transition between 1 and 2 is fast. So why bother ?

You tell me that transition between other stuffs is slow. So here is the issue, not between 1 and 2...

[tmoran]

I'm sorry this isn't clear.
Playlist_A lists "program_a\VTS_01_1.VOB" on the first line and "program_a\VTS_01_2.VOB" on the second line.
When VLC plays Playlist_A there is a barely noticeable transition when it finishes _1 and starts _2

Playlist_B lists "program_b\VTS_01_1.VOB" on the first line and "program_b\VTS_01_2.VOB" on the second line.
When VLC plays Playlist_B the window closes and re-opens, taking a few seconds, when it transitions from _1 to _2

ffmpeg -i program_a\VTS_01_1.VOB says stream #0.0 is mpeg2video, yuv420p, 720x480 and stream #0.1 is pcm_s16be audio.
program_a\VTS_01_2.VOB is the same, except that stream #0.0 is pcm_s16be audio and stream #0.1 is mpeg2video, yuv420p, 720x480 .

ffmpeg -i program_b\VTS_01_1.VOB says stream #0.0 is mpeg2video, yuv420p, 720x480 and stream #0.1 is ac3 audeo.
program_b\VTS_01_2.VOB is the same, except that stream #0.0 is ac3 audio and stream #0.1 is mpeg2video, yuv420p, 720x480.

So for both shows the only difference ffmpeg displays is the swap in stream number, and the same happens for both _1 and _2.
I dont' see what codec etc change might be causing the slow transition for program_B while not causing any slowup in program_A
Is there a way to get VLC to log or something the reason it is closing/reloading in the case of program_B?

The only difference ffmpeg shows between program_A's VOB files and program_B's VOB files is that A uses pcm_s16be audio (on both its VOB files) and B uses ac3 audio on both its VOB files. Does ac3 need to close/reload between each use while pcm_s16be doesn't?

Must I transocde any multi-VOB program that uses ac3 to use instead pcm_s16be, to enable (near)seamless transitions?

Is something other than the choice of audio codec causing the difference?

[Jean-Baptiste Kempf]

Ok. So transition between ac3 (using liba52) is slower thatn transitions between pcm.
They are not decoded by the same module, which can explain the issue.

Could you give us the messages with verbosity set to 2 (High) of the transitions ?

[tmoran]

>Could you give us the messages with verbosity set to 2 (High) of the transitions ?
I tried
vlc --verbose 2 --logfile vlclog playlist.m3u
and let it play all the way through. But there is no "vlclog" on my machine and in fact no new file of any name in either the vlc directory or the directory containing playlist.m3u, and if I click on View Messages during playing it shows a screen with no messages in it. Where can I find the verbosity 2 output so I can send it to you?

[Jean-Baptiste Kempf]

Run vlc and use the message dialog.

[tmoran]

It's not clear to me where to send the log files so I put them on my web site
The show with fast transition, using pcm_s16be, generated
log file http://home.comcast.net/~tommoran4/log_never.txt
rrd output http://home.comcast.net/~tommoran4/rlog_never.txt
The show with a slow transition, that uses ac3, has
log file http://home.comcast.net/~tommoran4/log_cinema.txt
rrd output http://home.comcast.net/~tommoran4/rlog_cinema.txt

[tmoran]

> Could you give us the messages with verbosity set to 2 (High) of the transitions ?
So did that allow you to figure out the cause of the problem?