- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello
I've got a video sample from an AVCHDcamcorder. The file has been trimmed to remove some frames at the beginning. The H.264 stream startswith an I (non-IDR) frame.
The GOP for the resulting streamlooks like this: IBBPBB...
The resulting display order corresponding to the frames BBI...
Theproblem is that the first Bs cannot be decoded completlyastheyrefersprevious frames that have been trimmed from the file. My understanding is that the decoder could detect this situation as the first I-frame in the stream is not an IDR frame and is notable to decode the following B frames.
As an example, ffdshow detects this situation and skips the first two B fields, resulting in a cleaner output for the user.
See attached01_Trimmed.mtsas an example to reproduce the issue.
The problem exists both with h.264 decoder console sample and the h.264 video decoder.
Thanks for your time,
Pascal
H.264 starter
I've got a video sample from an AVCHDcamcorder. The file has been trimmed to remove some frames at the beginning. The H.264 stream startswith an I (non-IDR) frame.
The GOP for the resulting streamlooks like this: IBBPBB...
The resulting display order corresponding to the frames BBI...
Theproblem is that the first Bs cannot be decoded completlyastheyrefersprevious frames that have been trimmed from the file. My understanding is that the decoder could detect this situation as the first I-frame in the stream is not an IDR frame and is notable to decode the following B frames.
As an example, ffdshow detects this situation and skips the first two B fields, resulting in a cleaner output for the user.
See attached01_Trimmed.mtsas an example to reproduce the issue.
The problem exists both with h.264 decoder console sample and the h.264 video decoder.
Thanks for your time,
Pascal
H.264 starter
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pascal,
Which application in UMC sample did you test? For the attached stream, I checked with the latest IPP 6.1 update 6. The splitter does not be correctly initialized with the stream.
Thanks,
Chao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pascal,
Were you able to resolve this issue? I am having a similar problem when seeking through the AVCHD 1080i media. Since the first two B frames in this case should refer to the I frame before them (in the GOP), they should be decoded correctly, but they are not (I am using the 2.0 Media SDK). This makes it necessary for me to discard the first two frames in the GOP when seeking. This seems like a decoder initialization issue.
Steve
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page