The VideoLAN Forums

..it seems that 2.2.4 *can* play it though.

So it looks like something has regressed.

The file was produced by ffmpeg from a raw USB capture and encoded using NVIDIA NVENC HEVC.

Audio comes through fine, but nothing gets decoded - in VLC codec info it shows zero for decoded blocks etc.

https://www.dropbox.com/s/c0rwtckyo6430 ... 4p.ts?dl=0

avplay (like VLC) complains the file is HEVC video track is invalid... So maybe, just maybe, it actually is invalid?

In any case, this seems like something between the file and libavcodec, rather than VLC.

If it was invalid, why would mpv and VLC 2.2.4 play it ok then?

Because they were implemented differently? I don't know but that seems obvious.

Interestingly, ffplay from latest git has no problem playing it either.

Here is another file it has problems with. Different encoder (x265 this time) same container TS.

https://www.dropbox.com/s/ncneps7j83rxr ... ff.ts?dl=0

This one is yuv422p instead. Same issue again, plays fine in mpv and ffplay, but VLC outputs audio only.

Also, there is a second unrelated problem with this one. It's encoded using x265's interlaced encoding. With mpv and ffplay it's necessary to tell it that it's in TFF format, otherwise they assume something different and doesn't deinterlace properly. I'm not sure whether that's a fault with x265 or just that none of the players have figured out to deal with the field order for interlaced hevc yet.

But for example to play this file back correctly in ffplay, you have to choose ffplay -vf yadif=1:0:0.

Unfortunately, VLC doesn't provide a similar option. Which was why this bug was logged many years ago: https://trac.videolan.org/vlc/ticket/10191

VLC needs this option! I hacked around it for now by forcing the top_field_first to true in modules/deinterlace.c and confirmed (with a yuv420p file) that it fixes it.

Finally, just to rule out the container format as the source of the problem I can confirm that if I repeat the first capture (yuv444p using NVENC) but output as an mp4 it exhibits the same problem.

I did not state that the file was invalid. I stated that was one possible explanation.

What I do see, is that avplay exhibits the same failures as VLC. So, if it is not a problem with the file, it is most certainly a problem in libavcodec. And then, you would be on the wrong forum.

Ok thanks. I'll take my problems elsewhere!

By the way, I thought I might be able to just build VLC against the ffmpeg git clone instead by editing the top of "rules.mak" in vlc/contrib/src/ffmpeg/ where there is a comment letting you choose between libav and ffmpeg but alas this is broken functionality and configure complains about some of the options not being valid such as --disable-swresample and others, so I gave up.

So it turns out that if I build vlc 3.0.0 git against ffmpeg instead of libav then it all works fine (the functionality isn't broken at all - I was the broken one, I just needed to do a cleaner build. Sorry!)

It would appear that libav doesn't support yuv422 or yuv444? Does that sound correct? The messages that avprobe outputs from my files is that the chroma for both the 422 and 444 files is invalid.

Which begs the question why is VLC building by default against a library that is so limited? Also, is that something new for vlc 3.0 - because vlc 2.2.4 doesn't have this problem. Does that mean that vlc 2.2.4 is built against ffmpeg too, at least for Windows?

Anyway, I hope this helps anyone else wondering why vlc 3.0.0 isn't dealing with non 420 chroma.

FFmpeg does not support hardware decoding acceleration properly. So it is not really an option for a media player.