The VideoLAN Forums

No matter what I try, I can't get VLC (3.0.8 64bit) to output a decent video file.
I have 2 clips, both exactly 5 seconds long, I'm just trying to merge them together as an experiment.
Ultimately I want to output directly to a rtmp stream, but in testing I'm simply muxing it into a file to see if it plays correctly.

Here's an example command: But no matter what, the resulting file doesn't play correctly in any video player. If I play the output in VLC, after the first few seconds it's as if the end of the second clip glitches into the end of the first clip. The resulting clip is 6 seconds long.
Mediainfo thinks the 10 second clip is 5 seconds long.
MPV almost plays correctly, but the seekbar goes back to the beginning at the start of the second clip and there are some audio sync issues.
I've tried different files, I get the same result.
VLC seems to be doing something that corrupts the video data.

I've also tried outputting directly to an rtmp server and it stops playing after the first clip.

Hi,

vlc.exe --no-repeat --no-loop -I rc -vv --no-lua "G:\Try\1.mkv" "G:\Try\2.mkv" vlc://quit --sout=#gather:file{mux=mkv,dst="G:\Try\3.mkv"} --sout-keep

Many VLC bugs! Time index, EOF, fps, duration,...

Try in three command lines:

vlc.exe --no-repeat --no-loop -I rc -vv --no-lua "G:\Try\1.mkv" :sout=#transcode{vcodec=h264,acodec=mp4a}:file{mux=mp4,dst="G:\Try\1.mp4"}

vlc.exe --no-repeat --no-loop -I rc -vv --no-lua "G:\Try\2.mkv" :sout=#transcode{vcodec=h264,acodec=mp4a}:file{mux=mp4,dst="G:\Try\2.mp4"}

vlc.exe --no-repeat --no-loop -I rc -vv --no-lua "G:\Try\1.mp4" "G:\Try\2.mp4" vlc://quit --sout=#gather:file{mux=mp4,dst="G:\Try\3.mp4"} --sout-keep

It's better.

Try in one command line:

vlc.exe --no-repeat --no-loop -I rc -vv --no-lua "G:\Try\1.mkv" "G:\Try\2.mkv" vlc://quit --sout=#transcode{vcodec=h264,acodec=mp4a}:gather:file{mux=mp4,dst="G:\Try\3.mp4"} --sout-keep

It's good, with habituals warnings: missing pictures, wrong fps,...
Control always the warnings in the Log file.

Good luck with your other settings!

Ed

Thanks for replying.
Your last command works a lot better than mine.
I've incorporated into it my transcode settings:

"C:\Program Files\VideoLAN\VLC\vlc.exe" --no-repeat --no-loop --no-lua playlist.m3u vlc://quit --sout=#transcode{vcodec=h264,venc=x264{profile=main,level=30,keyint=25,min-keyint=25,opengop=false},vfilter=canvas{width=1280,height=720,aspect=16:9},scale=1,fps=25,vb=5000,acodec=mp4a,ab=160,channels=2,samplerate=44100}:gather:file{mux=mp4,dst="out.mp4"} --sout-keep

Unfortunately it's still not very robust. The merging of 2 files works a lot better, Mediainfo detects the correct duration, but if I seek during encoding it messes it all up. Prone to getting a frozen image, sound out of sync... Just totally goes wrong
The same is true if VLC is given a slightly wonky video file as an input, a partially downloaded mkv for instance, with the end missing. If anything's slightly off it's prone to freezing and/or going out of sync.

[EDIT]

Hmm, might have been lucky with the first few tests - this seems just about as buggy as my command. Often video freezes at the end of the first file in the playlist while the audio continues to play.

Questions:

About the warnings, did you keep -I rc -vv in your command lines?

About the main resources, did you consult the task manager during VLC running? Processors, memory, disk?

About the command, why do you give these parameters for venc?

Ed

1: Here's a log for when I tried encoding a playlist of videos, all exported from Adobe Media Encoder so presumably 'good' video files:

[url]https://gist.github.com/hedgehog90/af4c69c464efff33cda0e7972ffa0c77[/url]

(The command I used is first 3 lines of gist)

2: I haven't consulted Task Manager. My system is pretty powerful, a lack of resources is certainly not an issue.

3: Is there something wrong with these parameters? I've tried removing them but I'm still left with a badly encoded video.

Ok, looking at the log closely I've noticed this line cropping up whenever it goes wrong:

[00000240478fc6d0] main mux error: cannot add a new stream (unsupported while muxing to this format). You can try increasing sout-mux-caching value

And this tends to appear when a file of different dimensions to the last is played.

And then I outputted these files singularly with the same VLC transcoding parameters and found they were only changing the height and width in the metadata so they played as 1280x720 in any video player, but the video data was still in fact the original width and height...

But then I tried adding width and height explicitly to the transcode params but I'm still encountering an error.
Now when I output each file singularly with explicit width/height params, they have 100% matching mediainfos - frame rate, dimensions, color space - if I then try to merge them in VLC I don't get any errors, but the resulting video has audio sync issues...

Conclusion: Even if the files are the same width/height, frame rate etc. I still get really bad audio sync issues.
After so much tinkering I'm really doubtful this is resolvable using VLC.

Hooray! I think I've finally got this working.

Here's what I'm doing now:

vlc playlist.m3u vlc://quit --sout "#std{access=file,mux=ts,dst=-}" --ignore-config | ffmpeg -i - -c:v libx264 -preset ultrafast -crf 20 -c:a aac -b:a 160k -ac 2 -ar 44100 -profile:v main -level:v 4.0 -f flv out.mkv

Or for streaming directly to an rtmp server:

vlc -vv playlist.m3u vlc://quit --sout "#std{access=file,mux=ts,dst=-}" --ignore-config | ffmpeg -re -i - -c:v libx264 -preset ultrafast -crf 20 -c:a aac -b:a 160k -ac 2 -ar 44100 -profile:v main -level:v 4.0 -f flv rtmp://url

I haven't seen anyone else try this, I was amazed it worked to be honest.
So I'm just piping out the raw VLC decoded output and encoding through ffmpeg. No need for --sout-keep or gather.
When there is a bit of discontinuity (ie, playing a new video) ffmpeg handles it well, I get a few errors but I don't notice any sync issues in the resulting output:

[aac @ 0xe4f74265240] Number of bands (65) exceeds limit (49).
Error while decoding stream #0:1: Invalid data found when processing input
[aac @ 0xe4f74265240] channel element 0.0 is not allocated
Error while decoding stream #0:1: Invalid data found when processing input

And maybe I drop a frame in the process, but that's it.

Seeking is a bit risky, it's still prone to going out of sync but only on a few occasions. In case that happens I guess I just have to stop/start the stream.

Otherwise, I'm pretty happy with these results.
If someone can see some way of improving upon it please let me know.

After a bit more testing I realised my above solution didn't work for files with different frame rates, so here's this:

vlc -vv 1.mp4 input.mkv --sout "#transcode{vcodec=H264,venc{profile=veryfast,level=40},vfilter=canvas{width=1280,height=720,aspect=16:9},width=1280,height=720,fps=25,vb=1000,acodec=aac,ab=160,channels=2,samplerate=44100}:std{access=file,mux=ts,dst=-}" --ignore-config | ffmpeg -i - -c copy -f flv -y out.flv

Now I use VLC to transcode the video to make a stream with a constant framerate. Still need to pipe it into FFMPEG if you want a playable file.

Hello

My feelings about gather.

Apparently, the gather module was made by a beginner-developer for the simple case; consequently, at the first peculiarity, it's the VLC bug!
The main peculiarities are: incompability between gather and other VLC parameters; fps always wrong after a VLC command line; missing, empty or absolute black image; audio desynchronized at the start, audio of absolute silence, ...

With gather, I created over a hundred command lines, always on the same principle: an introductory sequence, one or more sequences (taken from a single video) for the main video and an ending sequence.
ALL of these command lines produces good results, but at the cost of multiple programming tips and tricks!
The big advantage is the absence of new encoding.

For more complex cases, I use VSDC (freeware release); it is the "universal glue" with precise video cutting! With many special effects that work perfectly: transition, blue screen, ...
The big advantage is the perfect precision of all orders; the downside is the new encoding.

Good luck with your video concatenations!

Ed.