If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Status

()

Core
Audio/Video: Playback
P3
normal
RESOLVED WONTFIX
10 months ago
4 months ago

People

(Reporter: alwu, Assigned: alwu)

Tracking

Other Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment, 1 obsolete attachment)

We need to parse the h264 slice header, and then we can fill related information into DXVA2's slice control data structure.
Depends on: 1309163, 1321164
Comment hidden (mozreview-request)
The slice header is in the bits stream, and the bit stream has two formats (AnnexB/AVCC). It's easy to parse the NAL from the AVCC because we can know the NAL size from extra data.

In Windows, the MediaDataDecoder would get the AnnexB bits stream which was transformed by H264Converter, but AnnexB is difficult to parse because we don't know the NAL size and need to traverse every bits.

And I don't want to do the extra transformation just for parsing the slice more easily 
> AVCC -> AnnexB -> AVCC (parsing slice) -> AnnexB (DXVA requirement)

Therefore, I'm thinking about to create an new PDM which DecoderNeedsConversion() returns kNeedAVCC, but do the AnnexB conversion inside the MediaDataDecoder(or lower level module) instead of H264Converter.

---

Hi, Jya,
How do you think? Could you give me some suggestion?
Thanks!
Flags: needinfo?(jyavenard)
(In reply to Alastor Wu [:alwu] from comment #2)
> The slice header is in the bits stream, and the bit stream has two formats
> (AnnexB/AVCC). It's easy to parse the NAL from the AVCC because we can know
> the NAL size from extra data.
> ...
> Hi, Jya,
> How do you think? Could you give me some suggestion?
> Thanks!

We already are doing the conversion to parse the PPS and the SPS.
Converting from AnnexB to AVCC is pretty cheap, and that's how most decoder works anyway. Working with AnnexB is hard and inconvenient.

So what you could do is make your DXVA MediaDataDecoder request AVCC data, so that the H264Converter doesn't perform the conversion for you.

Perform all the parsings you need to do, and only when you go about feeding data to the dxva decoder will you convert to AnnexB.

That way you only ever perform a single AVCC->AnnexB conversion
Flags: needinfo?(jyavenard)
Blocks: 1322571
Priority: -- → P3
Comment hidden (mozreview-request)

Comment 5

9 months ago
mozreview-review
Comment on attachment 8817252 [details]
Bug 1319734 - parse h264 slice header.

https://reviewboard.mozilla.org/r/97620/#review102000

::: media/libstagefright/binding/H264.cpp:910
(Diff revision 2)
> +    return false;
> +  }
> +
> +  MOZ_ASSERT(aSample->Data());
> +  const int nalLenSize = ((*aSample->mExtraData)[4] & 3) + 1;
> +  BitReader br(aSample->Data(), aSample->Size());

BitReader has been changed, it takes the number of bits now. there is a utility to determine those now check the sps and pps parser

::: media/libstagefright/binding/H264.cpp:912
(Diff revision 2)
> +
> +  MOZ_ASSERT(aSample->Data());
> +  const int nalLenSize = ((*aSample->mExtraData)[4] & 3) + 1;
> +  BitReader br(aSample->Data(), aSample->Size());
> +
> +  aDest.first_mb_in_slice = br.ReadUE();

Check the new macro to verify that the value is valid and thst you wont overflow the destination variable
Thanks for reminding, I'll update my code when it's ready to be reviewed.
Now I'm just trying whether this parser is good enough for DXVA2 API decoding.
Comment hidden (mozreview-request)
Because the h264 decoding might be involved in patent issue, I'll stop developing it.
Just uploaded some WIP if we need it again someday .
Attachment #8817252 - Attachment is obsolete: true
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.