H.264 - B-Frames cause hiccups, only with HW encoding

[Jack_Chimasera]

A very off thing that I've had with the H264 encoder : When encoding video using SW only (on an older Nahelem) the encoded file plays well. When encoding it using Hardware (on an SB), the playback order of the frames seems to be all wrong, causing hiccups.
This was experienced both with Intel's own decoder (inside my software) and an external decoder (VLC), and with the encoder both runnig in my own application, or in sample_encode.
I doubt something like that could have slipped by everyone by now, or could it ?

I'm using version 3.0 beta 2

[Nina_K_Intel]

Hi Jack,

What is the version of the SNB graphics driver that you are using? Could you try updating the driver and trying again?

Thanks,

Nina

[Jack_Chimasera]

Hello Nina
I've updated the graphics driver for the Sandy Bridge, per your recommendation. However, this did not solve the issue. The driver I have installed is version 15.22.1.64.2361 for Windows 7 64bit (Home Premium). The software is 32bit at the moment (yes, running on a 64-bit platform, this could be changed if it's the cause). Any other ideas ?

regards

Jack Chimasera

[Nina_K_Intel]

Hi Jack,

Thanks for trying. No other ideas at the moment, let me just check the issue at my side. Could you give me the command line you are using for sample_encode? The YUV input is nothing special, right? And I assume no modifications to the sample_encode source code?

Thnx,

Nina

[Jack_Chimasera]

Hello Nina
The file is a plain vanilla YUV file, generated using sample_decode from a progressive-scan PAL video I have here (8 seconds long, 200 frames).
The commandline used, and output produced follow. The sample_encode binary wasn't compiled here, but rather, is the one provided in the SDK's installation package. I have tested with the 64 bit binary from the installation package, and the same issue was demonstrated.

regards

Jack Chimasera

C:\Program Files\Intel\Media SDK\3.0.332.30303 Beta2\bin\win32>sample_encode.exe
h264 -hw -u quality -i \media\burger8.yuv -o \media\burger8.m2v -w 720 -h 576
Intel Media SDK Encoding Sample Version 3.0.332.30303

Input file format YUV420
Output video AVC
Source picture:
Resolution 720x576
Crop X,Y,W,H 0,0,720,576
Destination picture:
Resolution 720x576
Crop X,Y,W,H 0,0,720,576
Frame rate 30.00
Bit rate(Kbps) 4000
Target usage quality
Memory type system
Media SDK impl hw
Media SDK version 1.1

Processing started
Frame number: 199
Processing finished
Frame number: 0
C:\Program Files\Intel\Media SDK\3.0.332.30303 Beta2\bin\win32>\media\burger8.h2
64

[Nina_K_Intel]

Thanks, got it. Will investigate and get back with results.

Nina

[Nina_K_Intel]

Hello Jack,

I couldn't reproduce the issue though tried on various YUV sources with the exact same versions of driver and app. I wonder if your YUV is something special, could you check it with some YUV viewer? Could it happen that you modified the sample_decode before decoding your original stream into a YUV file and it had the wrong number of frames as a result? Smth like changing DecodedOrder to 1?

Could you try on some other YUV sources and/or share your YUV with us?

Thanks,

Nina

[Jack_Chimasera]

Hello Nina
The decoder hasn't been modified, and the YUV file is unmodified.
I'd happily share both the YUV soruce and the encoded H264 file with you, what's your preferred mode of sharing such media ?

regards

Jack

P.S. sorry for the delays, the forum doesn't send me E-mail updates for this thread.

[Nina_K_Intel]

Hello Jack,

Please try this:

- ftp.intel.com

- enter 'anonymous' (no quotes of course) as login

- for password enter your email address

- Don't forget: enter 'bin' to go to binary mode

- cd /pub/incoming

- Files are hidden (not visible), so I'll need the _exact_ file name(s)

