Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove av1 obu parsing #265

Closed
wants to merge 2 commits into from
Closed

Conversation

jech
Copy link
Member

@jech jech commented Apr 15, 2024

  • Remove OBU parsing from AV1Packet
  • Remove codecs/av1/frame/av1.go

Remove OBU parsing from AV1Packet

In Pion, the Unmarshal operation is supposed to be
fast and perform no allocation, as it is sometimes used to check
just a single flag in the packet header. The AV1Packet
implementation breaks this property by parsing the whole list
of OBUs at Unmarshal time, even though it is likely to be unneeded.

We remove OBU parsing from Unmarshal, to make the method consistent
with the other implementations in Pion (for example, H264Packet
does not parse the list of NALs at Unmarshal time). We also remove the code in
codecs/frame, which depends on the OBU parsing.

If the code in codecs/frame is required, I volunteer to put it back in a way that
doesn't require parsing the whole list of OBUs at every call to Unmarshal.

In Pion, the (*XXXPacket).Unmarshal operation is supposed to be
fast and perform no allocation, as it is sometimes used to check
just a single flag in the packet header.  The AV1Packet
implementation breaks this property by parsing the whole list
of OBUs at Unmarshal time, even though it is likely to be unneeded.

We remove OBU parsing from Unmarshal, to make the method consistent
with the other implementations in Pion (for example, H264Packet
does not parse the list of NALs at Unmarshal time).  If OBU parsing
is required, it should be provided as a user-callable function
in codecs/av1/obu.
It used to depend on the now removed OBU parsing code.
@Sean-Der
Copy link
Member

Sorry about that @jech

Could we make it opt-out?

@jech
Copy link
Member Author

jech commented Apr 15, 2024

Could we make it opt-out?

Yes, that's what I'm suggesting. I suggest adding a new function:

func (p *AV1Packet) ParseOBUs() ([][]byte, error)

so that callers can opt-in simply by calling it. I volunteer to do that and, if required, to redo the removed frame code to use that function.

Do I have your agreement in principle?

@Sean-Der
Copy link
Member

What do you think of adding a NoParse member to AV1Packet ? Or something with different naming. It would be nice if we can avoid breaking the public API for existing users.

All the Unmarshal functions have the same problem. They keep getting expanded to add more functionality.

@jech
Copy link
Member Author

jech commented Apr 15, 2024

What do you think of adding a NoParse member to AV1Packet ?

It means that the default path is the inefficient behaviour, which has a bad smell. I'll do it, but only if you insist really strongly.

@jech
Copy link
Member Author

jech commented Apr 15, 2024

Please see #266. Please read the last paragraph of the PR description, and please consider removing the brain-damange altogether.

@Sean-Der
Copy link
Member

Replaced by #266

@Sean-Der Sean-Der closed this Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants