GithubHelp home page GithubHelp logo

mpeggroup / fileformatconformance Goto Github PK

View Code? Open in Web Editor NEW
10.0 8.0 3.0 2.74 MB

MPEG File Format Conformance Framework

Home Page: https://mpeggroup.github.io/FileFormatConformance/

License: BSD 3-Clause Clear License

Python 38.64% JavaScript 0.21% HTML 0.10% TypeScript 60.56% CSS 0.18% Roff 0.31%
conformance heif isobmff mp4 mpeg-4

fileformatconformance's Introduction

File Format Conformance Framework

Test

Overview

Welcome to the File Format Conformance Framework, a repository dedicated to supporting the conformance resources for specifications developed by the MPEG Systems File Format group. This framework is based on ISO/IEC 14496-32 and contains conformance files for various specifications, such as:

  • ISOBMFF: 14496-12
  • MP4: 14496-14
  • NALUFF: 14496-15
  • Text: 14496-30
  • HEIF: 23008-12

The main goals for the File Format Conformance Framework are:

  • to provide a way to contribute new files to the conformance suite.
  • to manage existing files and gather additional metadata associated with the files.
  • to create a dump of the contents of the files by utilizing automation tools with the ability to add additional information which could not be automatically determined.
  • to export all features (e.g. boxes, sample groups, etc.) from our specifications to a json format which we can later use to map conformance files to them which claim to be conformant to these features.
  • to utilize automation tools to check for validity of contributed files by checking the metadata extracted from specifications (this metadata includes checking box types, version, flags, location of the boxes, user defined features from specifications which files claim to be conformant to, etc.).

    NOTE: This framework DOES NOT validate the conformance of each feature, but rather provides a mapping from contributed files to features that are defined in our specifications. We check for correct box definitions and locations as well as defined versions and flags.

  • to automate validation of the registered boxes from MP4RA.
  • to provide visualization of existing files and its mapping to specifications, as well as providing a search tool to quickly find files with desired features.
  • to visualize the coverage page, which shows how many features can be found in files contributed to the framework. This information is used to understand the current status of the files that we have currently in our suite and how many files we still need to gather to provide example files to every feature defined our specifications.

Conformance files themselves are stored on this GitHub repository using the Git Large File Storage (LFS).

The design of the framework allows for easy extensions to support new specifications and file formats. The addition of new specifications or amendments to the framework is as simple as providing the necessary metadata.

Contributing

We encourage your contributions! If you identify any issues with the metadata or the functionality of this framework or if you can contribute conformance files, feel free to open an issue or contribute directly to the project on GitHub. Please refer to our CONTRIBUTING.md for information on the process for submitting new conformance files to this repository (MPEG Members only).

License

This project operates under the Clear BSD License. For more details, please see our LICENSE file.

fileformatconformance's People

Contributors

bradh avatar cconcolato avatar denizugur avatar dependabot[bot] avatar podborski avatar renovate[bot] avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

mfuchs-iis bradh dukesook

fileformatconformance's Issues

Update metadata for CENC files

Summary

CENC files contributed in #76 need an update in the metadata json files to add associated files (xml files) which are needed for decryption.

Steps to reproduce

No response

Affected specifications

No response

Affected files

  • all CENC files inside data/file_features/under_consideration/cenc

PR Checks: Check if unknown boxes are present in standard features

Currently, there is an edge case where if a box is not understood by GPAC and also not registered at MP4RA it's not considered as a problem. In fact, this could be the first time this box has been seen (new contribution) so we need to check if it's present in standard features regardless of if it exists in MP4RA or not. This would only apply to under_consideration files though.

related #107

Add remaining files

From the TuC:

  • [HEIF] Conformance for the ‘prdi’ Item Property
  • [HEIF] Conformance Samples for Region Items
  • [HEIF] Conformance Samples for Region Tracks
  • [ISOBMFF] Conformance for Essential Sample group
  • [NALFF] Conforming files for picture-in-picture

From MPEG#143:

video_cbcs_mkey_const_iv_subs* does not produce a valid XML.

Summary

ERROR: Couldn't parse "../data/file_features/under_consideration/cenc/video_cbcs_mkey_const_iv_subs.mp4". Not valid xml output from MP4Box.

This is probably a MP4Box bug.