(Note: don't use underscores in file names)

- Files names are case sensitive. So abc.txt, Abc.txt and ABC.txt are three different file names.

- Files will remain on ftp server for 24 hours and are then deleted automatically

Thanks!

Nina

[Nina_K_Intel · Accepted solution]

Jack,

Btw, are you aware that the output of sample_encode is an elementary video stream? So you need a capable player, VLC is not reliable for such streams. Could you give the stream a quick check using sample_decode with -r option? (it uses the simplest rendering model but should be good enough to check frame order correctness). Elecard tools are also suitable for viewing elementary h264 streams.

Thanks,

Nina

[Nina_K_Intel]

Hi Jack,

I got your files, thanks. Viewing them (*.h264 as well as *.m2v) in Windows Media Player (Win7) and Elecard Stream Eye I don't see any hiccups.

Can you tell which version of VLC you use when you see hiccups? I remember they had a bug with B frames for h264 playback in one of the older versions. But the current version 1.1.9 refuses to play elementary H264 streams at all. So I suggest you use other tools I mentioned.

Nina

[Jack_Chimasera]

Hello Nina
Firstly, let's discard of the M2V file, it was present only for reference purposes. It wasn't encoded with Intel's encoder, instead it was the source of the YUV, before decoding it.
Playing the H264 file in windows media player WITHOUT Elecard's software installed, the hiccups were omnipresent (using Microsoft's own decoder, under Graphedit as well).
When played inside StreamEye, indeed the playback was properly smooth, which leads me to thinking that some flag is ambiguously set, making some decoders play the file in Stream-Order instead of Display-Order.
VLC 1.1.10 does not refuse to play this file, if it is fed the file directly (open VLC< open file, type the file's name), and it stutters.
Worse, using your own decoder (Intel Media SDK) into a YUV file, and viewing that file stutters in exactly the same fashion as VLC and Microsoft's decoder do...

regards

Jack Chimasera

[Nina_K_Intel]

Hi Jack,

I have made a set of experiments at my side and I would still stick to the theory that the bug is in VLC and not in the MSDK encoder.

First of all, you reported that a stream encoded with a SW encoder is played back with correct order and only hw encoded stream stutters. I repeated you experiment and encoded a sw.h264 with Media SDK 3.0 Beta2 sw dll and a hw.h264 using the hw dll from SNB driver 2361. Used burger8.yuv as a source (though the source doesn't really matter). Then I tried to playback both files with different players.

The results are:

1) VLC: plays sw.h264 with stutter, doesn't play hw.h264 due to not found start code as the file starts with AUD - I learnt that from vlc messages log. I suppose both issues are problems of VLC player. Absolutely same behavior with other elementary h264 streams including our test streams from conformance pool and your burger8.m2v. Streams starting with SPS header and having B frames played with stutter, streams starting with AUD not played.

When the file which stutters is muxed into mp4 it is played correctly by VLC.

2) Reference AVC decoder software JM version 17.2 (http://iphome.hhi.de/suehring/tml/) decodes both files correctly

3) DShow Microsoft DTV-DVD Video Decoder plays both correctly

4) MSDK sample_decode and MSDK DShow h.264 decoder filter play both files correclty. I'm not sure why you have the same problem with you software which uses MSDK decoder as VLC has. Maybe check the DecodedOrder setting of MSDK decoder in your code?

I really hope we can figure out these isses finally. Please try out some of the players I mentioned and let me know how it works at your side. Actually, the reference decoder should be the main criteria for such controversy.

Best regards,

Nina

[Jack_Chimasera]

Indeed, it plays well with the sample_decoder. Now I'll try to figure out why I have these stutters with my code (which uses the SDK's decoder as well).

EDIT : There was a mistake in my implementation of the encoder frame-feeding mechanism. That in conjunction with the incompatibility of the intel H264 encoder with VLC threw me off-course, sorry.

[Nina_K_Intel]

Hi Jack,

Good to hear that the issue is solved.

Good luck with further development.

Nina