gpac/gpac

GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery

GPAC Introduction

Current version: 2.5-DEV

Latest Release: 2.4

GPAC is an open-source multimedia framework focused on modularity and standards compliance. GPAC provides tools to process, inspect, package, stream, playback and interact with media content. Such content can be any combination of audio, video, subtitles, metadata, scalable graphics, encrypted media, 2D/3D graphics and ECMAScript. GPAC is best-known for its wide MP4/ISOBMFF capabilities and is popular among video enthusiasts, academic researchers, standardization bodies, and professional broadcasters.

For more information, visit https://gpac.io

GPAC is distributed under the LGPL v2.1 or later, and is also available, for most of it, under a commercial license.

Please ! cite ! our work in your research:

• "GPAC Filters" (https://doi.org/10.1145/3339825.3394929) for recent versions (0.9 or above)
• "GPAC: open source multimedia framework" (https://doi.org/10.1145/1291233.1291452) for older versions.

Features

GPAC can process, analyse, package, stream, encode, decode and playback a wide variety of contents. Selected feature list:

• Audio: MPEG audio (mp1/2/3, aac), AC3, E-AC3, Opus, FLAC, …
• Video: MPEG 1 / 2 / 4 (H264/AVC) / H (HEVC), VVC, AV1, VP9, Theora, ...
• Subtitles: WebVTT, TTML (full, EBU-TTD, …), 3GPP/Apple Timed Text, …
• Encryption: CENC, PIFF, ISMA, OMA, ...
• Containers: MP4/fMP4/CMAF/Quicktime MOV/ProRes MOV, AVI, MPG, OGG, MKV, ...
• Streaming: MPEG-2 Transport Stream, RTP, RTSP, HTTP, Apple HLS, MPEG-DASH, ATSC 3.0 ROUTE, ...
• Supported IOs: local files, pipes, UDP/TCP, HTTP(S), custom IO
• Presentation formats: MPEG-4 BIFS, SVG Tiny 1.2, VRML/X3D
• JS scripting through QuickJS for both SVG/BIFS/VRML and extending GPAC framework tools
• 3D support (360 videos, WebGL JS filters…)
• Inputs: microphone, camera, desktop grabbing
• Highly configurable media processing pipeline
• Python and NodeJS bindings

Features are encapsulated in processing modules called filters:

• to get the full list of available features, you can run the command line gpac -h filters or check filters' wiki.
• to get the full list of playback features, check the dedicated wiki page.

Tools

MP4Box

MP4Box is a multi-purpose MP4 file manipulation for the prompt, featuring media importing and extracting, file inspection, DASH segmentation, RTP hinting, ... See MP4Box -h, man MP4Box or our wiki.

gpac

GPAC includes a filter engine in charge of stream management and used by most applications in GPAC - read this post for more discussion on how this impacts MP4Box. The gpac application is a direct interface to the filter engine of GPAC, allowing any combination of filters not enabled by other applications. See gpac -h, man gpac, man gpac-filters or our wiki for more details.

Getting started

Download

Stable and nightly builds installers for Windows, Linux, OSX, Android, iOS are available on gpac.io.

If you want to compile GPAC yourself, please follow the instructions in the build section of our wiki.

Documentation

The general GPAC framework documentation is available on wiki.gpac.io, including HowTos.

GPAC tools are mostly wrappers around an underlying library called libgpac which can easily be embedded in your projects. The libgpac developer documentation is available at doxygen.gpac.io, including documentation of JS APIs, Python APIs and NodeJS APIs.

Testing

GPAC has a test suite exercising most features of the framework. The test suite is in a separate repository https://github.com/gpac/testsuite/, but is available as a submodule of the GPAC main repository. To initialize the testsuite submodule, do git submodule update --init.

For more details on the test suite, read this page and check the testsuite readme.

Per-commit build and tests results are available.

Support, ongoing tasks and bugs

Please use github for feature requests and bug reports. When filing a request there, please tag it as feature-request.

Contributing

A complex project like GPAC wouldn’t exist and persist without the support of its community. Please contribute: a nice message, supporting us in our communication, reporting issues when you see them… any gesture, even the smallest ones, counts.

If you want to contribute to GPAC, you can find ideas at GSoC page or look for a good first issue. In any doubt please feel free to contact us.

Team

GPAC is brought to you by an experienced team of developers with a wide track-record on media processing.

The project is mainly developed in the MultiMedia group of Telecom Paris with the help of many great contributors.

GPAC has a peculiar story: started as a startup in NYC, GPAC gained traction from research and a nascent multimedia community as it was open-sourced in 2003. Since then we have never stopped transforming GPAC into a useful and up-to-date project, with many industrial R&D collaborations and a community of tens of thousands of users. This makes GPAC one of the few open-source multimedia projects that gathers so much diversity.

Roadmap

Users are encouraged to use the latest tag or the master branch.

V2.X

Targets:

• DASH event support
• Web GUI
• QUIC support
• ROUTE file repair support
• FLUTE support
• Rust Bindings

gpac's Issues

DashCast $Time$ token

Hi

Does DashCast support the $Time$ token, for file segments names and for the SegmentTemplate.

MP4Box has a -segment-name option, but can find anything like this for DashCast.

Thanks

improve the security of the code and API

• static analysis:
  • http://paulinsights.wordpress.com/2014/07/10/why-you-should-really-care-about-cc-static-analysis/comment-page-1/#comment-1
  • ASAN, Valgrind etc. (cf new in gcc 4.9)
  • control flow integrity: https://sites.google.com/a/chromium.org/dev/developers/testing/control-flow-integrity
  • http://frama-c.com/what_is.html
  • coverity: http://www.coverity.com/ (can be integrated with TravisCI)
• securizing the code:
  • https://wiki.libav.org/Security/Tools
  • http://gynvael.coldwind.pl/?id=524
  • https://code.google.com/p/address-sanitizer/downloads/list
• compiling:
  • http://blog.quarkslab.com/clang-hardening-cheat-sheet.html

Note of gf_bs_*(): 74e5eb4

"pcr" in pcrb box is 48-bits long, but gpac reads and writes 64 bits for it

In the DASH spec (6.4.7.2 MPEG-2 TS PCR information box):

aligned(8) class MPEG2TSPCRInfoBox extends Box(‘pcrb’, 0) {
    unsigned int(32) subsegment_count;
    for( i = 1; i <= subsegment_count; i++){
        unsigned int(42) pcr;
        unsigned int(6) pad = 0;
    }
}

pcr + pad is 48 bits long, but in src/isomedia/box_code_base.c functions you read and write them as 64-bit values:

GF_Err pcrb_Read(GF_Box *s,GF_BitStream *bs)
{
    u32 i;
    GF_PcrInfoBox *ptr = (GF_PcrInfoBox*) s;

    ptr->subsegment_count = gf_bs_read_u32(bs);
    ptr->size -= 4;

    ptr->pcr_values = gf_malloc(sizeof(u64)*ptr->subsegment_count);
    for (i=0; i<ptr->subsegment_count; i++) {
        u64 data1 = gf_bs_read_u32(bs);
        u64 data2 = gf_bs_read_u32(bs);
        ptr->size -= 8;
        ptr->pcr_values[i] = (data1 << 10) | (data2 >> 22);

    }
    return GF_OK;
}

GF_Err pcrb_Write(GF_Box *s, GF_BitStream *bs)
{
    GF_Err e;
    u32 i;
    GF_PcrInfoBox *ptr = (GF_PcrInfoBox*) s;

    e = gf_isom_box_write_header(s, bs);
    if (e) return e;

    gf_bs_write_u32(bs, ptr->subsegment_count);

    for (i=0; i<ptr->subsegment_count; i++ ) {
        u32 data1 = (u32) (ptr->pcr_values[i] >> 10);
        u32 data2 = (u32) ((ptr->pcr_values[i]& 0x3FF) << 22);

        gf_bs_write_u32(bs, data1);
        gf_bs_write_u32(bs, data2);
    }
    return GF_OK;
}

GF_Err pcrb_Size(GF_Box *s)
{
    GF_Err e;
    GF_PcrInfoBox *ptr = (GF_PcrInfoBox*) s;
    e = gf_isom_box_get_size(s);
    if (e) return e;

    ptr->size += 4;
    ptr->size += ptr->subsegment_count * 8;

    return GF_OK;
}

[Android] Some streams are played at 24000

When playing some streams on Android, the audio is not played at the right sampling rate. In function

static GF_Err WAV_QueryOutputSampleRate(GF_AudioOutput *dr, u32 *desired_samplerate, u32 *NbChannels, u32 *nbBitsPerSample)

in modules/droid_audio/droid_audio.c, the desired_samplerate is argument is 24000 where the actual stream's sample rate is 48000.

dumping DASH file with MP4Client

Hi all,

I am trying to dump a live MPEG-DASH stream in order to do a PSRN comparison.
I found a previous discussion about keeping the cache

http://ehc.ac/p/gpac/discussion/287547/thread/be52202f/#1eef

When I use the same configurations I have the following error:

Opening URL http://<serverIP>/video1.mpd
[HTTP] Failure: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>    
<h1>Not Found</h1>
<p>The requested URL /tmp/gpac_cache_B049E484B4AA47A7924DBF39288A27821AF0F40C.mp4 was not found on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at <serverIP> Port 80</address>
</body></html>

[HTTP] Error parsing reply: Requested URL is not valid or cannot be found for URL             http://<serverIP>:80/tmp/gpac_cache_B049E484B4AA47A7924DBF39288A27821AF0F40C.mp4
[CACHE] gf_cache_delete_entry:835, failed to delete file /tmp/gpac_cache_7BF61017F5FFEC8CD6EF66772986D35AB768D758.mp4.txt
[DASH] FAILED to download http://<serverIP>:80/tmp/gpac_cache_B049E484B4AA47A7924DBF39288A27821AF0F40C.mp4 = Requested URL is not valid or cannot be found...
 Cannot open http://<serverIP>/video1.mpd: Requested URL is not valid or cannot be found
[CACHE] entry is null at utils/cache.c:556
[CACHE] entry is null at utils/cache.c:556

How can I tell MP4Client to take the cache in local directory?

Thanks

[DASH] Add missing DASH-IF IOP profiles.

Hi!

While creating DASH HEVC media according to DASH-IF IOP guidelines (I'm using the publicly available version v2.9, which is a draft of soon to be released v3.0 (http://dashif.org/w/2014/08/DASH-IF-IOP-v2.90.pdf), I noticed that MP4Box knows only about DASH and DASH-264/AVC profiles (at least that's what I see in mp4box -h dash (-profile option)). Since HEVC is now also the part of DASH-IF IOP, it would be nice to have additional profiles for it. Perhaps, something similar to DASH-264/AVC, for example: "dashevc265:onDemand" and "dashevc265:live".

Request: MP4Client to output to stdout

This is a feature request rather than a bug, but it would be very useful if MP4Client could output the data to stdout rather than direct to the audio/visual hardware.

While I'm sure many developers/users would find this useful for chaining the output to other commands, my specific use would be to allow playback of MPEG-DASH streams within the squeezebox music system. There is a plugin which will play simple DASH streams created by MP4Box using vlc to handle the transcoding (see https://github.com/Mac0z/playDASH) but this cannot handle more complex streams such as the BBC's test MPEG-DASH feed (http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-audio.mpd) which MP4Client handles perfectly.

Commit "More fixes on AVI audio dumping and misc fixes" breaks playing on Android

Commit 5fccaca "More fixes on AVI audio dumping and misc fixes" breaks playing on android, Audio is stuttering and playing http://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4, it skips after some seconds right to the end.

Make a static build of MP4Box easier

...a and add to the https://travis-ci.org/gpac/gpac/builds/42405732

And notifiy at https://sourceforge.net/p/gpac/bugs/341/ (related to #5)

[DASH] Streams URL not constructed correctly when receiving HTTP redirect

When trying to play a dash stream, if the http servers reply with an HTTP redirect when fetching the m3u8 play list, the sub-stream URLs are constructed using the original URL instead of the redirected one. This ugly patch fixes the problem but I suppose you'd want something cleaner.

--- a/src/media_tools/dash_client.c
+++ b/src/media_tools/dash_client.c
@@ -4285,3 +4285,3 @@ GF_Err gf_dash_open(GF_DashClient *dash, const char *manifest_url)
        } else {
-           gf_m3u8_to_mpd(local_url, manifest_url, NULL, dash->reload_count, dash->mimeTypeForM3U8Segments, 0, M3U8_TO_MPD_USE_TEMPLATE, &dash->getter);
+           gf_m3u8_to_mpd(local_url, dash->base_url /* manifest_url */, NULL, dash->reload_count, dash->mimeTypeForM3U8Segments, 0, M3U8_TO_MPD_USE_TEMPLATE, &dash->getter);
        }
--- a/src/media_tools/m3u8.c
+++ b/src/media_tools/m3u8.c
@@ -698,5 +698,16 @@ GF_Err declare_sub_playlist(char *currentLine, const char *baseURL, s_accumulate
            char *currFullURL = fullURL;
-           fullURL = gf_url_concatenate(baseURL, currFullURL);
+           char *b = strstr(baseURL, "?");
+           char *tmp;
+           if (b) {
+               tmp = gf_malloc(b - baseURL + 1);
+               strncpy(tmp, baseURL, b - baseURL);
+               tmp[b - baseURL] = 0;
+           } else {
+               tmp = strdup(baseURL);
+           }
+           fullURL = gf_url_concatenate(tmp, currFullURL);
+
            if (currFullURL != currentLine)
                gf_free(currFullURL);
+           gf_free(tmp);
        }

Use enum types for trackNum and trackId

There are some possible bugs hidden in the confusion between track numbers and track IDs. Track IDs are from the specification while track numbers are GPAC's internals. Having a stronger type for each of them would certainly raise interesting warnings.

Possible Regression: Commits from today introduce compile error

I originally stumbled on this error in a discussion board here:

http://sourceforge.net/p/gpac/discussion/287547/thread/1bea5b64/

Yesterday GPAC builds were working as expected on Ubuntu, today I was getting the same error as above with the latest commits.

Creating mpeg-dash stream with subtitles

Hi to everyone, I don't know if this is the right place to post it, but...

I am trying to create my own mpeg-dash "live" stream with subtitles usign gpac as I can see in http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live-subtitle/

I am able to add subtitles (srt) to an mp4 video by using:

MP4Box -add subs.srt video.mp4

but I am not able to create a "live" stream using MP4Box with a video and subtitles like it is shown in

http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live-subtitle/readme.txt

That command only creates an mpd that has video component, not subtitle component.

Which is the correct command line to create a mpeg-dash live stream with subtitles?

I am running MP4Box 0.5.1-DEV-rev5366 on a Debian 8.0 64 bits

MP4Box -version
MP4Box - GPAC version 0.5.1-DEV-rev5366
GPAC Copyright (c) Telecom ParisTech 2000-2012
GPAC Configuration:
Features: GPAC_HAS_SSL GPAC_HAS_JPEG GPAC_HAS_PNG

Thanks in advance

Felipe

Video templating

Hi. I'm searching for solution of video templating issue for web streaming.
I've got video which could be changed on the fly on demand and then streamed. I want to make it fast.
My goal is to split video file into small chunks (and store chunks in separate files) which will be a build blocks of final video, then change some of chunks (frame data only, no duration changes) on demand and concat chunks to get the result video.
My goal is to limit computations and simplify concatenation if it possible to simple cat.
So is it possible to do it this way with mp4Box?

'configure' should output a config.log file to help debugging

Cache folder should be created when it does not exist

Changing the cache folder in .gpacrc to a non-existing folder leads to I/O Errors.

[DASH] When constructing sub-stream URLs, the ?... part of the URL is dropped

When trying to play a dash stream where the sub-stream URLs contains parameters like http://foo.com/my/stream.ts?foo=bar&baz=bar, the ?foo=bar&baz=bar part is dropped due to the code at line 673 of src/media_tools/m3u8.c:

    char *fullURL = strstr(currentLine, "?");
    if (fullURL) {
        /*some URL contains garbage after the filename*/
        size_t len = fullURL-currentLine;
        fullURL = gf_malloc(len+1);
        strncpy(fullURL, currentLine, len);
        fullURL[len] = '\0';
    } else {
        fullURL = currentLine;
    }

Using only

fullURL = currentLine;

fixes the problem.

colorize the libgpac log

It would improve readibility. FFmpeg does it great!

[DASH] Muxed media is not supported by DASH-AVC/264.

Hi!

I noticed that using MP4Box (GPAC rev 5572) it's possible to create muxed DASH media using DASH-AVC/264 profiles. But, as mentioned in the DASH-AVC/264 Interoperability Points v2.0, "only non-multiplexed Representations are supported, i.e. each Representation only contains a single media component" (see: Figure 7, page 16; 3.2.1, page 2, line 38).
.
I guess, at least a warning must be shown in this case.

Test media can be found here: http://1drv.ms/1xDwuTP

Representation segment index doesn't start with a segment index box which indexes the index segment

Sorry about the long title.

In 6.4.6.3 Representation Index Segment:

The Segment Index for each Media Segments is concatenated in order, preceded by a single
Segment Index box that indexes the Index Segment. This initial Segment Index box shall have one
entry in its loop for each Media Segment, and each entry refers to the Segment Index information for
a single Media Segment.

When I use MP4Box to create a DASH stream from MPEG-TS files, the representation index doesn't start with this initial segment index box, but instead just has the segment indexes for media segments.

[DASH] AdaptationSet@lang (audio) is missing while using DASH-AVC/264 profiles.

Hi!

While using MP4Box (GPAC rev 5572), I noticed that the AdaptationSet@lang attribute for audio streams is missing when the DASH-AVC/264 profiles are used, and a language of an audio stream is undefined. But, according to DASH-AVC/264 Interoperability Points v2.0, this attribute is mandatory - "For any Adaptation Sets with value of the @contentType="audio" the following attributes shall be present: @lang".

Test media can be found here: http://1drv.ms/1AxRlrg

There are 2 audio streams:

1. audio-240k.m4a - doesn't have the language "tag", so "mp4box.exe -info" reports "Media Info: Language "und (und)"".
2. audio-240k-en-US.m4a - has the language "tag" (en-US) (Media Info: Language "English (en-US)") (I used "mp4box.exe -lang en-US audio-240k-en-US.m4a" in order to set it).

So, if the language is not set (the "und" case), then AdaptationSet@lang is missing. But this is wrong - this attribute must always present, and its value, in the "und" case, must be set to "und", according to 4.1 (5) of the BCP-47 (http://www.rfc-editor.org/rfc/bcp/bcp47.txt).

[DASH] Add the way to specify custom DASH profiles / interoperability points / extensions.

Hi!

At this moment, MP4Box allows to specify only specific DASH profiles (the -profile option). But DASH-IF IOP mentions (in section 1) that content authors may signal the specific subset of DASH-IF IOP. As far as I know (correct me if I'm wrong), the only thing that is needed is to be able to specify custom extension identifiers (Table 1) in MPD@profiles, which will describe the actual media.

Right now, MP4Box uses generic "http://dashif.org/guildelines/dash264" for the DASH-264/AVC case, for example. But it would be nice if it would be possible to specify custom identifiers, like "http://dashif.org/guidelines/dashif#sd", for example.

Perhaps, there could be another option added to MP4Box for that purpose. Maybe something like -profile-extension, or anything like that. So, the idea is that you still have to specify the -profile, but if you want another identifier, then you additionally specify it in the -profile-extension.

Can't load FFmpeg on the latest Android official APK

May be related to #45

What's the best way to proceed?

mp4box -raw is extracting tracks without extensions when path of source file contains "."

for ex.
let's assume that test.mp4 contains 1 video track and 1 audio track
"mp4box.exe -raw 1 -raw 2 d:\test.test\test.mp4"
will create "test_track1" and "test_track2" instead of
"test_track1.h264" and "test_track2.aac"

Segmentation faults trying to package TTML captions

Hi,

I'm getting segmentation faults when trying to wrap TTML captions into ISOBMFF as explained here:

http://gpac.wp.mines-telecom.fr/2014/08/23/ebu-ttd-support-in-gpac/

I'm using the latest revision of GPAC (r5526). For the TTML file I'm using the file from your own regression tests (as well as several of my own):

https://raw.githubusercontent.com/gpac/gpac/master/regression_tests/ttml/ebu-ttd_sample.ttml

Segmentation faults occur on the following platforms:

• OS X 10.10.1 (Yosemite)
• Ubuntu 14.04.1 LTS 64-bit

$ MP4Box -add ebu-ttd_sample.ttml -new captions.mp4
TTML Import                                         
Segmentation fault (core dumped)

Infinite loop when packaging/DASH-ing TTML content

Hi all,

I'm trying to use the TTML (EBU-TT-D) support in MP4Box to package my content, but it just ends up in an endless loop maxing out my CPU without ever finishing. Steps to reproduce:

1. Use the TTML file found here
2. Package the TTML file using the following command: MP4Box -add sintel_en_ttml.xml:ext=ttml -new captions.mp4
3. DASH the file with a subsegment duration of 4 seconds: MP4Box -dash 4000 -profile onDemand -rap -frag-rap -url-template -segment-name %s_ -segment-ext mp4 captions.mp4 -out captions

The last command will freeze indefinitely on my computer (OS X 10.10 Yosemite) and max out my CPU usage. MP4Box output only shows:

DASH-ing file - single segment
Subsegment duration 4.000 - Fragment duration: 4.000 secs
Spliting segments and fragments at GOP boundaries
[DASH] Generating MPD at time 2014-12-09T13:40:30Z
DASHing file captions.mp4

I am using MP4Box r5544. The loop also occurs when I add video and audio representations as well. Thanks for any help!

[DASH] MPD@maxSegmentDuration is missing while using DASH-AVC/264 live profile.

Hi!

While using MP4Box (GPAC rev 5572), I noticed that the MPD@maxSegmentDuration attribute is missing when the DASH-AVC/264 live profile is used. According to DASH-AVC/264 Interoperability Points v2.0, this attribute is mandatory (3.2.2, page 2, lines 25 and 31) - "If the MPD@profiles attribute includes "urn:mpeg: dash:profile:isoff-live:2011", then the attribute MPD@maxSegmentDuration shall be present".

when concatenating incompatible H264 files, mp4box creates mixed avc1/avc3 mp4 files

I can't share files here, please contact me to be able to reproduce. The only difference is the presence of the aspect_ratio_info_present_flag flag in the SPS.

The streams are generated with FFmpeg and I couldn't figure out with the SPS were different yet.

GPAC could either have:

• a better comparison algorithm for AVCConfig (especially for descriptors) ;
• change the behaviour and use multiple "sample descriptions" with 'avc1' or switch completely to 'avc3' - check if compatible with existing players.

Opinions? CC @gpac/owners

[DASH] Bitstream switching between Representations that use different codecs.

Hi!

While creating DASH media using MP4Box (GPAC rev 5572), I noticed a warning that says "[DASH]: Couldnt merge AVC|H264 SPS from different files (same SPS ID used) - different sample descriptions will be used". Also, by looking at the code and by checking the MPD, I noticed that bitstream switching is turned off in this case:

gpac/src/media_tools/dash_segmenter.c

Line 2437 in 25a10ff

GF_LOG(GF_LOG_WARNING, GF_LOG_DASH, ("[DASH]: Couldnt merge AVC|H264 SPS from different files (same SPS ID used) - different sample descriptions will be used\n"));

My media consists of 2 video (v) and 1 audio (a) stream (http://1drv.ms/1xDsl27):
1.v) 360p using Constrained Baseline profile and level 3.0.
2.v) 720p using High profile and level 3.1.
1.a) AAC-LC.

So, what triggers this behavior (and warning) is the fact that I'm using different codecs for different video Representations.

But it seems that something is wrong here.

1. DASH-AVC/264 Interoperability Points v2.0 (and other versions) does not require Representations in one specific AdaptationSet to use the same codec. (This case is not even mentioned there.)
2. ISO/IEC 23009-1 (2nd edition) (DASH standard) also does not have such a requirement, but it additionally mentions in 4.3 that "Clients may ignore Representations that rely on codecs or other rendering technologies they do not support or that are otherwise unsuitable".

In other words, only media players (Clients) must decide whether they're going to switch to specific (supported) streams. So, bitstream switching must not be disabled by default, if different codecs are used.

Also, speaking of the warning itself, it seems wrong or misleading (although I must say that I don't know much about SPS NAL units). Why MP4Box is trying to merge SPSs? Since different profiles and levels are used, it should be OK that SPSs are different, isn't it? And if SPSs "couldn't be merged", then why the "same SPS ID used"?

[DASH] "Segment duration variation" warning is shown in the wrong case.

Hi!

While creating DASH media using MP4Box (GPAC rev 5572), I noticed that sometimes invalid warnings may be shown.

It looks like:

E:\Programs\GPAC>mp4box.exe -dash 10000 -frag 10000 -rap -frag-rap -profile dashavc264:live -segment-name %s- "E:\Media\Sintel\Trailer\Source\360-200k.mp4" "E:\Media\Sintel\Trailer\Source\360-350k.mp4" "E:\Media\Sintel\Trailer\Source\360-500k.mp4" "E:\Media\Sintel\Trailer\Source\audio-240k.m4a" -out "E:\Media\Sintel\Trailer\Clean\sintel.mpd"
DASH-ing files: 10.00s segments 10.00s fragments single sidx per segment
Spliting segments and fragments at GOP boundaries
[DASH] Generating MPD at time 2014-12-21T11:53:13Z
DASHing file E:\Media\Sintel\Trailer\Source\360-200k.mp4
[DASH]: Segment duration variation is higher than the +/- 50% allowed by DASH-IF (min 2.208, max 10) - please reconsider encoding
DASHing file E:\Media\Sintel\Trailer\Source\360-350k.mp4
[DASH]: Segment duration variation is higher than the +/- 50% allowed by DASH-IF (min 2.208, max 10) - please reconsider encoding
DASHing file E:\Media\Sintel\Trailer\Source\360-500k.mp4
[DASH]: Segment duration variation is higher than the +/- 50% allowed by DASH-IF (min 2.208, max 10) - please reconsider encoding
DASHing file E:\Media\Sintel\Trailer\Source\audio-240k.m4a
[DASH]: Segment duration variation is higher than the +/- 50% allowed by DASH-IF (min 2.101, max 9.984) - please reconsider encoding

The media that I was using can be found here: http://1drv.ms/1wRwk9A

The media is using GOP equal to 2 seconds, which can be proven by looking into "*nalu.xml", "*ts.txt", "*ffmpeg.txt" and "*stats.txt" files. So, I-frames are located strictly at "FPS (24) * 2" positions. This means that "segment duration variation" can't happen.

The warning (let's take the first one, for example) mentions that the minimum segment duration is 2.208, but I specified -dash 10000 (10 seconds). Knowing that GOP is constant, the only case when this may happen is the last segment, since it may contain less frames than in 1 whole segment. So, given that the video consist of 1253 frames, FPS is 24, and we're splitting it into 10 seconds segments, we get: 1253 / (24 * 10) = 5.22083(3). In other words, 5 whole segments, and 1 is 2.208, which is more than 50% smaller than other segments. And the warning proves it.

But this is wrong. DASH-AVC/264 Interoperability Points v2.0 (http://dashif.org/w/2013/08/DASH-AVC-264-v2.00-hd-mca.pdf), in 3.2.1 (line 20) says "Note that the last segment in a representation may be shorter according to ISO/IEC 23009-1". So, such warnings must not be shown if they're caused only by the last segment. And seems that this logic is currently missing: https://github.com/gpac/gpac/blob/master/src/media_tools/dash_segmenter.c#L1665

put gpac_extra_libs in a repository on github

"Timescale 600" used regardless of content and options

Hi,

I try to prepare an .MP4 file such that my camera (Panasonic LX100) is willing to replay it.
As an supposedly easy first attempt I tried to re-mux an existing video clip the camera recorded using MP4Box, experimenting with options such that the output file would not differ from the input file.

The options that yield the "least visible difference" for the output of MP4Box -info for me are:

MP4Box -brand mp42:1 -no-iod -no-sys -add P1000457.MP4 P1000999.MP4

(You can download the (3.5 MB) sample video file here: http://filebin.ca/1knlOxMESIbK/P1000457.MP4 )

Unluckily, the resulting file P1000999.MP4 still shows at least one significant difference:

 * Movie Info *
-       Timescale 90000 - Duration 00:00:02.880
+       Timescale 600 - Duration 00:00:02.880

... and this may well be the reason why the camera is unwilling to replay it.

I've tried all sorts of options, including the :timescale=... and :rescale=... syntax, but nothing seems to keep MP4Box from using "Timescale 600" in the output file, as displayed under "* Movie Info *".

Is there some possibility to avoid this and use the original Timescale 90000? Or is this just a bug in MP4Box?

For reference, here's the full output of "-info" for the input file:

MP4Box -info P1000457.MP4 
* Movie Info *
        Timescale 90000 - Duration 00:00:02.880
        2 track(s)
        Fragmented File: no
        File suitable for progressive download (moov before mdat)
        File Brand mp42 - version 1
        Created: GMT Tue Dec 16 06:37:43 2014
        Modified: GMT Tue Dec 16 06:37:43 2014

File has no MPEG4 IOD/OD

Track # 1 Info - TrackID 1 - TimeScale 90000 - Media Duration 00:00:02.880
Track has 1 edit lists: track duration is 00:00:02.880
Media Info: Language "und (und)" - Type "vide:avc1" - 72 samples
Visual Track layout: x=0 y=0 width=1280 height=720
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 1280 x 720
        AVC Info: 1 SPS - 1 PPS - Profile High @ Level 3.1
        NAL Unit length bits: 32
        Pixel Aspect Ratio 1:1 - Indicated track size 1280 x 720
        Chroma format 1 - Luma bit depth 8 - chroma bit depth 8
Self-synchronized

Track # 2 Info - TrackID 2 - TimeScale 48000 - Media Duration 00:00:02.922
Track has 1 edit lists: track duration is 00:00:02.880
Media Info: Language "und (und)" - Type "soun:mp4a" - 137 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

[Android] Stream freeze at seemingly random times.

When playing a stream on Android, it freezes after some time for about 30 seconds then starts again. I cannot reproduce it on PC and I cannot reproduce it on the Osmo4Android build because of issue 46. It might be a kind of race condition as it's harder to reproduce when activating logs and easier to reproduce with GF_TERM_NO_DECODER_THREAD. Note that on Android, its using GF_TERM_NO_COMPOSITOR_THREAD as its the jvm thread that's doing the blitting.

Here are links to two traces: https://www.dropbox.com/s/3v0kvv4y6lfxsx5/gpac-log-before.gz?dl=0, https://www.dropbox.com/s/yl1dm2kp938ikvb/gpac-log-after.gz?dl=0. In the before trace, at the end the problem is happening. You can see that there are no more ffmpeg decoder traces. In the after traces the first ffmpeg traces are where the stream started playing again.

[HEVC] [MP4Box] Wrong error while importing raw HEVC (.h265) into .mp4.

Hi!

I noticed that MP4Box (GPAC rev 5612, 64-bit, Windows), when importing raw .h265 into .mp4, shows this error:

CMD> mp4box -add 720p.h265 720p.mp4
[Importer] Unknown input file type for "720p.h265"
[Importer] Unknown input file type for "720p.h265"
Error importing 720p.h265: Corrupted Data in file/stream

Changing the file extension from .h265 to .265 solves the issue, but by looking at other raw formats and their extensions using CMD> mp4box -h format, I guess the .h265 extension must be supported as well.

GPAC on Mac: write a COCOA render module

http://nshipster.com/the-death-of-cocoa/

MPD for single-file representation uses <SegmentBase> for media file and <RepresentationIndex> is broken because <SegmentBase> isn't a folder

Sorry for the long title. I created a MPD like this:

MP4Box -dash 30000 ~/Videos/Lifting_Off_4K.ts ~/Videos/Lifting_Off.1080p.ts \
    ~/Videos/Lifting_Off.360p.ts -out lifting-off.mpd \
    -profile 'dashavc264:onDemand'

And it created 3 representations like this:

<Representation id="1" mimeType="video/mp2t" width="3840" height="2160" audioSamplingRate="48000" codecs="avc1.640033,mp4a.40.02" startWithSAP="1" bandwidth="24527754">
 <BaseURL>Lifting_Off_4K_dash1.ts</BaseURL>
 <SegmentBase>
  <RepresentationIndex sourceURL="Lifting_Off_4K_dash.six"/>
 </SegmentBase>
</Representation>

If I'm reading this correctly, the MPD is saying that the index is at Lifting_Off_4K_dash1.ts/Lifting_Off_4K_dash.six. I don't see any special cases for when <BaseURL> is a file, so I think MP4Box is wrong here.

add a config.log to the configure script

MP4Client Osmo4 dose not support newer iphone device.

I had trying install Osmo4 in my iphone5s. It just show in a small are of screen. And touch the screen the coordinates mismatched. Can you tell me how to build it for newer iphone device. Thank you

Default window width is smaller than GUI width

At least on Linux, during the first start of the player (no .gpacrc)

MP4Box: TTML (EBU-TT-D) mimeType looks wrong

When dashing a EBU-TT-D subtitle track, the generated MPD seems to have the wrong value for the mime type minetype="video/mp4"

The DVB spec: 7 DASH Specific Aspects for Subtitles , The signalling of subtitling codecs for the codec parameter uses RFC6381 [6] as shown in the Table 10:

minetype=application/mp4

check pkgconfig for static libgpac

Apparently we don't fill it correctly. Also see https://sourceforge.net/p/gpac/bugs/341/

Useless code or bug

Hello,

Browsing the code, I found that in stbl_read.c (line 221) :
if (stts->r_FirstSampleInEntry == 1)
stts->r_FirstSampleInEntry = 1;

Best Regards,

"isLeading" flag set to zero for all samples when re-muxing file

(This is a followup to issue #28 - but regarding another difference between original and re-muxed file:)

I try to prepare an .MP4 file such that my camera (Panasonic LX100) is willing to replay it.
As an supposedly easy first attempt I tried to re-mux an existing video clip the camera recorded using MP4Box, experimenting with options such that the output file would not differ from the input file.

The options that yield the "least visible difference" for the output of MP4Box -info for me are:

MP4Box -brand mp42:1 -no-iod -no-sys -add P1000457.MP4 P1000999.MP4

(You can download the (3.5 MB) sample video file here: http://filebin.ca/1knlOxMESIbK/P1000457.MP4 )

After issue #28 was fixed, there is no more difference between original and re-muxed file when looking at the output of MP4Box -info .... But still, the camera is unwilling to play the re-muxed file, so I looked for other relevant differences, and found one in the outputs of MP4Box -dts P1000457.MP4 and MP4Box -dts P1000999.MP4: The "isLeading" flag in the MP4Box written file is set to zero for all samples, while it is set to one for many samples in the original file.

First lines from the -dts dump of the original file:

#dumping track ID 1 timing: Num DTS CTS Size RAP Offset isLeading DependsOn DependedOn Redundant RAP-SampleGroup Roll-SampleGroup Roll-Distance
Sample 1    DTS 0   CTS 10800   91026   1   131080  1   0   0   0   0   0   0
Sample 2    DTS 3600    CTS 3600    41698   0   222106  0   0   2   0   0   0   0
Sample 3    DTS 7200    CTS 7200    35217   0   263804  0   0   2   0   0   0   0
Sample 4    DTS 10800   CTS 21600   59639   0   299021  1   0   0   0   0   0   0
Sample 5    DTS 14400   CTS 14400   34361   0   358660  0   0   2   0   0   0   0
Sample 6    DTS 18000   CTS 18000   35938   0   393021  0   0   2   0   0   0   0
Sample 7    DTS 21600   CTS 32400   62280   0   428959  1   0   0   0   0   0   0
Sample 8    DTS 25200   CTS 25200   36409   0   491239  0   0   2   0   0   0   0
Sample 9    DTS 28800   CTS 28800   36394   0   527648  0   0   2   0   0   0   0
Sample 10   DTS 32400   CTS 43200   62392   0   564042  1   0   0   0   0   0   0

First lines from the -dts dump of the MP4Box writte file (as cited above):

#dumping track ID 1 timing: Num DTS CTS Size RAP Offset isLeading DependsOn DependedOn Redundant RAP-SampleGroup Roll-SampleGroup Roll-Distance
Sample 1    DTS 0   CTS 10800   91026   1   2776    0   0   0   0   0   0   0
Sample 2    DTS 3600    CTS 3600    41698   0   93802   0   0   2   0   0   0   0
Sample 3    DTS 7200    CTS 7200    35217   0   135500  0   0   2   0   0   0   0
Sample 4    DTS 10800   CTS 21600   59639   0   170717  0   0   0   0   0   0   0
Sample 5    DTS 14400   CTS 14400   34361   0   230356  0   0   2   0   0   0   0
Sample 6    DTS 18000   CTS 18000   35938   0   264717  0   0   2   0   0   0   0
Sample 7    DTS 21600   CTS 32400   62280   0   300655  0   0   0   0   0   0   0
Sample 8    DTS 25200   CTS 25200   36409   0   362935  0   0   2   0   0   0   0
Sample 9    DTS 28800   CTS 28800   36394   0   399344  0   0   2   0   0   0   0
Sample 10   DTS 32400   CTS 43200   62392   0   435738  0   0   0   0   0   0   0

I guess that the different offsets might be irrelevant, but the difference in "isLeading" looks fishy, doesn't it?

[DASH] Representation.SegmentList is not supported by DASH-AVC/264.

Hi!

While creating DASH media using MP4Box (GPAC rev 5572), I noticed that when I don't specify the "-segment-name" parameter, and the DASH-AVC/264 live profile is used, then I get Representation.SegmentList elements in the MPD. But according to DASH-AVC/264 Interoperability Points v2.0 - "If the Representation.SegmentList is present in a Representation element then this Representation element may be ignored". And media with such MPD doesn't even work in dash.js 1.2.0.

I also checked other profiles, and what I got is (format: profile - element in the Representation - playback status in dash.js 1.2.0):

• dashavc264:live - SegmentList - FAIL
• dashavc264:onDemand - SegmentBase - OK
• live - SegmentTemplate - OK
• onDemand - SegmentBase - OK

So, instead of using SegmentList, SegmentTemplate (like in the "live" case, or while using the "-segment-name" parameter) must be used.

[HEVC] [MP4Box] Supported raw formats don't mention HEVC.

Hi!

I noticed that MP4Box (GPAC rev 5612, 64-bit, Windows) doesn't show that it can HEVC. So, when doing CMD> mp4box -h format, the list doesn't contain anything about HEVC.

I faced with this problem when I was trying to work with a .h265 file. MP4Box was reporting me that the file is corrupted (#39). It was surprising to me, since on the GPAC's web-site I saw that HEVC is supported. So, when I took a look at the supported formats, I didn't find anything related to HEVC. Although by looking at other supported formats (their extensions), I changed the extension of my file to .265, and the file was processed without any problems.

So, it would be nice if CMD> mp4box -h format would show that HEVC is supported, and which its extensions are known.

And one more thing related to this issue: the section header for supported raw formats and header has too many "p"-s in the word "supported".

Playing from cache should work when not connected to a network

When playing DASH content and keeping files in cache:
[DASH]
KeepFiles=yes
MemoryStorage=no

[Downloader]
CleanCache=no

Replay of the same URL when disconnected from a network should work, at least until no new segment is needed.

Can MP4Box write "udta" atoms into the "moov" section?

I am still trying to convince my camera to replay an .MP4 file it recorded which I then re-muxed with MP4Box (as mentioned in issues #28 and #29 ). It seems that the one relevant remaining difference between the original and the re-muxed file is that the original contains a "udta" atom inside the "moov" section (hex "00 01 00 00 75 64 74 61" + 65528 bytes of data) that contains some camera vendor specific stuff, I can see the camera model name in there as well as a JFIF preview-image of the video.

Now I wonder: Is there a feature available in MP4Box to insert such an "udta" atom into the "moov" section of the output file? If not, could one be implemented? (Just copying a blob from some binary input file into the "udta" atom should be sufficient.)

Add HLSv4+ input support

MP4Client retains frame when being minimized

... then it plays back as fast as possible to catch up with live!

Long videos don't play to end, due to sum of segment lengths > video duration

I have an hour long video, and I noticed the last few seconds are not being played. (I am using the DASH-IF player after using mp4box to segment the video). I use the segment timeline option, so I summed up all the segment durations to be 3581 seconds, although the original video is 3575 seconds.

I assume the video doesn't play to the end because the player thinks it has reached the end of the video, based on the video duration of 3575 seconds. (I verified segments up to #1917 are requested, although mp4box generated 1919 segments). If I manually edit the duration to match the sum of the segments, the video plays to the end. But that seems like such a hack to me, and is a pain if I need to fix other long videos.

How can the sum of the segments exceed the video duration? Is it possible the video duration is inaccurate?

I attached the generated .mpd file. (Needed to change the extension to make it uploadable).