I'm doing an H264 encoding with timecode using Intel Media QSV encoder. The encoded file doesn`t show any timecode.
Funny thing is that I do the same thing using Intel Media Software encoder and everything is fine. Timecode is present when playing back the encoded file and all seems correct.
In the attached zipped folder there are print screens from the files bitstreams (from Elecard stream analyzer), as well as the log files from Intel Media SDK Tracer.
I can`t understand why timecode is present in Software encoding but absent in QSV encoding.
Does anyone have an idea on what could be the problem?
I`m using Intel Media SDK 2013 R2. Version of the driver is:22.214.171.12465
Overall, the SW and HW encoder does operate differently and thus, does not produce the exact same streams. This is expected.
The files you sent does not highlight any time code specifics. Can you expand a bit more on the time code your referring to, and it location in the generated stream?
Thanks for your previous answer.
I'm doing an encoding with SCTE128 timecode stored as picture timing.
Attached are two streams, one captured with the SW codec and the other with QSV. They represent each a GOP of 15 frames. You could notice that the one captured with the SW codec has picture timing and the other doesn`t.
it is the exact same code that is used in the two cases.
Is there any specific parameter to set in other to capture picture timing with QSV? Notice that I have the same bug with AVC HD timecode stored as SEI unregister. It works in SW but not in HW. However, Closed Captioning and AFD works fine in both cases: HW and SW.
Do you have any idea on what could be wrong?
that is quite strange. I can see the lack of "pic timing" in your HW encoded stream.
I performed a quick snapshot test by comparing SW encoder vs. HW encoder behavior. The generated streams both have "pic timing". I suspect there is something specific with your encoder configuration that causes this issue.
We will work on trying to replicate your specific config and behavior as soon as possible.
Can you also please share some details on what platform you are running your workload on? A 3rd or 4th generation Intel Core processor?
I have an update on my timecode bug.
For picture timing, if I insert two payload data in the mfxExtBuffer (instead of only one) in an interlaced resolution, it works for SW and QSV H264 encoder. I see the timecode in playback.
However, I still have a bug in progressive. I insert only one mfxExtBuffer and i don`t see any timecode in QSV. In SW it works.
Do you have any idea how to make timecode work in QSV progressive?
We realize, we need some more information to be able to debug this further.
Could you please provide full Media SDK tracer log including details for each encode call. You can do this by selecting the "Per-frame logging" box before capturing trace log. Also, if you can, please provide details about the custom SEI payload messages you insert.
Here are the tracer logs for two captured NTSC files.
The first one is with AVC HD timecode, encoded in the mfxPayload as unregistered user data type. Basically I insert two mxfPayload data in the mfxEncodeCtrl object which I send for encoding. This case works.
The second, which doesn't work is with SCTE128 picture timing. Here, I insert two mfxExtBuffer objects in the mfxEncodeCtrl sent for encoding. NumExtParam = 2 and ExtParam points to an array of two pointers that point each to one mfxEncodeCtrl object.
Note that the both cases work fine in SW.
Thanks for providing the specific use case details.
We have explored this further and it looks like for this specific use case there may be a bug in Media SDK. We are working on ways to resolve this. Thanks for helping us make Media SDK better.
Could you also please provide frame by frame trace log and output bistream for the progressive encode case?
we have investigated this issue further and have taken some actions.
- We found a bug in Media SDK causing incorrect PT SEI in stream. The fix will land in future release of Media SDK DLL, part of the graphics driver.
- As part of the investigation we also would like to clarify some current limitations.
1)Attaching per-field buffers to mfxEncodeCtrl is currently not supported. We will explore adding this feature for future version of the Media SDK API. We will enhance near term behavior by returning a returning a warning status code if 2 buffers of same type is attached.
2) Templates with mfxExtPictureTimingSEI. Only CtType is now supported. Other parameters should be configured by application. Media SDK will return warning if 0xffff is sent for any other parameter and write 0xffff values to bitstream "as is".
Thanks for helping us improve Intel Media SDK.