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
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 188.8.131.52.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 ?
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.
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
Crop X,Y,W,H 0,0,720,576
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
Frame number: 199
Frame number: 0
C:\Program Files\Intel\Media SDK\3.0.332.30303 Beta2\bin\win32>\media\burger8.h2
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 ?
P.S. sorry for the delays, the forum doesn't send me E-mail updates for this thread.
- 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
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.
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...
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.