VLC and MTS playback issue

[JonVic]

Last night I was backing up a 32GB memory card from my Sony camcorder that is now full. I watched through a few videos (clicked the AVCHD folder and accessed the individual MTS video files) from it afterwards and noticed a strange issue.

I'm using a Mac laptop and if I use VLC Media player to play the files individually most of them play fine. However a couple of them have a 'glitch' not long after starting.

If I play the video it goes okay for a few seconds and then there is a significant skip or pause for about quarter/half a second. Once this has happened if I slide the playhead back on the video and start from the beginning it plays fine with no glitch. It seems to only do it when you have loaded the video 'fresh' in VLC. This glitch is always in the same place.

What is strange is if I play these files in Quicktime then there is no glitch. If I load them in to Premier Pro then there is no glitch when previewing the clip in the software or if I export the video re-encoded as another file format. If I load them on to a hard drive and play them on my Panasonic TV with built-in media player they also play fine.

It looks like this is just an issue in VLC and only on the initial playback. I find it strange though that it's only a couple of the videos on the memory card and the rest are fine. If it was glitching in a different place every time then I would put it down to glitchy playback on VLC and be fine with it, but it's the fact it is in the same place every time.

I guess if other software plays it fine and VLC itself can play it fine when you scrub back on the playhead to the start again then the file must be okay?

I have attached one of the videos, could someone tell me if there is any kind of problem with this clip technically or what may be the issue here? The glitch on this sample clip is at 4 seconds...

Thanks

00011.MTS

[Bernix]

Hi,
played in Win10 from HDD and no problem. But it start and 1 frame last longer. I think it is buffering video. It has bitrate about 3MB/s, so probably card or connection can be problem. Card are not as fast as SSD supposing. It seems to me, that the medium is not capable to provide enough data to player (on other hand if camcoder can write at this speed card should be readed faster), or you can try change buffer size in VLC itself.
26Mb/s is no problem for harddiscs, seems to me be not problem for your card also. But 50 progressive frames per second can be problem for your cpu. Once it is in memory, you have no problem, so Cpu can achieve this too. If you have it connected throught USB 1 you should see it very slow as the speed is 12Mb/s = cca 1,5MB/s. 2.0 and higher are much faster and cann't be problem. Or are you using Firewire? Also shouldn't be problem.


Try copy them to HDD on your comp, and tell us if there are still glitches. Or what your CPU specs is. If copied to your HDD and played o.k. you can eliminate potential problems Card and connection. If problem still, you know, the problem is your CPU or VLC settings. (I would check buffer size)


Bernix

[JonVic]

Thanks for your reply. If I copy the file to my hard drive it has the same problem. I have an SSD and the laptop is a MacBook pro so no issues with data to the player.

Processor is 2.7Ghz i7 - so pretty fast.

I can't find the settings to change CPU buffer in VLC...?

[JonVic]

I have found all the options under preferences in VLC now, but absolutely no idea where to start or what to change? Can't find anything that looks like it changes the CPU buffer.

[davexnet]

I noticed in VLC a slight pause at about the 5 second mark on the video you posted. This appears to be VLC's fault,
the frame size adjusts itself from 1920x1090 > 1920x1080 - why it does this I don't know.

You could try and capture some diagnostic messages, but you might be better off with another video player,
try mpc-hc or mpc-be.

To capture messages, load the video and immediately pause. Press CTRL-M and set verbosity to warning.
Close the dialog and resume playback. After the error, pause the video, open the message dialog again and see what it says.

[Bernix]

Hi,
was busy. It is in settings, inputs and codecs. You have to choose advanced on bottom. Default is 300 (ms) try set 1000 or more and you will see. I have not any glitch when played first time. Sorry my english is very poor and I have it in my native language. You will probably have here buffer file size. or something like this. Or something related to inner memory file size. But it should be called buffer on 99%



Bernix

[JonVic]

Thanks for the replies. Before I looked at the buffer or anything else I had read elsewhere that some people have had issues with the 'hardware decoding' check box under preferences/input codecs. I de-selected this check box, closed VLC and loaded the video 'fresh'. The glitch was gone! It appears that it is this option causing the problem.

Now, whilst I am happy that this seems to be the case I am concerned davexnet that you mention the video starts at 1920x1090 and then goes to 1920x1080. That seems bizarre.

I can't understand how a video could start playing at a non-standard resolution like that, how did you find this out? Was it using the VLC diagnostics?

[jagabo]

Pandy posted an ffprobe batch file that displays information about every frame of the video:
https://forum.videohelp.com/threads/390460-Ffmpeg-print-video-file-fps-every-sec#post2530898

