Is it possible to write raw video / audio streams to an MP4 container, as well as parsing them out?
If not, is adding that functionality within the realm of possibility?

I noticed in the network session in Chrome that there are requests that simply being requested twice.

after debugging a bit I have seen that in downloader.setCallback there is the line:

var nextStart = mp4box.appendBuffer(response) return with response.usedByets = chunkSize in the first cycle and nextStart is does not change.
Then there is another download of the same segment only response.usedByets = 0.
Only after that nextStart is changed to the next chunk...

Why is that?

Do you think it is possible to combine the two and create a simple dash player (only one bit rate) with the (roughly) following steps:

1. Get the non-fragmented source and create an .mpd (of the fragmented) file from it.
2. Replace the source with the .mpd file.
3. Override fragmentLoader.js of dash.js so that when trying to download a segment it will download the matching parts of the non-fragmented mp4 pass it to mp4box and get the correct chunks to as a respond.

What do you think? is there a way to combine the two projects?
That is - to utilize the strength of dash.js with playing a stream (even with only one bit rate) with the possibility of creating the fragmented file on the fly?

Issue raised by @Ayms in #12. Creating a separate issue for better tracking.

Happens the videos in the demo page.
When seeking to a downloaded range and also to an undownloaded range.

I don't remember it was always so jittery...

It would help a lot if seek would return the range of the segment instead of the ony the starting offset incase I want to download only the needed segment.

What do you think?

Probably something forgotten, the pad function is not defined in the repo

Probably a typo:

DataStream = --> var DataStream =
VTTin4Parser = --> var VTTin4Parser =
TTMLin4Parser = --> var TTMLin4Parser =

mp4box.onSamples() will always receive a list of nbSamples samples, regardless of which ones are RAPs. The script below will reproduce the problem.

window.onload = function() {
var mp4box = new MP4Box();
mp4box.onError = function(e) {};
mp4box.onReady = function(info) {
videoTrackID = info.videoTracks[0].id;
mp4box.setExtractionOptions(videoTrackID, null, {nbSamples:10, rapAlignement:true});
};
mp4box.onSamples = function(id, user, samples) {
console.log("Received "+samples.length+" samples on track "+id+" for object "+user);
console.log(samples);
}
var downloader = new Downloader();
downloader.setUrl("https://dl.dropboxusercontent.com/u/7245016/bug_buck_bunny_trailer.mp4")
downloader.setCallback(function(response, eof) {
mp4box.appendBuffer(response);
mp4box.flush();
});
downloader.getFile();
}

Add the bitrate info in the info arguments for videos.

Some results indicate that bit manipulation using DataView is not efficient:
http://jsperf.com/dataview-vs-typed-array-views
https://groups.google.com/forum/#!topic/dashjs/5PmEkjKILDQ (dash.js member-only)

We should reconsider the use of DataView, ie. the use of DataStream.

Is this code already usable in real life scenarios?

Related to #16 (#16 (comment)), moov not detected.

Please see the screenshot below of mp4box.js debug, first one is the not working case with strange names for the boxes, second one is the working case:

Details sent by email.

This issue was raised by @Ayms in #12. Creating a separate issue for easier tracking.

Is it possible to write a validation function so that an app can call it to validate that a file can be parsed by mp4box and if not the app can act accordingly.

I think it would be very helpful - what do you guys think?

Gets the initial value every time (a very small index - 56000). I'm using this video https://a0.muscache.com/airbnb/static/Paris-P1-1.mp4

Any ideas why?

Is it possible to write a validation function so that an app can call it to validate that a file can be parsed by mp4box and if not the app can act accordingly.

I think it would be very helpful - what do you guys think?

Related to #16 stop/restart

Tested with Peersm and http://download.tsi.telecom-paristech.fr/gpac/mp4box.js/

As you can see on the screenshot the average rate for Peersm to retrieve the data before passing it to mp4box is 1 Mbps, the rate for mp4box to issue segments continuously decreases (14650 bps after 49838 s on the screenshot)

There is no memory leak but maybe there is an excessive number of JSArrayBufferData and some lookup inside them are causing the performance problem.

Im am converting something which works, https://github.com/ericwooley/StreamTor/blob/master/app/utils/videostream.js (line 142 works)

to a class which is more manipulatable.
https://github.com/ericwooley/StreamTor/blob/master/app/VideoQueue.js (line 165, is the problem)

The problem I am having is that mp4Box.append buffer returns the end of the file, instead of the offset. I can't figure out what is happening differently in the two files. Any help would be appreciated

Request by @KozhinM at https://groups.google.com/forum/#!topic/dashjs/5PmEkjKILDQ

Apparently it depends on the size of the chunks, to reproduce set for example downloader.chunkSize = 10000;

I would like to use Mp4Box with FileReader.
I tried following code.

  var reader = new FileReader();
  var mp4box = new MP4Box();

  mp4box.onError = function(e) { console.log("mp4box failed to parse data."); };
  mp4box.onMoovStart = function (info) {
    console.log(info);
    reader.abort();
  }

  var append_data_to_mp4box = function(event) {
    var arraybuffer = event.target.result;
    arraybuffer.fileStart = event.loaded;   // adding fileStart property
    mp4box.appendBuffer(ab);
  }

  reader.onloadstart = append_data_to_mp4box;
  reader.onprogress = append_data_to_mp4box;
  reader.onloadend = append_data_to_mp4box;

  // Read in the mp4 video as ArrayBuffer
  reader.readAsArrayBuffer(file);

There are no error messages and erro callback, but onMoovStart() is never called.
Could someone tell me how to do ?

consider the following scenario

1. seek to the middle of the video
2. seek to the end of the video (the last chunk is downloaded)
3. seek to the middle of the video again