Steps to reproduce

No response

Affected specifications

No response

Affected files

  • video_cbcs_mkey_const_iv_subs.mp4

Handlers support

Summary

So far we also ignore handlers. We need handlers.json files in every specification.

Steps to reproduce

No response

Script to check completeness of standard_features

Identify issues with MP4RA and GPAC.

MP4RA:

  • some 4CCs are not assigned to correct specs
  • some 4CCs are missing

GPAC:

  • some 4CCs are not assigned to correct specs
  • some XML output has issues (not valid XML)

etc.

[Website] Coverage percentage seems incorrect

Summary

It's not clear how the coverage is computed:
image

When I set the depth to 1, I end up with 142 boxes covered and 224 boxes not covered. I would expect to see a coverage percentage of 142/(142+224)~= 38.8% (instead of 63.39%). Same for depth=2, ...

The page should indicate the formula used to compute the coverage.

Steps to reproduce

  1. Open the Website
  2. Go to coverage report
  3. select a depth and compare the box numbers with the given percentage

Boxes inside a sample group

Summary

Not so sure how to deal with this one in the framework but SVCDependencyRangeBox - svop is a box which is used inside a scif sample group. so the container can not be sgpd and so far we didn't cover the case where boxes are added inside a sample group.

Identify missing 4CCs / features

We need to write a script which would allow us to easily identify a list of features and 4CCs which are not included in the conformance suite

[Website] Exact container level filter bug

Summary

I want to remove all user defined features which we don't need. For example the ones which reflect a presence of a box could be removed since the website already allows to search for boxes. Also we have a filter for location of the boxes. So for example the following user defined features can be removed:

 "file level meta": "Meta box at file level",
 "movie level meta": "Meta box at movie level",
 "track level meta": "Meta box at track level",

There is one bug with the filter though.

Steps to reproduce

Let's say we want to find a file with a movie level meta only.
Go to the website and set a filter for exact match for meta in the moov box.

image

It will show 1.mp4 but if you open it there will be no file.moov.meta in it.

https://gpac.github.io/mp4box.js/test/filereader.html?https://mpeggroup.github.io/FileFormatConformance/files/published/maf/vsaf/1.mp4

Keep a table for each spec, on internal Gitlab, and automate generating snippet files for box syntax

If each repo at the MPEG internal Gitlab repo had a markdown or CSV table of the 'current versions' of the spec and amendments, with (linked) MPEG document numbers, and linked also to the ISO project, then

  • the minutes would no longer need to include 'current status'
  • an automated script could extract the SDL, check for registration of 4CCs, and push the SDL snippets to the conformance repo
  • we could also link to the ISO project (that would have to be manually done)
  • anyone could edit it to bring it up to date

This table shouldn't be public as most of the links would not work

Script to verify submissions

Possible verifications:

  • file exists
  • list of boxes / features exists in the spec
  • run a validation tool on the files (if possible)

[Website] Better naming of specs and linking

The current list of specs (in the main page or in the coverage page) is:

ISO/IEC 14496-12 (ISOBMFF): ver7
ISO/IEC 23008-12 (HEIF): ver-1
ISO/IEC 14496-15 (NALu): ver5
ISO/IEC 14496-30 (Timed Text): ver-1
ISO/IEC 14496-14 (MP4): ver-1