The program shows all frames are 1920x1080, SAR 1:1, with a duration of 1800/90000 seconds (20 ms, 1/50 second).

ffprobe's csv file imported into a spreadsheet:


I don't see VLC changing the video frame size during playback, but if you have played the video before it asks if you want to start where you left off last time. This is done by inserting a ribbon between the menu bar and the video window. If you're looking at the bottom of the frame it looks like the frame is shrinking when that ribbon goes away (after 5 seconds, even if you pause the playback) and the video frame shifts up. This might explain a pause/jump on some computers when it plays the video.

[JonVic]

Thanks for the screengrab jagabo. Interesting information about the ribbon.

I suppose the remaining question I have is simply, is this clip okay? Is there anything unusual about it or problematic?

The stuff about the ribbon, is this to be expected with a clip like this? Has my camera done anything wrong?

[jagabo]

The ribbon has nothing to do with your video. It's a feature in VLC that allows you to resume playback where you left off last time. That's useful when you've watched half a movie and want to pick up where you left off. You can turn this feature off in the Preferences.

As far as I can tell there's nothing wrong with the clip. I've played it with several players and editors and found nothing wrong.

[JonVic]

That's great to know. Thanks very much for all your effort to help, and to everyone else who posted

I do wonder why 'hardware decoding' makes these particular clips stutter/pause then. I have looked through around 70 MTS files from three different cameras and not one of the clips stutters like this. It's only a selected few from this Sony.

I wonder what is so different about these clips and what makes them have this unique behaviour if nothing is technically 'wrong' with them. I tried the sample clip on another Macbook Pro today with 'hardware decoding' checked and it stuttered/paused the same.

I have established the pattern. The stutter occurs at 4 seconds. If I start the video and scrub back to the start before it goes over the bit that stutters then it will still stutter when it reaches the 4 second mark. if I play the video and allow it to stutter at the 4 second mark and then scrub back then no stutter. That is with 'hardware decoding' enabled. It's really really weird. What you mentioned about the ribbon seems to not be the issue though as I am starting the video fresh each time.

[davexnet]

Yes my mistake with the so-called resize, this must be the "jump" at 5 seconds as jagabo mentioned.
Looks like this "ribbon" at the top is part of the buffer as can be seen in this screen shot taken in the first few seconds

Except for a very slight pause before the video starts and this "jump" at 5 seconds I also don't see any issues.
I'm using motherboard video (very basic Radeon 3000) I don't think it even supports HW acceleration -
consequently I see ~30% CPU when your video is playing

[flashandpan007]

This is a *.MTS file, so it is from an AVCHD Camcorder of any kind. If I look at the pgs style I assume it is a Sony and then I looked in MediaInfo which states "Sony HDR-PJ410".

But is it the first file while you recorded this scene? Cams do filesplitting at 2GB, 4GB or whatever size, so I have to ask: Is this the full clip when you recorded or is there one or more files left before on the sd card. Since it is called 00011.MTS, I need to know if there is a 00009.MTS and a 00010.MTS on the sd card which were created during one recording. This is important to know.

[jagabo]

Except for a very slight pause before the video starts

I believe the cause of that is the 512 ms advance of the audio. Ie, the audio starts a half second before the video. Some players show garbage video during that half second. The OP could check other videos from the camera and if that is the differentiating factor for videos that don't play correctly in VLC. MediaInfo shows it in the audio section as a negative audio delay.

[JonVic]

Thanks for all the help guys, really appreciate it. I have spent some time tonight looking at the files on the card and I think I have discovered two things that shed some light on this issue.

As suggested by flashandpan007 I took a look at the files to see if any of them were split due to long recordings. It turns out that indeed four files were created by the camera automatically making a new file due to the length. The four files listed below are the files that have been started by the camera after the previous file reached it's maximum filesize for a single clip.

00002.MTS
00005.MTS
00006.MTS
00011.MTS

With 'hardware decoding' enabled it is only these four files that glitch/pause, when LOADED FRESH in to VLC. The rest of the files play with no glitch/pause regardless of if 'hardware decoding' is selected or not when loaded fresh. For some reason 00006.MTS glitches/pauses at 7 seconds, whereas the other three glitch/pause at 4 seconds.

So as far as the identifying which clips do it, I think it's clear that when loading them fresh in to VLC it is clips created by the camera after splitting that have this issue when 'hardware decoding' is selected.

Now, I also discovered another thing.