result - the nextParsePosition returns from append is always the end of the file even though I have appended the middle of the video.

analyzer: http://download.tsi.telecom-paristech.fr/gpac/mp4box.js/filereader.html

I'm trying to use MP4Box.js to extract information like bitrate and codecs. But many videos can't be parsed. The files also don't work on your test site:
http://download.tsi.telecom-paristech.fr/gpac/mp4box.js/filereader.html

Here's one small video file demonstrating the problem:
http://www1.inf.tu-dresden.de/~s1445051/necrodancer_teaser.mp4

One always gets:
TypeError: c is undefined
"[BoxParser]" "Not enough data in stream to parse the entire "inf" box

As it turns out, if one starts this box one byte earlier, all works fine. Here an ugly hack doing this:

diff --git a/src/box.js b/src/box.js
index 4f78ca0..63221c8 100644
--- a/src/box.js
+++ b/src/box.js
@@ -152,6 +152,15 @@ var BoxParser = {
                }
                var size = stream.readUint32();
                var type = stream.readString(4);
+
+               //HACK: 'minf' is shifted one byte, move one byte up and read again
+//             console.log(type);
+               if(type.startsWith("inf")){
+                       stream.seek(start-1);
+                       size = stream.readUint32();
+                       type = stream.readString(4);
+               }
+
                Log.d("BoxParser", "Found box of type "+type+" and size "+size+" at position "+start+" in the current buffer ("+(stream.buffer.fileStart+start)+" in the file)");
                hdr_size = 8;
                if (type == "uuid") {

There is significant performance changes when using different parameters (mainly different chunk size and different segment duration) - By performance I mean load time of the video and seek durations.

i.e when reducing the segment duration the video loads faster but can be stuck very fast. when increasing it, it takes time for the video to load but when it starts playing it should be Ok.

What would be a good way to decide the optimum for a specific video?

It seems like mp4 files which have the header info at the back of the file are not supported by the demo? I'm not sure if this is intentional, if so, please ignore.

I have a file multitrack-original.mp4. When I run the demo page on that file, it will read track info correctly, but it will never start playing. From the logs, it looks like it thinks the file has already been downloaded completely (maybe due to "Next buffer to fetch should have a fileStart position of 22087486"?).

These are the logs for running the demo on this file:

 [0:00:00.138] [MSE] Source opened
Log.js:27 [0:00:07.219] [Downloader] Starting file download
Log.js:27 [0:00:07.219] [Downloader] Resuming file download
Log.js:27 [0:00:07.220] [Downloader] Fetching multitrack-original.mp4 with range: bytes=0-999999
Log.js:27 [0:00:07.382] [Downloader] Received data range: bytes 0-999999/22087486
Log.js:32 [0:00:07.386] [BoxParser] Not enough data in stream to parse the entire "mdat" box
Log.js:27 [0:00:07.386] [Downloader] Next download scheduled in 1000 ms.
Log.js:27 [0:00:08.388] [Downloader] Fetching multitrack-original.mp4 with range: bytes=21914920-22914919
Log.js:27 [0:00:08.416] [Downloader] Received data range: bytes 21914920-22087485/22087486
Log.js:32 [0:00:08.429] [ISOFile] Duplicate Box of type: free, ignoring previous occurrences
Log.js:27 [0:00:08.429] [Application] Starting to parse movie information
Log.js:27 [0:00:08.464] [Application] Movie information received
Log.js:27 [0:00:08.464] [Downloader] Stopping file download
Log.js:27 [0:00:08.466] [MP4Box] Next buffer to fetch should have a fileStart position of 22087486
Log.js:27 [0:00:08.467] [MP4Box] Flushing remaining samples
Log.js:27 [0:00:10.698] [MSE - SourceBuffer #1] Creation with type 'video/mp4; codecs="avc1.4d4028"'
Log.js:27 [0:00:11.490] [MSE - SourceBuffer #3] Creation with type 'video/mp4; codecs="mp4a.40.2"'
Log.js:27 [0:00:17.985] [MSE - SourceBuffer #1] Appending initialization data
Log.js:27 [0:00:17.986] [MSE - SourceBuffer #3] Appending initialization data
Log.js:27 [0:00:17.988] [MSE - SourceBuffer #1] Init segment append ended, updating: false, buffered: (empty), pending: 0
Log.js:27 [0:00:17.989] [MSE - SourceBuffer #3] Init segment append ended, updating: false, buffered: (empty), pending: 0
Log.js:27 [0:00:20.899] [Downloader] Resuming file download
Log.js:27 [0:00:20.899] [Downloader] File download done.
Log.js:27 [0:00:20.899] [MP4Box] Flushing remaining samples

When I process the file using a tool like MetaData Mover to move the metadata to the beginning of the file, the demo works and the output becomes

[0:00:00.266] [MSE] Source opened
Log.js:27 [0:02:19.726] [Downloader] Starting file download
Log.js:27 [0:02:19.726] [Downloader] Resuming file download
Log.js:27 [0:02:19.727] [Downloader] Fetching multitrack.mp4 with range: bytes=0-999999
Log.js:27 [0:02:19.762] [Downloader] Received data range: bytes 0-999999/22194256
Log.js:32 [0:02:19.777] [BoxParser] Not enough data in stream to parse the entire "mdat" box
Log.js:27 [0:02:19.778] [Application] Starting to parse movie information
Log.js:27 [0:02:19.799] [Application] Movie information received
Log.js:27 [0:02:19.799] [Downloader] Stopping file download
Log.js:27 [0:02:19.801] [MP4Box] Next buffer to fetch should have a fileStart position of 1000000
Log.js:27 [0:02:24.107] [MSE - SourceBuffer #1] Creation with type 'video/mp4; codecs="avc1.4d4028"'
Log.js:27 [0:02:25.075] [MSE - SourceBuffer #3] Creation with type 'video/mp4; codecs="mp4a.40.2"'
Log.js:27 [0:02:27.543] [MSE - SourceBuffer #1] Appending initialization data
Log.js:27 [0:02:27.544] [MSE - SourceBuffer #3] Appending initialization data
Log.js:27 [0:02:27.545] [MSE - SourceBuffer #1] Init segment append ended, updating: false, buffered: (empty), pending: 0
Log.js:27 [0:02:27.546] [MSE - SourceBuffer #3] Init segment append ended, updating: false, buffered: (empty), pending: 0
Log.js:27 [0:02:30.300] [Downloader] Resuming file download
Log.js:27 [0:02:30.300] [Downloader] Fetching multitrack.mp4 with range: bytes=1000000-1999999
Log.js:27 [0:02:30.352] [Downloader] Received data range: bytes 1000000-1999999/22194256
Log.js:27 [0:02:30.418] [MP4Box] Next buffer to fetch should have a fileStart position of 2000000
Log.js:27 [0:02:30.418] [Downloader] Next download scheduled in 1000 ms.
Log.js:27 [0:02:31.420] [Downloader] Fetching multitrack.mp4 with range: bytes=2000000-2999999
Log.js:27 [0:02:31.470] [Downloader] Received data range: bytes 2000000-2999999/22194256
Log.js:27 [0:02:31.485] [MP4Box] Next buffer to fetch should have a fileStart position of 3000000
Log.js:27 [0:02:31.485] [Downloader] Next download scheduled in 1000 ms.
Log.js:27 [0:02:32.485] [Downloader] Fetching multitrack.mp4 with range: bytes=3000000-3999999
Log.js:27 [0:02:32.525] [Downloader] Received data range: bytes 3000000-3999999/22194256
Log.js:27 [0:02:32.534] [MP4Box] Next buffer to fetch should have a fileStart position of 4000000
Log.js:27 [0:02:32.536] [Downloader] Next download scheduled in 1000 ms.
Log.js:27 [0:02:33.542] [Downloader] Fetching multitrack.mp4 with range: bytes=4000000-4999999
Log.js:27 [0:02:33.610] [Downloader] Received data range: bytes 4000000-4999999/22194256
Log.js:27 [0:02:33.620] [MP4Box] Next buffer to fetch should have a fileStart position of 5000000
Log.js:27 [0:02:33.620] [Downloader] Next download scheduled in 1000 ms.
Log.js:27 [0:02:34.622] [Downloader] Fetching multitrack.mp4 with range: bytes=5000000-5999999
Log.js:27 [0:02:34.682] [Downloader] Received data range: bytes 5000000-5999999/22194256
Log.js:27 [0:02:34.690] [MP4Box] Sending fragmented data on track #1 for samples [0,999]
Log.js:27 [0:02:34.692] [Application] Received new segment for track 1 up to sample #1000, segments pending append: 1
Log.js:27 [0:02:34.692] [MSE - SourceBuffer #1] Update ended, updating: false, buffered: (empty), pending: 1
...

Maybe the origin of #4 , mp4box should free all the resources on close.

since eaa50ad
the export is like this

if (typeof exports !== 'undefined') {
    exports.MP4Box = MP4Box;    
}

I noticed some old libs were depending on old versions, so I tried updating and found that none of them imported correctly.

It might be too late, because you don't want to make a breaking change but I think it should be exported like this:

if (typeof exports !== 'undefined') {
    exports = MP4Box;   
}

Unless you are now exporting multiple things.

So i'm trying to appendBuffer a mp4 array buffer but the box is undefined at box-parser.js line 37. The video plays inside the browser and on Windows 8.1's video player.

Here's the video we used:
https://mega.co.nz/#!3RdyjK7R!uuG7lHDrDQDcuY5YoqkRuI9HVaJBSzLWEgqVyqqJQxc

And a snippet of code we used:

var file = response.response;
file.fileStart = 0;
mp4Box.appendBuffer(file);

Since I'm extensively testing the demo app behaviour and benchmarks on many videos these days, I have decided to open an issue that will have all the videos that I found that are not working.

If anyone knows why / has more videos to share , please comment here.

This is the first one
http://content.jwplatform.com/videos/HkauGhRi-640.mp4

Hi,
I have been trying to integrate mp4box into dash.js project. I encountered two issues while trying to parse sidx box:

1. It seems that ref.size property in the following piece of code is calculated incorrectly:

    //file: box-parse.js 
    //method: BoxParser.sidxBox.prototype.parse

    ref.size = tmp_32 & 0x8FFFFFFF;

I observe that ref.size has negative value. I peeped at the other parsing lib and it seems that a correct formula is:
ref.size = tmp_32 & 0x7FFFFFFF;
2. The size of the sidx box appears to be calculated incorrectly. To be more precise: in the code below an initial size value seem to be correct, but then it is reduced by hdr_size

    // file: box.js
    //method: parseOneBox

    if (BoxParser[type+"Box"]) {
        box = new BoxParser[type+"Box"](size - hdr_size);       
    } else {

Then in it is reduced once again:

    // file: box-parse.js
    // method: BoxParser.FullBox.prototype.parseFullHeader

    this.size -= 4;

For example, for the following media file the first sidx box should have size = 100, instead it is 88:
http://dash.edgesuite.net/dash264/TestCases/1a/sony/DASH_vodaudio_Track5.m4a

So-- why are the Audio and Video split, and added to their own SourceBuffer? Why can't the segments be both streams?

MP4Box.prototype.getInfo
track.codec = sample_desc.getCodec();
--> undefined is not a function

I send you separately the video link

To reproduce it with the demo link, set downloader.chunkSize=498

Load the first demo link and watch the memory use for this Chrome tab, it does increase very fast.

It's not that obvious with bigger size of chunks but if you reset/restart a video on the same page you can see that memory keeps increasing.

Apparently something is not correctly gced, taking a snapshot in Chrome shows that it might be related to 'compiled code' (BoxParser.FullBox ??)

stco.chunk_offsets in buildSampleLists or resetTables

According to the code stco is supposed to be mandatory, but I got this error with a file formated with GPAC apparently (please email me if you want the link)

using chrome on OS X, its so jitter when seeking
when using chrome on windows, audio track load first，and video track lag behind

The CTS of samples seem to calculated incorrectly. I've had this problem with every MP4 I've tried.

I'm mostly interested in sample.cts-sample.dts for any given sample, and interestingly, it looks like I can get the correct value for sample i by doing samples[i+1].cts - samples[i+1].dts.

For the same video track, these are the first samples reported by mp4box.js:
Sample 1 DTS 0 CTS 7507
Sample 2 DTS 3753 CTS 11260
Sample 3 DTS 7507 CTS 22522
Sample 4 DTS 11260 CTS 18767
Sample 5 DTS 15014 CTS 15014
Sample 6 DTS 18768 CTS 33783
Sample 7 DTS 22522 CTS 30029
Sample 8 DTS 26275 CTS 26275

and these are the samples reported by doing MP4Box -dts:
Sample 1 DTS 0 CTS 7507
Sample 2 DTS 3753 CTS 18768
Sample 3 DTS 7507 CTS 15014
Sample 4 DTS 11260 CTS 11260
Sample 5 DTS 15014 CTS 30029
Sample 6 DTS 18768 CTS 26275
Sample 7 DTS 22522 CTS 22522
Sample 8 DTS 26275 CTS 33783

I often get both in the demo app and in my own app an error in Datastream.memcpy
"Source is too large"

Did someone else experienced that and knows the reason?

It's working better, the video starts playing well, but then...back to #10... after 1mn the sound continues playing but the image freezes

Please see:

I supposed the codecs are supported by Chrome (?? if not it would not play at all)

And my logs, you can see the begining of the segments being appended in utf8/hex formats, please let me know if you need yours (or if you suspect that it can be an issue in Peersm but as far as I can see everything looks normal):

db_query/db_connected 1686 ms 674 Thu Sep 04 2014 16:58:29 GMT+0200 (Paris, Madrid (heure d’été))
init_media video/mp4 Thu Sep 04 2014 16:58:29 GMT+0200 (Paris, Madrid (heure d’été))
start_t0 received 1409842735672 Thu Sep 04 2014 16:58:55 GMT+0200 (Paris, Madrid (heure d’été))
moov start Thu Sep 04 2014 16:58:56 GMT+0200 (Paris, Madrid (heure d’été))
992472 bps nbBlocs 84 stream window 84 - sending sendme stream received 456168 - Buffer Amount: 0 1409842739350 Thu Sep 04 2014 16:58:59 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18678 stream length 498 Thu Sep 04 2014 16:58:59 GMT+0200 (Paris, Madrid (heure d’été))
996256 bps nbBlocs 85 stream window 85 - sending sendme stream received 953670 - Buffer Amount: 0 1409842743332 Thu Sep 04 2014 16:59:03 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18660 stream length 498 Thu Sep 04 2014 16:59:03 GMT+0200 (Paris, Madrid (heure d’été))
997448 bps nbBlocs 85 stream window 85 - sending sendme stream received 1451670 - Buffer Amount: 0 1409842747316 Thu Sep 04 2014 16:59:07 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18655 stream length 498 Thu Sep 04 2014 16:59:07 GMT+0200 (Paris, Madrid (heure d’été))
997904 bps nbBlocs 85 stream window 85 - sending sendme stream received 1949670 - Buffer Amount: 0 1409842751303 Thu Sep 04 2014 16:59:11 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18654 stream length 498 Thu Sep 04 2014 16:59:11 GMT+0200 (Paris, Madrid (heure d’été))
998432 bps nbBlocs 85 stream window 85 - sending sendme stream received 2447670 - Buffer Amount: 0 1409842755285 Thu Sep 04 2014 16:59:15 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18652 stream length 498 Thu Sep 04 2014 16:59:15 GMT+0200 (Paris, Madrid (heure d’été))
999120 bps nbBlocs 85 stream window 85 - sending sendme stream received 2945670 - Buffer Amount: 0 1409842759259 Thu Sep 04 2014 16:59:19 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18649 stream length 498 Thu Sep 04 2014 16:59:19 GMT+0200 (Paris, Madrid (heure d’été))
999320 bps nbBlocs 85 stream window 85 - sending sendme stream received 3443670 - Buffer Amount: 0 1409842763241 Thu Sep 04 2014 16:59:23 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18648 stream length 498 Thu Sep 04 2014 16:59:23 GMT+0200 (Paris, Madrid (heure d’été))
999440 bps nbBlocs 85 stream window 85 - sending sendme stream received 3941670 - Buffer Amount: 0 1409842767224 Thu Sep 04 2014 16:59:27 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18648 stream length 498 Thu Sep 04 2014 16:59:27 GMT+0200 (Paris, Madrid (heure d’été))
play media mp4box ready Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
mp4box mime: video/mp4; codecs=" avc1.640029" Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
mp4box mime: video/mp4; codecs=" mp4a.40.2" Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
init length 2 Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
init segment track 1 1261 Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 1261 �ftypisom�isom��moovlmvhd�������X���� Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 1261 000000146674797069736f6d0000000169736f6d000004d96d6f6f760000006c6d76686400000000d005eaa6d005eaa60000 Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
init segment track 2 1141 Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 1141 �ftypisom�isom�amoovlmvhd�������X���� Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 1141 000000146674797069736f6d0000000169736f6d000004616d6f6f760000006c6d76686400000000d005eaa6d005eaa60000 Thu Sep 04 2014 16:59:30 GMT+0200 (Paris, Madrid (heure d’été))
979816 bps nbBlocs 83 stream window 83 - sending sendme stream received 4440666 - Buffer Amount: 0 1409842771930 Thu Sep 04 2014 16:59:31 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18729 stream length 498 Thu Sep 04 2014 16:59:31 GMT+0200 (Paris, Madrid (heure d’été))
999376 bps nbBlocs 85 stream window 85 - sending sendme stream received 4937670 - Buffer Amount: 0 1409842775200 Thu Sep 04 2014 16:59:35 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18648 stream length 498 Thu Sep 04 2014 16:59:35 GMT+0200 (Paris, Madrid (heure d’été))
999520 bps nbBlocs 85 stream window 85 - sending sendme stream received 5435670 - Buffer Amount: 0 1409842779179 Thu Sep 04 2014 16:59:39 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18648 stream length 498 Thu Sep 04 2014 16:59:39 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 379606 dmoof�mfhdCLtraf�tfhd���tfdt$trun���l�o Thu Sep 04 2014 16:59:40 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379606 dmoof�mfhdCLtraf�tfhd���tfdt$trun���l�o Thu Sep 04 2014 16:59:40 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379606 000000646d6f6f66000000106d66686400000000000000430000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 16:59:41 GMT+0200 (Paris, Madrid (heure d’été))
996792 bps nbBlocs 85 stream window 85 - sending sendme stream received 5933670 - Buffer Amount: 0 1409842783295 Thu Sep 04 2014 16:59:43 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18658 stream length 498 Thu Sep 04 2014 16:59:43 GMT+0200 (Paris, Madrid (heure d’été))
999808 bps nbBlocs 85 stream window 85 - sending sendme stream received 6431670 - Buffer Amount: 0 1409842787136 Thu Sep 04 2014 16:59:47 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18647 stream length 498 Thu Sep 04 2014 16:59:47 GMT+0200 (Paris, Madrid (heure d’été))
999480 bps nbBlocs 85 stream window 85 - sending sendme stream received 6929670 - Buffer Amount: 0 1409842791139 Thu Sep 04 2014 16:59:51 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18648 stream length 498 Thu Sep 04 2014 16:59:51 GMT+0200 (Paris, Madrid (heure d’été))
999800 bps nbBlocs 85 stream window 85 - sending sendme stream received 7427670 - Buffer Amount: 0 1409842795106 Thu Sep 04 2014 16:59:55 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18647 stream length 498 Thu Sep 04 2014 16:59:55 GMT+0200 (Paris, Madrid (heure d’été))
999688 bps nbBlocs 85 stream window 85 - sending sendme stream received 7925670 - Buffer Amount: 0 1409842799098 Thu Sep 04 2014 16:59:59 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18647 stream length 498 Thu Sep 04 2014 16:59:59 GMT+0200 (Paris, Madrid (heure d’été))
999704 bps nbBlocs 85 stream window 85 - sending sendme stream received 8423670 - Buffer Amount: 0 1409842803082 Thu Sep 04 2014 17:00:03 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18647 stream length 498 Thu Sep 04 2014 17:00:03 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 1 4258256 dmoof�mfhdLtraf�tfhd���tfdt$trun���l������ Thu Sep 04 2014 17:00:08 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 4258256 dmoof�mfhdLtraf�tfhd���tfdt$trun���l������ Thu Sep 04 2014 17:00:12 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 4258256 000000646d6f6f66000000106d66686400000000000000000000004c74726166000000107466686400020000000000010000 Thu Sep 04 2014 17:00:16 GMT+0200 (Paris, Madrid (heure d’été))
870976 bps nbBlocs 74 stream window 74 - sending sendme stream received 8927148 - Buffer Amount: 0 1409842817669 Thu Sep 04 2014 17:00:17 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19236 stream length 498 Thu Sep 04 2014 17:00:17 GMT+0200 (Paris, Madrid (heure d’été))
888704 bps nbBlocs 76 stream window 76 - sending sendme stream received 9424152 - Buffer Amount: 549 1409842820508 Thu Sep 04 2014 17:00:20 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19143 stream length 498 Thu Sep 04 2014 17:00:20 GMT+0200 (Paris, Madrid (heure d’été))
903760 bps nbBlocs 77 stream window 77 - sending sendme stream received 9921654 - Buffer Amount: 0 1409842823498 Thu Sep 04 2014 17:00:23 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19069 stream length 498 Thu Sep 04 2014 17:00:23 GMT+0200 (Paris, Madrid (heure d’été))
917704 bps nbBlocs 78 stream window 78 - sending sendme stream received 10419156 - Buffer Amount: 0 1409842826501 Thu Sep 04 2014 17:00:26 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19003 stream length 498 Thu Sep 04 2014 17:00:26 GMT+0200 (Paris, Madrid (heure d’été))
930784 bps nbBlocs 79 stream window 79 - sending sendme stream received 10916658 - Buffer Amount: 3843 1409842829500 Thu Sep 04 2014 17:00:29 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18943 stream length 498 Thu Sep 04 2014 17:00:29 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 379556 dmoof�mfhd��Ltraf�tfhd���tfdt��$trun���l��% Thu Sep 04 2014 17:00:31 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379556 dmoof�mfhd��Ltraf�tfhd���tfdt��$trun���l��% Thu Sep 04 2014 17:00:31 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379556 000000646d6f6f66000000106d666864000000000000061a0000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:00:32 GMT+0200 (Paris, Madrid (heure d’été))
933752 bps nbBlocs 79 stream window 79 - sending sendme stream received 11414658 - Buffer Amount: 0 1409842833469 Thu Sep 04 2014 17:00:33 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18930 stream length 498 Thu Sep 04 2014 17:00:33 GMT+0200 (Paris, Madrid (heure d’été))
944712 bps nbBlocs 80 stream window 80 - sending sendme stream received 11912160 - Buffer Amount: 0 1409842836547 Thu Sep 04 2014 17:00:36 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18880 stream length 498 Thu Sep 04 2014 17:00:36 GMT+0200 (Paris, Madrid (heure d’été))
937696 bps nbBlocs 80 stream window 80 - sending sendme stream received 12410160 - Buffer Amount: 0 1409842841550 Thu Sep 04 2014 17:00:41 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18909 stream length 498 Thu Sep 04 2014 17:00:41 GMT+0200 (Paris, Madrid (heure d’été))
945016 bps nbBlocs 80 stream window 80 - sending sendme stream received 12908160 - Buffer Amount: 0 1409842844946 Thu Sep 04 2014 17:00:44 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18879 stream length 498 Thu Sep 04 2014 17:00:44 GMT+0200 (Paris, Madrid (heure d’été))
954584 bps nbBlocs 81 stream window 81 - sending sendme stream received 13405662 - Buffer Amount: 0 1409842848020 Thu Sep 04 2014 17:00:48 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18836 stream length 498 Thu Sep 04 2014 17:00:48 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 380091 dmoof�mfhd (Ltraf�tfhd���tfdt�@$trun���l�� Thu Sep 04 2014 17:00:50 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 380091 dmoof�mfhd (Ltraf�tfhd���tfdt�@$trun���l�� Thu Sep 04 2014 17:00:51 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 380091 000000646d6f6f66000000106d6668640000000000000c280000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:00:51 GMT+0200 (Paris, Madrid (heure d’été))
956792 bps nbBlocs 81 stream window 81 - sending sendme stream received 13903662 - Buffer Amount: 0 1409842851925 Thu Sep 04 2014 17:00:51 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18827 stream length 498 Thu Sep 04 2014 17:00:51 GMT+0200 (Paris, Madrid (heure d’été))
965168 bps nbBlocs 82 stream window 82 - sending sendme stream received 14401164 - Buffer Amount: 0 1409842855040 Thu Sep 04 2014 17:00:55 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18790 stream length 498 Thu Sep 04 2014 17:00:55 GMT+0200 (Paris, Madrid (heure d’été))
972752 bps nbBlocs 83 stream window 83 - sending sendme stream received 14898666 - Buffer Amount: 0 1409842858201 Thu Sep 04 2014 17:00:58 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18756 stream length 498 Thu Sep 04 2014 17:00:58 GMT+0200 (Paris, Madrid (heure d’été))
980280 bps nbBlocs 83 stream window 83 - sending sendme stream received 15396666 - Buffer Amount: 3843 1409842861324 Thu Sep 04 2014 17:01:01 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18727 stream length 498 Thu Sep 04 2014 17:01:01 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 1 6478780 dmoof�mfhd �Ltraf�tfhd���tfdt�F($trun���l��c��� Thu Sep 04 2014 17:01:08 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 6478780 dmoof�mfhd �Ltraf�tfhd���tfdt�F($trun���l��c��� Thu Sep 04 2014 17:01:13 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 6478780 000000646d6f6f66000000106d6668640000000000000af10000004c74726166000000107466686400020000000000010000 Thu Sep 04 2014 17:01:20 GMT+0200 (Paris, Madrid (heure d’été))
873344 bps nbBlocs 74 stream window 74 - sending sendme stream received 15899148 - Buffer Amount: 0 1409842881312 Thu Sep 04 2014 17:01:21 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19225 stream length 498 Thu Sep 04 2014 17:01:21 GMT+0200 (Paris, Madrid (heure d’été))
881568 bps nbBlocs 75 stream window 75 - sending sendme stream received 16396650 - Buffer Amount: 0 1409842884469 Thu Sep 04 2014 17:01:24 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19181 stream length 498 Thu Sep 04 2014 17:01:24 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 378740 dmoof�mfhd�LLtraf�tfhd���tfdt.�$trun���l��� Thu Sep 04 2014 17:01:26 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 378740 dmoof�mfhd�LLtraf�tfhd���tfdt.�$trun���l��� Thu Sep 04 2014 17:01:27 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 378740 000000646d6f6f66000000106d666864000000000000124c0000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:01:27 GMT+0200 (Paris, Madrid (heure d’été))
884808 bps nbBlocs 75 stream window 75 - sending sendme stream received 16894650 - Buffer Amount: 0 1409842888425 Thu Sep 04 2014 17:01:28 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19165 stream length 498 Thu Sep 04 2014 17:01:28 GMT+0200 (Paris, Madrid (heure d’été))
893472 bps nbBlocs 76 stream window 76 - sending sendme stream received 17392152 - Buffer Amount: 0 1409842891399 Thu Sep 04 2014 17:01:31 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19121 stream length 498 Thu Sep 04 2014 17:01:31 GMT+0200 (Paris, Madrid (heure d’été))
901584 bps nbBlocs 77 stream window 77 - sending sendme stream received 17889654 - Buffer Amount: 0 1409842894412 Thu Sep 04 2014 17:01:34 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19079 stream length 498 Thu Sep 04 2014 17:01:34 GMT+0200 (Paris, Madrid (heure d’été))
909696 bps nbBlocs 77 stream window 77 - sending sendme stream received 18387654 - Buffer Amount: 549 1409842897376 Thu Sep 04 2014 17:01:37 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19043 stream length 498 Thu Sep 04 2014 17:01:37 GMT+0200 (Paris, Madrid (heure d’été))
916848 bps nbBlocs 78 stream window 78 - sending sendme stream received 18885156 - Buffer Amount: 0 1409842900457 Thu Sep 04 2014 17:01:40 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19007 stream length 498 Thu Sep 04 2014 17:01:40 GMT+0200 (Paris, Madrid (heure d’été))
924480 bps nbBlocs 79 stream window 79 - sending sendme stream received 19382658 - Buffer Amount: 0 1409842903401 Thu Sep 04 2014 17:01:43 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18970 stream length 498 Thu Sep 04 2014 17:01:43 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 379967 dmoof�mfhd�TLtraf�tfhd���tfdt>�$trun���l�� Thu Sep 04 2014 17:01:46 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379967 dmoof�mfhd�TLtraf�tfhd���tfdt>�$trun���l�� Thu Sep 04 2014 17:01:46 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379967 000000646d6f6f66000000106d66686400000000000018540000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:01:47 GMT+0200 (Paris, Madrid (heure d’été))
927096 bps nbBlocs 79 stream window 79 - sending sendme stream received 19880658 - Buffer Amount: 0 1409842907225 Thu Sep 04 2014 17:01:47 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18958 stream length 498 Thu Sep 04 2014 17:01:47 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 1 4286510 dmoof�mfhd��Ltraf�tfhd���tfdt��P$trun���l������ Thu Sep 04 2014 17:01:53 GMT+0200 (Paris, Madrid (heure d’été))
915000 bps nbBlocs 78 stream window 78 - sending sendme stream received 20379156 - Buffer Amount: 0 1409842913851 Thu Sep 04 2014 17:01:53 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 19015 stream length 498 Thu Sep 04 2014 17:01:53 GMT+0200 (Paris, Madrid (heure d’été))
920880 bps nbBlocs 78 stream window 78 - sending sendme stream received 20877156 - Buffer Amount: 0 1409842917040 Thu Sep 04 2014 17:01:57 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18989 stream length 498 Thu Sep 04 2014 17:01:57 GMT+0200 (Paris, Madrid (heure d’été))
926208 bps nbBlocs 79 stream window 79 - sending sendme stream received 21374658 - Buffer Amount: 0 1409842920293 Thu Sep 04 2014 17:02:00 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18962 stream length 498 Thu Sep 04 2014 17:02:00 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 380377 dmoof�mfhd�Ltraf�tfhd���tfdtN $trun���l�� Thu Sep 04 2014 17:02:01 GMT+0200 (Paris, Madrid (heure d’été)) appending track 2 380377 dmoof�mfhd�Ltraf�tfhd���tfdtN $trun���l�� Thu Sep 04 2014 17:02:01 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 380377 000000646d6f6f66000000106d6668640000000000001e600000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:02:02 GMT+0200 (Paris, Madrid (heure d’été))
927152 bps nbBlocs 79 stream window 79 - sending sendme stream received 21872658 - Buffer Amount: 0 1409842924402 Thu Sep 04 2014 17:02:04 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18958 stream length 498 Thu Sep 04 2014 17:02:04 GMT+0200 (Paris, Madrid (heure d’été))
930368 bps nbBlocs 79 stream window 79 - sending sendme stream received 22370658 - Buffer Amount: 0 1409842928031 Thu Sep 04 2014 17:02:08 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18944 stream length 498 Thu Sep 04 2014 17:02:08 GMT+0200 (Paris, Madrid (heure d’été))
936056 bps nbBlocs 80 stream window 80 - sending sendme stream received 22868160 - Buffer Amount: 0 1409842931116 Thu Sep 04 2014 17:02:11 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18916 stream length 498 Thu Sep 04 2014 17:02:11 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 379185 dmoof�mfhd$�Ltraf�tfhd���tfdt]�$trun���l�� Thu Sep 04 2014 17:02:14 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379185 dmoof�mfhd$�Ltraf�tfhd���tfdt]�$trun���l�� Thu Sep 04 2014 17:02:14 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379185 000000646d6f6f66000000106d66686400000000000024840000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:02:14 GMT+0200 (Paris, Madrid (heure d’été))
937176 bps nbBlocs 80 stream window 80 - sending sendme stream received 23366160 - Buffer Amount: 0 1409842935133 Thu Sep 04 2014 17:02:15 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18911 stream length 498 Thu Sep 04 2014 17:02:15 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 1 2851085 dmoof�mfhd �Ltraf�tfhd���tfdt-�x$trun���l�� ��� Thu Sep 04 2014 17:02:18 GMT+0200 (Paris, Madrid (heure d’été))
932800 bps nbBlocs 79 stream window 79 - sending sendme stream received 23864658 - Buffer Amount: 3843 1409842940344 Thu Sep 04 2014 17:02:20 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18934 stream length 498 Thu Sep 04 2014 17:02:20 GMT+0200 (Paris, Madrid (heure d’été))
937080 bps nbBlocs 80 stream window 80 - sending sendme stream received 24362160 - Buffer Amount: 0 1409842943656 Thu Sep 04 2014 17:02:23 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18912 stream length 498 Thu Sep 04 2014 17:02:23 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 379903 dmoof�mfhd_�Ltraf�tfhd���tfdtm$trun���l��� Thu Sep 04 2014 17:02:25 GMT+0200 (Paris, Madrid (heure d’été)) appending track 2 379903 dmoof�mfhd_�Ltraf�tfhd���tfdtm$trun���l��� Thu Sep 04 2014 17:02:25 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 379903 000000646d6f6f66000000106d6668640000000000002a8f0000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:02:26 GMT+0200 (Paris, Madrid (heure d’été))
936560 bps nbBlocs 80 stream window 80 - sending sendme stream received 24860160 - Buffer Amount: 3843 1409842948025 Thu Sep 04 2014 17:02:28 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18914 stream length 498 Thu Sep 04 2014 17:02:28 GMT+0200 (Paris, Madrid (heure d’été))
940504 bps nbBlocs 80 stream window 80 - sending sendme stream received 25358160 - Buffer Amount: 0 1409842951372 Thu Sep 04 2014 17:02:31 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18898 stream length 498 Thu Sep 04 2014 17:02:31 GMT+0200 (Paris, Madrid (heure d’été))
945176 bps nbBlocs 80 stream window 80 - sending sendme stream received 25856160 - Buffer Amount: 0 1409842954520 Thu Sep 04 2014 17:02:34 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18878 stream length 498 Thu Sep 04 2014 17:02:34 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 1 1940806 dmoof�mfhd+�Ltraf�tfhd���tfdt=��$trun���l������ Thu Sep 04 2014 17:02:36 GMT+0200 (Paris, Madrid (heure d’été))
onsegment track 2 378750 dmoof�mfhd0�Ltraf�tfhd���tfdt}$trun���l��} Thu Sep 04 2014 17:02:36 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 378750 dmoof�mfhd0�Ltraf�tfhd���tfdt}$trun���l��} Thu Sep 04 2014 17:02:36 GMT+0200 (Paris, Madrid (heure d’été))
appending track 2 378750 000000646d6f6f66000000106d66686400000000000030b90000004c74726166000000107466686400020000000000020000 Thu Sep 04 2014 17:02:36 GMT+0200 (Paris, Madrid (heure d’été))
938456 bps nbBlocs 80 stream window 80 - sending sendme stream received 26354160 - Buffer Amount: 3843 1409842960331 Thu Sep 04 2014 17:02:40 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18906 stream length 498 Thu Sep 04 2014 17:02:40 GMT+0200 (Paris, Madrid (heure d’été))
942448 bps nbBlocs 80 stream window 80 - sending sendme stream received 26852160 - Buffer Amount: 0 1409842963608 Thu Sep 04 2014 17:02:43 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18890 stream length 498 Thu Sep 04 2014 17:02:43 GMT+0200 (Paris, Madrid (heure d’été))
946184 bps nbBlocs 81 stream window 81 - sending sendme stream received 27349662 - Buffer Amount: 0 1409842966913 Thu Sep 04 2014 17:02:46 GMT+0200 (Paris, Madrid (heure d’été))
sendme timeout 18870 stream length 498 Thu Sep 04 2014 17:02:46 GMT+0200 (Paris, Madrid (heure d’été))
send db_end CID 1 sid 1 reason 1 Thu Sep 04 2014 17:02:47 GMT+0200 (Paris, Madrid (heure d’été))
stop streaming Thu Sep 04 2014 17:02:47 GMT+0200 (Paris, Madrid (heure d’été))
execute fin Thu Sep 04 2014 17:02:47 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 4286510 dmoof�mfhd��Ltraf�tfhd���tfdt��P$trun���l������ Thu Sep 04 2014 17:02:54 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 4286510 000000646d6f6f66000000106d66686400000000000015df0000004c74726166000000107466686400020000000000010000 Thu Sep 04 2014 17:02:59 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 2851085 dmoof�mfhd �Ltraf�tfhd���tfdt-�x$trun���l�� ��� Thu Sep 04 2014 17:03:01 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 2851085 000000646d6f6f66000000106d66686400000000000020cd0000004c74726166000000107466686400020000000000010000 Thu Sep 04 2014 17:03:04 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 1940806 dmoof�mfhd+�Ltraf�tfhd���tfdt=��$trun���l������ Thu Sep 04 2014 17:03:06 GMT+0200 (Paris, Madrid (heure d’été))
appending track 1 1940806 000000646d6f6f66000000106d6668640000000000002b940000004c74726166000000107466686400020000000000010000 Thu Sep 04 2014 17:03:08 GMT+0200 (Paris, Madrid (heure d’été))

Here is the scenario.

Play a long (i took a 15 minutes video)video to the end then seek back to the half of the video.

The sourceBuffer (of the video) buffered has only one range in it - [midSecOfVideo,endSecOfVideo] - possibly it is being dropped by the video tag so it won't take too much memory.

Now , when calling MP4Box.prototype.seek seekInfo gets the right seek_info.offset
But this.inputIsoFile.findEndContiguousBuf returns the offset of the end of the video - So , It does not return the needed offset...

And the line smallB = new Uint8Array(newLength); gets an error (mp4Box line 216)

for example for these parametes I get it

b.byteLength = 300001
b.fileEnd = 24298968
b.fileStart = 23998968

ab.bytesLength = 39935
ab.fileEnd = 24157404
ab.fileStart = 24117470

offset = 181499 --> newLength = -141564 --> error

To investigate, whether it's a mistake in my code or an API issue.

The moov segment can be huge, it would be good to have a onMoov event so we can notify a streaming user that things are going well but he needs to wait a little bit.

Resuming a video: the parser should be able to restart from any place (assuming the moov info has been stored somewhere)

Seek is required in almost any VoD use case.
It would be great to have in mp4box.js (great initiative btw)

I ran the demo on ff nightly (37.0a1 (2014-12-28)) with the video - video counter unfragmented.
It seemed to work but it is a bit buggy.

Will keep testing and update - did anyone else tried to test this?