Instead of "ver7", make it explicit "7th Edition".
Also, "ver-1" is not clear if this means "1st Edition" or no version (-1).
It would be good to add the date of the spec. For example 14496-12 7th edition is the 2022 edition (see https://www.iso.org/standard/83102.html).
It would be good to link the specs to this page https://github.com/MPEGGroup/FileFormat/blob/master/DocumentStatus.md so that people have direct links to download them (either from MPEG document management system if they are member, or from ISO's portal otherwise).

[Website] Link box name in coverage page to the box description

Summary

It would be good to have the box names listed in the coverage tables linked to the other page that describes the box. You could click on a box (covered or not) and get a description for it.

Steps to reproduce

  1. Open the Website
  2. Go to the coverage section
  3. Find a box you're interested in (in the covered or not covered part), e.g. mebx
  4. You should be able to click on it and it would take you to https://mpeggroup.github.io/FileFormatConformance/?query=mebx

"Files under consideration"

Summary

We should consider removing the notion of "Files under consideration".
I think files should be reviewed when the contribution is received, and when the PR is prepared. We can always correct them afterwards if we see bugs.
This would mean removing the "Files under consideration" from the main page, and renaming "Files submitted" into "Conformance files"

Steps to reproduce

N/A

Issue generating *_gpac.json files

I try to use the 897c4dc to check some test vector, and have the following issues :

  • from the several mp4 files, only one was taken into account
  • it require to put the directory with the test vectors under data/file_features directory, which was not previously the case : Is it correct ?

I then checkout the commit 2dcb214, where the two previous issues are no more present. However, the *_gpac.json files are no more generated. I fix this by modifying code

FileFormatConformance/src/feature_extractor/file_features.py

Line 466 in 2dcb214

gpac_dict = _run_mp4box_on_file(actual_file_path)

replacing actual_file_path_ by mp4_path. This modification may also be necessary in main branch.

[Website] Sample groups issue.

Summary

There seems to be an issue with sample groups search.

Steps to reproduce

Search for tele sample group. The website shows 0 files. but there is at least one file with that sample group data/file_features/published/isobmff/sg-tl-st.mp4.

[Website] The depth setting range is not large enough

Summary

There remains red arrows in box lists, even when you put the max value in the depth range
image

Increase the slider max value to make sure it covers every possibility.

Steps to reproduce

  1. Open the coverage part
  2. Set the slider to the max value

Conformance File Contribution Automation Issues

  • Test scripts don't use the latest commit and that fails the test
  • Status checks don't report properly

The problem is the bot doesn't trigger a new workflow run. We would need a PAT or Deploy Keys to mitigate this.

Related article

  • Fix the automation
  • Skip CFC if last commit has been made by bot
  • If contents of MP4Box output has changed (except for version) update it
  • Skip tests if CFC created files (related, concurrency wait)
  • (test.yml) fail construct and coverage without external check (1)
  • (test.yml) proper flow (check conclusion of dependency installation)

On `tbas and sabt track reference` feature

Summary

There are some files that claim to have tbas and sabt track references by defining that metadata in user-defined features field, but no such track references can be found. Probably the ff-conformance.xls issue.

Steps to reproduce

No response

Affected specifications

No response

Affected files

  • hevc_tiles_single_track_nalm_all_intra.mp4
  • hevc_tiles_single_track_nalm_rle.mp4
  • hevc_tiles_single_track_nalm.mp4
  • hevc_tiles_single_track_trif_full_picture.mp4

Question on the search feature

Why when searching for auxl in the coverage report, do the results show auxC or auxi?
image

The same search in the other page does not show them:
image

Handling deprecated 4CCs

Summary

Some 4CCs have been deprecated (e.g. mere) but those are still registered at mp4ra (and this will stay like that). Some of those appear in this warning message:

2023-09-06 13:55:56.465 | WARNING  | construct.boxes:main:336 - Missing boxes in standard features (126): {'auvd', 'feci', 'heic', 'mjpg', 'mint', 'mp4a', 'nclx', 'auxv', 'mp7b', 'geom', 'Exif', 'cdec', 'ecam', 'heix', 'prof', 'isob', 'rICC', 'tile', 'lhti', 'lhte', '1pic', 'sdhd', 'spsc', 'icam', 'vvis', 'iovl', 'vvic', 'evmi', 'relo', 'iphd', 'hvci', 'ochd', 'heis', 'hvti', 'vide', 'iso4', 'mtyp', 'mime', 'pict', 'mif2', 'jpeg', 'levl', 'ctab', 'slid', 'spvi', 'eroi', 'vwsc', 'frar', 'hvce', 'odhd', 'iden', 'null', 'plvi', 'tesc', 'ilvi', 'clip', 'iso2', 'comp', 'jpgs', 'isom', 'm4ae', 'unif', 'rgan', 'mp41', 'mp42', 'isoa', 'scsz', 'm7hd', 'evir', 'vvhd', 'hevs', 'iso9', 'mp4v', 'heim', 'rtvi', 'soun', 'iso3', 'hevm', 'bitr', 'ipmc', 'cgsc', 'iso8', 'load', 'evm1', 'avci', 'hevx', 'matt', 'mere', 'nvws', 'mask', 'avcs', 'volv', 'mp7t', 'mp4s', 'msf1', 'evbi', 'evms', 'mjhd', 'iso6', 'pnot', 'kmat', 'mski', 'aSEI', 'iso7', 'mp71', 'fgsc', 'hvcx', 'resc', 'mif1', 'meco', 'iso5', 'iods', 'isoc', 'hevc', 'mela', 'prfl', 'imif', 'evbs', 'nras', 'crgn', 'imap', 'mpsz', 'esds', 'crhd', 'elvi', 'hapt'}

we need a way to deal with deprecated ones. Perhaps adding an optional deprecated flag to json files would be an option.

Steps to reproduce

No response

Missing conformance files

According to the current coverage report, when you select a depth of 1 (meaning that you don't care where a box is used, and only care about the fact that a box is present somewhere in a conformance file), the coverage is 38.80%. This is a poor coverage.

I see 224 boxes for which we don't have a single conformance file. Some of the missing boxes can easily be contributed (e.g. the elng box). Some other boxes are probably used in derived standards (e.g. OMAF) and could be added here. Also, some files under considerations probably exercise some of the missing boxes.

How should we track missing conformance files? Should we open 1 issue per missing box? @podborski ?

Add version and flags to standard_features

It would be really helpful if we store box versions and flags for each FullBox. This would allow us to search for a box of a specific version of flags. Here is an example on how our current json files could be extended:

      "versions": [1, 2, 3],
      "flags": [
      {
        "name": "track_enabled",
        "value": "0x01"
      }, ... ],
      "syntax": "..."

There is some work Cyril did for mp4box.js which can be used to update this fields

Extract syntax from the spec

we could write a script to scan the document and extract the syntax definitions and add them to spec_features

RegEx to validate 4CC too strict/possible characters missing

Issue

Identified by reviewing the "check" for #83:
The "test_validate_files"-check fails because a 4CC contains a - which is not an allowed character per the RegEx ^file(?>\\.[0-9a-zA-Z]{4})*$
see https://github.com/MPEGGroup/FileFormatConformance/actions/runs/6117640706/job/16604576692 , "Validate Output", Line33

proposed solution

Quickly scrolling through mp4ra.org, the following characters are used with registered 4CCs and should be added into the RegEx:

  • -
  • +
  • $20
  • anything else?

Basic issues left with currently available data

Summary

There are some issues that are highlighted by our coverage scripts. Most of them should be easy to handle, they just need to be verified with the spec and committed to the repository.

Issues:

  • Box enca is not listed as container for box sinf
  • Box esds was found in submitted files and it exists in MP4RA but not in our database
  • Box ftyp is not listed as container for box hvc1
  • Box hvt1 is not listed as container for box btrt
  • Box iods was found in submitted files and it exists in MP4RA but not in our database
  • Box iref is not listed as container for box cdsc
  • Box lhe1 is not listed as container for box btrt
  • Box lhv1 is not listed as container for box btrt
  • Box m4ae was found in submitted files and it exists in MP4RA but not in our database
  • Box mp4a was found in submitted files and it exists in MP4RA but not in our database
  • Box mp4s was found in submitted files and it exists in MP4RA but not in our database
  • Box mp4v was found in submitted files and it exists in MP4RA but not in our database
  • Box sbgp is not listed as container for box alst
  • Box sbgp is not listed as container for box nalm
  • Box sbgp is not listed as container for box rap
  • Box sbgp is not listed as container for box rash
  • Box sbgp is not listed as container for box refs
  • Box sbgp is not listed as container for box roll
  • Box sbgp is not listed as container for box tele
  • Box strk is not listed as container for box stsg
  • Box tref is not listed as container for box dpnd
  • Box tref is not listed as container for box sync
  • Path ~enca.sinf is not listed as container for box frma
  • Path ~enca.sinf is not listed as container for box schi
  • Path ~enca.sinf is not listed as container for box schm
  • Box avci was found in submitted files and it exists in MP4RA but not in our database
  • Box heic was found in submitted files and it exists in MP4RA but not in our database
  • Box heis was found in submitted files and it exists in MP4RA but not in our database
  • Box heix was found in submitted files and it exists in MP4RA but not in our database
  • Box hevc was found in submitted files and it exists in MP4RA but not in our database
  • Box hvce was found in submitted files and it exists in MP4RA but not in our database
  • Box hvci was found in submitted files and it exists in MP4RA but not in our database
  • Box mif1 was found in submitted files and it exists in MP4RA but not in our database
  • Box mp41 was found in submitted files and it exists in MP4RA but not in our database
  • Box mp42 was found in submitted files and it exists in MP4RA but not in our database
  • Box msf1 was found in submitted files and it exists in MP4RA but not in our database
  • Box pict was found in submitted files and it exists in MP4RA but not in our database

Steps to reproduce

You run run npm install && npm test on root directory

Wrongly labeled files from Part 32 (sample entry related)

Summary

Some files seem to be wrongly labeled in the first version of the 14496-32 spec. This is now visible because we mapped metadata from ff-conformance.xls to json data in this repo.

For example some files are labeled to have hev1 sample entry type in them but there is no such sample entry to be found.

I will remove user-defined features for sample entries, since the framework allows to search for them without explicit signaling. This issues is just to keep track of the problem with the metadata for some of the files.

Steps to reproduce

No response

Affected specifications

No response

Affected files

  • hevc_tiles_multiple_tracks_empty_base.mp4 (no hev1)
  • there are many more and I will not list them all but I will reference this issue in commits

About "features"

Summary

The notion of "features" is not explained on the website. The about page also uses features in a different way.

Steps to reproduce

N/A

improve contributing.md

Summary

As discussed at the File format AhG call, some suggestions to improve contributing.md

Split section 1 in 1.1. general requirements and 1.2. json metadata
1.1. can include the zipfile naming requirements, byte size requirements (how many bytes ?) and the requirement to make an mpeg contribution
1.2 json metadata
I would like to know a bit more about how to generate this with GPAC (command line), or bento and what the specific requirements on the syntax of json would be. The default option of using gpac looks strange to me as by definition new boxes are not supported in gpac otherwise they would not be new. So a contributor would really need to know how to create a metadata json file in any case. The explanation that the json is used by the search interface also helps to understand why this is needed and a requirement for contributing. I dont think it is necessary to provide too many details on how the gpac integration works in the framework. Instead, I think if people know how to create the json and they include it when contributing reference files this will
help not only for the conformance framework, but also with doing cross checks as the json shows what is intended to be in the mp4 file.
clause 2:
If this is only intended for administrators, maybe create a separate document on how to create a pull request and reference to that? It is good to have this information, but as most people are not file format chairs including this information by reference makes sense !?

Steps to reproduce

none/open contributing.md

npm run serve failing

I ran npm install in the html folder (no problem) but have a problem with npm run serve:

❯ npm run serve

> [email protected] serve
> vue-cli-service serve

 INFO  Starting development server...
10% building 2/5 modules 3 active ...ato/oss_code/FileFormatConformance/html/node_modules/eslint-loader/index.js??ref--14-0!/Users/cconcolato/oss_code/FileFormatConformance/html/src/main.jsError: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at module.exports (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:471:10)
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:503:5
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:358:12
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at iterateNormalLoaders (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:236:3
    at runSyncOrAsync (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
    at iterateNormalLoaders (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
    at Array.<anonymous> (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:55:16)
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:91:9
node:internal/crypto/hash:67
  this[kHandle] = new _Hash(algorithm, xofLen);
                  ^

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at module.exports (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:471:10)
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:503:5
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/webpack/lib/NormalModule.js:358:12
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at Array.<anonymous> (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (/Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:55:16)
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:91:9
    at /Users/cconcolato/oss_code/FileFormatConformance/html/node_modules/graceful-fs/graceful-fs.js:123:16
    at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read_file_context:68:3) {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v17.2.0

On `oinf, linf and oref track reference` feature.

Summary

The following feature is defined in some files: oinf, linf and oref track reference

However there is no such thing as oinf of linf track reference. oref is the track reference, others are just a sample group.

I think the feature is safe to be removed. But in case I missed oinf of linf track reference feel free to raise it.

There is also no such references registered at mp4ra.

Steps to reproduce

No response

Affected specifications

No response

Affected files

  • mhvc_hev1_hev2_multiple_tracks_extractors.mp4
  • mhvc_hev1_lhe1_multiple_tracks_implicit.mp4
  • etc.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.