Skip to content
New issue

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

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

Already on GitHub? # to your account

Add support for MPEG-4 Part 2 video codec (ISO 14496-2). #296

Merged
merged 1 commit into from
Jun 9, 2021

Conversation

dreamaniajp
Copy link
Contributor

Hi, This PR tries to fix the MP4V (ISO 14496-2) support.

Could you help to review it?
Many thanks!

@baumanj
Copy link
Contributor

baumanj commented Apr 12, 2021

Thanks for the submission. Just to let you know, I'm not going to be able to start reviewing this until next week (Apr 19) at the earliest, but I'll definitely get to it as soon as I can.

@baumanj baumanj self-assigned this Apr 19, 2021
@baumanj
Copy link
Contributor

baumanj commented Apr 20, 2021

I've started looking at this, but I'm not going to be finished until later this week.

One thing that would help is to know what your desired use case for the code is. Are you looking to consume video/mp4v-es content via the mp4parse crate, or are you hoping to integrate it with some gecko-derived codebase? Something else?

@dreamaniajp
Copy link
Contributor Author

I've started looking at this, but I'm not going to be finished until later this week.

One thing that would help is to know what your desired use case for the code is. Are you looking to consume video/mp4v-es content via the mp4parse crate, or are you hoping to integrate it with some gecko-derived codebase? Something else?

Hi,
I would like to integrate it with some gecko-derived codebase and would like to keep following/merging newer gecko-dev version in the future.
So it will be helpful if the video/mp4v-es support could be added into Gecko code base by some kind of feature flag control.

Many thanks.

@baumanj
Copy link
Contributor

baumanj commented Apr 28, 2021

It's going to take me a little while to get to this yet. Just wanted to let you know I haven't forgotten.

@dreamaniajp
Copy link
Contributor Author

It's going to take me a little while to get to this yet. Just wanted to let you know I haven't forgotten.

Thanks @baumanj !

@dreamaniajp
Copy link
Contributor Author

Hi @baumanj ,

Sorry for bothering you.
If possible, could you help to have a look at this PR?

Thanks a lot!

@baumanj
Copy link
Contributor

baumanj commented Jun 1, 2021

Hey @dreamaniajp. Apologies for the delay, but this is a critical time for my main work. It would be easier to approve this PR if it were written in a way that doesn't affect the existing functionality when the "mp4v" feature isn't enabled. I understand that may be inconvenient, but since the way it's written now will potentially change the way the code behaves in Firefox, when the feature is not enabled, I need to review it more thoroughly before we can accept it.

The current patch needs to have conflicts resolved (and probably be rebased). I'd suggest doing that and seeing if it's possible to write your change in a way that doesn't modify the existing functionality. We definitely want this crate to useful for purposes other than Firefox, but in terms of resource allocation, we have to prioritize that use case. If this is the approach you feel makes most sense, perhaps you can use a fork for the time being until I have the opportunity to give this the review it needs. I want to set clear expectations and let you know that it'll still be at least a little while until I can look at this closely enough to determine whether we can accept it in its current form.

@dreamaniajp dreamaniajp force-pushed the master branch 3 times, most recently from 574f2a5 to b1e2e1a Compare June 8, 2021 16:21
@dreamaniajp
Copy link
Contributor Author

Hi @baumanj ,
Thanks for the reply,
I rebased this PR and add "mp4v" feature to separate the mp4v related call flow from original.
This makes it doesn't affect the existing functionality when the "mp4v" feature isn't enabled.

Thanks a lot.

Copy link
Contributor

@baumanj baumanj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good, but I think there's one place where it is still potentially changing the existing behavior. Fix that one, and I think we should be good to go.

Comment on lines 3394 to 3919
esds.audio_codec = match object_profile {
0x40 | 0x41 => CodecType::AAC,
0x69 | 0x6B => CodecType::MP3,
_ => CodecType::Unknown,
};

esds.video_codec = match object_profile {
0x20..=0x24 => CodecType::MP4V,
_ => CodecType::Unknown,
};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a logic change to the underlying code which will affect the behavior with the "mp4v" feature disabled. Putting it behind a feature flag (and making L3393–3398 conditional on #[cfg(not(feature = "mp4v"))] obscures the code too much, so I don't think we want to accept this kind of change.

It may well be a good one, but unfortunately we don't have time to invest in the necessary vetting for a change that isn't necessary for us.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @baumanj ,

I moved this back to the original place to keep the original call flow and committed the change again.

Thanks.

Comment on lines 3912 to 3916
esds.audio_codec = match object_profile {
0x40 | 0x41 => CodecType::AAC,
0x69 | 0x6B => CodecType::MP3,
_ => CodecType::Unknown,
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to move this? Doing so potentially changes the behavior even then the "mp4v" feature is not enabled since it mutates esds before the call to find_descriptor which takes it as a parameter

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @baumanj ,

No, we don't need to move this actually.
I moved this back to the original place to keep the original call flow and committed the change again.

Thanks.

@baumanj baumanj merged commit 2e2c39a into mozilla:master Jun 9, 2021
@fabricedesre
Copy link

Thanks all!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants