Closed Bug 1481513 Opened 6 years ago Closed 6 years ago

disable ffvpx on aarch64 windows

Categories

(Core :: Audio/Video, enhancement, P3)

ARM64
Windows
enhancement

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: froydnj, Assigned: froydnj)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Otherwise, we somehow wind up including atomic_gcc.h on Windows, which isn't going to end well for anybody.

I don't know if providing the correct config* files will necessarily solve everything, but it'll be a step in the right direction.  Perhaps upstream has already integrated the necessary work?
Rank: 25
Priority: -- → P3
There's no support for it in our local tree, and trying to hack in support is
too sketchy.
Attachment #8999007 - Flags: review?(core-build-config-reviews)
Assignee: nobody → nfroyd
Summary: provide ffvpx/libavutil configuration for aarch64 windows → disable ffvpx on aarch64 windows
Attachment #8999007 - Flags: review?(core-build-config-reviews) → review+
jya, do you know if ffvpx has fast code for aarch64 ?
Flags: needinfo?(jyavenard)
ffmpeg would. but how optimal I don't know. We never integrated those optimisations however.

Disabling ffvpx will have a significant performance impact and machines with already lower spec. Surely, there's a better solution than disabling entirely.
Flags: needinfo?(jyavenard)
(In reply to Jean-Yves Avenard [:jya] from comment #3)
> Disabling ffvpx will have a significant performance impact and machines with
> already lower spec. Surely, there's a better solution than disabling
> entirely.

Sure.  And note that the plan would be to turn ffvpx off just to get things to build and possibly to prove that the whole thing runs.  We can turn ffvpx back on at a later point.

My current tree has a cargo-culted media/ffvpx/config_aarch64_win64.h header and a hacked media/ffvpx/config.h to use that header when appropriate.  The build dies because aarch64-specific files aren't checked in (makes sense), but it's not obvious to me that even with those files, the build would succeed.  I guess I could try getting them into the tree and seeing what happens...
(In reply to Nathan Froyd [:froydnj] from comment #4)
> My current tree has a cargo-culted media/ffvpx/config_aarch64_win64.h header
> and a hacked media/ffvpx/config.h to use that header when appropriate.  The
> build dies because aarch64-specific files aren't checked in (makes sense),
> but it's not obvious to me that even with those files, the build would
> succeed.  I guess I could try getting them into the tree and seeing what
> happens...

I looked at README_MOZILLA, which says that the current revision that we're using is n3.4.1-g587fadaef1, which I assume corresponds to:

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/587fadaef1

(I don't know what the 'g' prefix on the commit hash is for.)  Is that correct?
Flags: needinfo?(jyavenard)
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/64213b300680
disable ffvpx on aarch64 windows; r=gps
https://hg.mozilla.org/mozilla-central/rev/64213b300680
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
See Also: → 1488065
Flags: needinfo?(jyavenard)
(In reply to Nathan Froyd [:froydnj] from comment #5)

> 
> I looked at README_MOZILLA, which says that the current revision that we're
> using is n3.4.1-g587fadaef1, which I assume corresponds to:
> 
> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/587fadaef1
> 
> (I don't know what the 'g' prefix on the commit hash is for.)  Is that
> correct?


n3.4.1-g587fadaef1 is the output of git describe when done in the ffmpeg tree.

you can use it just like a commit hash:
git log n3.4.1-g587fadaef1

but you're right, what you find after the g is the hash it points to
You need to log in before you can comment on or make changes to this bug.