I have the 'continue playback' set to 'always'. For some reason some of the clips even when left to run for over 20 seconds will never automatically resume with this option enabled. Yet. some of the clips do. Very odd.

On the clips that do automatically resume I have noticed that EVERY CLIP will show this glitch/pause with 'hardware decoding' enabled when they resume and don't go from the start of the video!!!

It appears to me therefore that, in summary:

1. Split files where the start has been made by the camera react to 'hardware decoding' and glitch such as on the sample I posted initially. Always in the same place, every time (5-7 seconds after the video starts from the beginning).
2. Resuming ANY file (split or not) with 'hardware decoding' enabled creates this glitch and they will then glitch in the same place, every time (around5-7 seconds after starting the video, similar to when the split ones are loaded fresh).

I have written a lot and hopefully haven't lost you There is clearly something about these Sony files that VLC struggles with, both with split clips and with resuming any clip split or not.

Do I just have to say that there is inherently something different with these clips compared to all other .MTS files? I have some .MTS files made by a Panasonic camcorder and these have been split by that camera and absolutely no sign of these issues!

[jagabo]

If you look at the ffprobe results you'll see that the timestamps start at 640.86 seconds. Maybe that has something to do with it. What if you append all the segments that make up the one video? Does the whole thing play smoothly?

[JonVic]

I'm really sorry jagabo but i'm not entirely sure I understand about the timestamp. Could you explain a little more what this means? When you say append all the segments, do you mean create a single video with them? Sorry to seem thick, i'm no expert with all this stuff

[JonVic]

Just an additional finding with this I thought I would mention. I also have a Sony Cybershot stills camera that shoots video. I bought it at the same time as the camcorder we have been discussing to take mainly stills. I did shoot some video on this in AVCHD, so it also has created some .MTS files. I don't seem to have any videos that have been split by the camera that I can currently find. However, if I play any of the .MTS files shot on this Cybershot it too has the glitch/pause issue when resuming videos, exactly as above with the camcorder.

So, that's two Sony devices bought around the same time (2015). I have also just tested my old JVC camcorder and I have no split clips I can find but when I resume a file it does glitch/pause as well!

Weird thing is a selection of .MTS files from a 2010 Panasonic camcorder I have here don't do it.


This is clearly a widespread thing across different brands of camera - but not all of them!

[jagabo]

I suspect when VLC resizes the window to remove the resume message it takes too long on your computer and that causes playback to fall behind, causing a slight pause as player tries to resync the audio and video. The reason it doesn't happen with your old camcorder videos is because it shoots at a lower resolution and/or frame rate. It's hard for computer to keep up with 1920x1080 at 50 frames per second. 25 fps is much easier as the player has twice as much time between frames.

So it's a problem with VLC with high resolution high frame rate videos on your computer. Just disable the resume feature and the problem will go away.

[JonVic]

Thanks jagabo. I do agree that seems logical but I should have been clearer, but the video types are as follows:

Panasonic (old camera): 1080p 50p (No stutter on split files or resume playback)
JVC (old camera): 1080i (Stutter on resume playback but no split clip to test)
Sony Cybershot: 1080p 50p (Stutter on split clips and resume playback)
Sony Handycam (camera I supplied the sample from): 1080p 50p (Stutter on split clips and resume playback)

This is the crux of the issue for me. The old Panasonic shooting at 1080p 50p doesn't do it but the others do, even the JVC shooting at 1080i has the issue.

If the Panasonic had the issue then I would be fine that it was an issue with all .MTS files in VLC but clearly it can play them fine at 1080p 50p from the Panasonic. It's crazy confusing!

[jagabo]

The old Panasonic shooting at 1080p 50p doesn't do it

Maybe it uses a different codec or settings that are easier (faster) to decompress.

even the JVC shooting at 1080i has the issue.

1080i25 is deinterlaced to 1080p50 on playback.

[JonVic]

I see, so the Panasonic could be using different settings. That makes sense. I suppose being a 2010 model it stands to reason that it may well be less intensive than the 2015 models I have.

Only thing I am still not sure about is VLC is actually set to not de-interlace on my laptop. I have turned it off, so it will be playing back at interlaced. I should probably change that but surely the JVC not being de-interlaced would be okay? The JVC is from the same era (2010).

[flashandpan007]

Can I access the whole SD card folder, just to test a few things, maybe I can create "one scene files" for you which don't have problems.
If you don't want to upload it here, send a link to google drive or whatever per pm. I have a 2012 3MOS Panasonic and I am interested in that issue.

[JonVic]

