Video encoded with VP9 codec is unplayable

I'm using VLC for iOS 2.7.4.

I found that many videos encoded with VP9 codec can't be played using VLC. Instead of the video, I only see some garbage, but the sound plays fine.

Here is an example video that demonstrates the problem. This video can be played fine using VLC for desktop, yet VLC for iOS doesn't seem to handle it. This video was created using the following command:

ffmpeg -i source.mkv -vf scale=640:-1 -c:v vp9 -b:v 2048k -map v example.mkv

What's your iOS device?

nvm, wow, that's impressive :D

changed title from iOS: video encoded with VP9 codec is unplayable to Video encoded with VP9 codec is unplayable

OK, that's a cross-platform VLC 3.0 regression

added Component::Decoders + 1 deleted label

changed milestone to %3.0 FF

Expected output: http://files.feepk.net//3254zkb Actual output: http://files.feepk.net//7SkWJPH

The problem is in our avcodec module, the vpx module works as expected.

commit f116ca5e fixes a NULL dereference in the vpx module that was crashing with the given sample.

commit 0bceaf96 prioritizes the vpx decoder over the avcodec decoder.

Replying to [comment:6 tmatth]:

commit f116ca5e fixes a NULL dereference in the vpx module that was crashing with the given sample.

commit 0bceaf96 prioritizes the vpx decoder over the avcodec decoder.

I may miss something but I'd like to add that Ronald Bultje, one of the authors of libvpx iirc, wrote the vp9 decoder in libavcodec specifically to be significantly faster than libvpx, so at least on mobile devices, prioritizing libvpx sounds like a bad idea.

Works fine here with --demux=ffmpeg The issue may be related to the fact that older libvpx by default creates no second I frame and that seeking without I frames is impossible in vp* (contrary to mpeg streams).

Replying to [comment:7 cehoyos]:

Replying to [comment:6 tmatth]:

commit f116ca5e fixes a NULL dereference in the vpx module that was crashing with the given sample.

commit 0bceaf96 prioritizes the vpx decoder over the avcodec decoder.

I may miss something but I'd like to add that Ronald Bultje, one of the authors of libvpx iirc, wrote the vp9 decoder in libavcodec specifically to be significantly faster than libvpx, so at least on mobile devices, prioritizing libvpx sounds like a bad idea.

Works fine here with --demux=ffmpeg The issue may be related to the fact that older libvpx by default creates no second I frame and that seeking without I frames is impossible in vp* (contrary to mpeg streams).

This a demuxer independent issue AFAICT, so I wouldn't expect --demux=ffmpeg to change anything. I think the bug is present with newer libavcodec (i.e. I can reproduce it with contrib but not my system's older libavcodec) but I haven't figured out when this behaviour started.

Replying to [comment:8 tmatth]:

Replying to [comment:7 cehoyos]:

Works fine here with --demux=ffmpeg This a demuxer independent issue AFAICT, so I wouldn't expect --demux=ffmpeg to change anything. I am not sure I understand: Do you mean you tested the sample with vlc --demuxer=ffmpeg and it was not played correctly, just as if you had not used any additional option?

Replying to [comment:9 cehoyos]:

Replying to [comment:8 tmatth]:

Replying to [comment:7 cehoyos]:

Works fine here with --demux=ffmpeg This a demuxer independent issue AFAICT, so I wouldn't expect --demux=ffmpeg to change anything. I am not sure I understand: Do you mean you tested the sample with vlc --demuxer=ffmpeg and it was not played correctly, just as if you had not used any additional option?

I'm talking about current master, to see the bug you need to force avcodec, i.e. ./vlc --codec avcodec example.mkv vs. ./vlc example.mkv

You also need a recent enough libavcodec for the bug to manifest. It doesn't matter what demuxer you are using (i.e. our matroska demux vs. libavformat), the bug is in decoding.

Replying to [comment:10 tmatth]:

I'm talking about current master, to see the bug you need to force avcodec, i.e. ./vlc --codec avcodec example.mkv

And is the issue also reproducible with ./vlc --codec=ffmpeg --demux=ffmpeg example.mkv?

assigned to @tmatth

It seems that when using ffmpeg's libavcodec, we are using our own packetizer/avparser instead of the copy packetizer. However, when using libav's libavcodec, we are using the copy packetizer.

actually it's an issue in libav's lavc. If there is a superframe, avcodec_decode_video2 doesn't returned the size used but the size of the packet minus the size used.

https://lists.libav.org/pipermail/libav-devel/2016-June/077240.html

added Status::not VLC label

closed