Log in

View Full Version : Curious issue with b-references in Elemental

Blue_MiSfit
5th June 2015, 19:13
Hello folks!

Gosh, it's been awhile since I've posted...

In any case, I've been using lots of commercial encoders these days in my professional life, for a variety of reasons. One of these encoders is Elemental - specifically their Elemental Live product that takes live inputs from HD-SDI, MPEG-TS over IP, RTMP etc and generates one or more GOP aligned outputs packaged in one or more ways.

Elemental has been continually developing their product, and they recently added support for reference B-Frames. This seems to work fine almost everywhere, including hardware decoders on iOS devices, and LAV decoding in MPC-HC. However, VLC shows strange block artifacts on decode!

I'm wondering if one of the clever folks here with stream analysis tools could give me any insight as to why this is happening? Here's a short test clip using Big Buck Bunny - Sunflower in 720p59.94 at 2 Mbps.

http://www.mediafire.com/watch/s76856vq2jnx7i5/test_bref.mp4

For those familiar with Elemental, this stream was encoded with their GPU encoder.
sneaker_ger
5th June 2015, 19:22
LAV decoding in MPC-HC
LAV software has same problem. (I.e. ffmpeg)
videoh
5th June 2015, 20:19
Looks OK with DGDecNV. ;)
nevcairiel
5th June 2015, 21:31
All Hardware Decoders in LAV or otherwise seem to handle it fine, so the bitstream seems alright.
I would recommend to simply report it as a bug to ffmpeg, H264 corruption bugs are usually fixed rather quickly (http://ffmpeg.org/bugreports.html)
Blue_MiSfit
5th June 2015, 23:09
Ah! I see the same issue! I thought my LAV was set to software but it was set to cuvid :)

I'll whine at the ffmpeg guys.
Blue_MiSfit
5th June 2015, 23:45
Also verified that latest ffplay exhibits the same issue.

Ticket created with ffmpeg trac

https://trac.ffmpeg.org/ticket/4596
benwaggoner
6th June 2015, 18:53
You should probably report to Elemental as well. They have some of the best support in the business.
Blue_MiSfit
6th June 2015, 20:03
That's the first thing I did, Ben :)

Their support really is first class.
nevcairiel
9th June 2015, 11:32
The issue was fixed in ffmpeg this morning, and will be in the next LAV nightly build. Now only a question of VLC updating their ffmpeg eventually.
Blue_MiSfit
9th June 2015, 17:14
I saw the same thing. Does VLC lag behind, generally speaking?

Tried with ffplay built today but still no-go. I'm guessing the build was made before the fix was implemented. I'll try again tomorrow.
benwaggoner
12th June 2015, 00:02
The issue was fixed in ffmpeg this morning, and will be in the next LAV nightly build. Now only a question of VLC updating their ffmpeg eventually.
What was the bug?
nevcairiel
12th June 2015, 00:15
What was the bug?

The SSSE3 optimized bi-weighting code didn't properly handle a corner case in the weightings. The code in question was from like 2010, surprising that never occurred before.
Blue_MiSfit
12th June 2015, 06:33
Verified latest ffplay can decode this sample perfectly.