I would love to share the card flashandpan007, unfortunately I have to go away today and i'm not going to have time to sort that out before I go. I'm due back home in 10 days so once I am back I will get it uploaded to Amazon Drive and share you in to a link to download. I will definitely do that. I will drop you a PM when it is done.

I have done a little further testing of footage because I managed to get my hands on a Sony RX100 MK4 and a Panasonic TZ100. Both of these record AVCHD .MTS files at 50p. I recorded some footage on both ensuring that the clips were long enough that the camera split them automatically.

I can confirm that the Sony RX100 MK4 has the same issue in that it stutters/jumps when you load a clip that has been started by the process of the camera splitting a file. Equally if I use the resume feature on the footage I get the same stutter/jump problem. As above this only happens when hardware decoding is selected.

The Panasonic TZ100 does not have this problem at all. I could not replicate it, so it appears that the issue isn't as simple as high resolution and high framerate. There must be something specific about certain types of .MTS files that causes this.

Anyway it was good to see this issue on a camera other than one I owned - bit of peace of mind! It's not just me!

Strangely I found a split clip from my old JVC camcorder and the 1080i .MTS files do stutter/jump using the resume feature but (from what I have seen so far) don't stutter when starting a clip that the camera has made as a result of splitting. Mileage really does vary with this!

I did discover some issues with micro stutter on the JVC 1080i footage, which I don't understand. It happens in Quicktime and VLC, but that's for another thread when I return from being away!

I will keep looking at this thread on my phone even though I am away, I just won't have access to many of the files until I get back.

Thanks guys, really do appreciate your help with all of this.

[JonVic]

One small thing to add I have just found out. As we had established the glitching on resuming videos only seemed to occur when 'hardware decoding' was enabled. I have come across a bit of a curve ball with that.

Only on the JVC 1080i footage it appears that with resume enabled and hardware decoding disabled about 1 in every 10 times i load the video and it resumes there is the glitch. That makes no sense as with everything else it seemed that hardware decoding was the culprit. The fact that the majority of resumes are fine I think indicates the 1080i clip is fine but it makes this issue even more odd and hard to diagnose.

You normally can establish a pattern with this sort of thing but this is just random and goes against the way everything else performs.

Certainly for me I will have resume off and hardware decoding disabled and hopefully with that combination not see this again.

[Bernix]

If this is problem of just and only of VLC, have you not any alternative on Mac? Because it seems it is related to only VLC, you can keep these files as backup without problem. I would look for different software player. On win there is wide choise, not know how on Mac. But if i were you i would try different player. Actually what you do is limiting you bit. HW decoding is very useful think and resume, not sure but can be good at some condition probably.

Edit - You can try Mplayer or MPV not sure, probably cli driven players but at least good rating.



Bernix

[JonVic]

Thanks Bernix, yes, it is related to mainly VLC, I think. I have seen a couple of jumps similar to this on Quicktime but they have been rare and could have been caused by other applications on the machine running. I would have to test more.

I guess the main crux of it is every clip I have tested at some point with one configuration or another has played fine, in VLC. So I would imagine there is nothing wrong with the actual footage, or at least I hope so! That's all I really care about.

By turning off hardware decoding and removing the resume function everything is fine, except for this pesky 1080i footage doing the jump every so often on resume without hardware decodig which is bonkers and don't understand why that happens. It goes against everything else the other videos do.

If I am going to sit down and watch this footage chances are I would watch it either edited in to a video on YouTube or similar. If I am going to watch the raw footage I would watch it through the media player on my HDTV. I have a Panasonic HDTV and when played from an external hard drive through the built-in media player things seem to play nicely and look a bit better!

I haven't got a windows machine but may have soon so I can wait to see if VLC running on that works better. I believe the test others did on here with my sample clip with Windows was okay.

[jagabo]

I agree with Bernix. Why do you keep going on and on about this? It's obviously a problem with VLC. Playing A/V files is very complex. Not every player plays all possible sources perfectly on every possible hardware/software configuration. Just turn off hardware decoding or change the "Continue Playback?" feature. It has three settings: Never, Ask, Always. Use Never or Always and your problem will go away. You may also be able to get around this by picking a different Output device in the video settings. On the Win7 computer I'm using right now there are 14 different video output "devices" -- and that's with just onboard graphics!

[JonVic]

I apologise to be seen as 'going on and on'. I thought this was the place for this kind of discussion and flashandpan had stated he was interested in it himself. I won't post anymore about this, but appreciate your help I will try the output device.

[flashandpan007]

I am still interested, because I think I can "repair" the files, just send me a link to the files per pm
I have a presumption, but need the files to test that.