smoothstreaming audio retrieval failed after 6 secondes

[DarkAnakin]

Hi

For some channels audio stop working after some secondes while video still keep working.
I think it will be better to ask now before I dig on the source code to try to find out why, that I know will take me some days.

In the archives below you will find the kodi.log and the manifest file parsed by kodi.
Search for "code 404" to get right away the error or either "vf=" or "vo=" to get the audios fragments downloaded by curl.

1st log with only one audio stream
logs_vf.zip

2nd log with 2 audio streams, vf stream select by default. This audio stream doesn't failed.
After some time a switch to vo stream and it failed.
logs_vf_vo.zip

3rd log with 2 audio streams, vo stream select by default. The audio stream failed after some secondes.
Switch to vf works but video stream "pause" while audio stream tried to catch the time difference.
logs_vo_vf.zip

Where is timeshifting is implemented? inputstream addon side or my client side? Because for some channels I have 8 hours of timeshift but kodi don't allow me to pause neither to go back in time.

I am use the agile branch for kodi and for inputstream.adaptive cause only with this one ffmepg can't decrypt the streams.
Thanks

Edit1:
After quick 1st log review, it seems that the timestamp request is wrong. if duration have some patterns, it should be 1211745612061910 instead of 1211745592221914. For what I have seen with exoplayer, they redownload the manifest and update corresponding variables.
I start to implement this but it seems it will need more works than just redownload the manifest and update some variables. I have to understand what going on and It will surely take me some time.
So if you can't implement it or point me the rigth way to do it, it will be wonderful.

Edit2:
Updating durations with refreshing manifest seems the best way to do it but I will maybe need to modified more codes than I would like to. So I have a function that find the durations pattern and append it to segment_durations in AdaptiveTree::SetFragmentDuration(). The timestamp request sequence seems right but I get an CVideoPlayerAudio - CDVDMsg::GENERAL_EOF this time.You will find the logs and the function in this archive
logs_edit_pattern.zip
_

[peak3d]

I have to dig into your zip examples / logs. From theory reloading manifests should not be needed as the length of the fragments is always present. But this is theory (and worked at some time at least for the live streams I was playing with. redownloading manifest files feels for me kind of "fixing something broken" I'll look into the logs you provided

• timeshift is not implemented, kodi still has no proper interface to pass timeshift infos and therefore I postponed it. I start now-12 secs and tel kodi that stream ist not seekable and not pausable.

Edit: before thinking about redownloading manifest files we should more look why we calculate the wrong fragment duration of the last segment played. the 1211745592221914 seems to be a calculated value and seems to be not correct. Its much easier to find the root cause instead thinking about redownloading anything.

[DarkAnakin]

I don't fully understand your code and the smoothstreaming protocol so I take some shortcuts that maybe wrong. I was thinking that the manifest refresh was the best choice because maybe in some time the pattern will change. The right value for 1211745592221914 is not what I said before, it 1211745592221920. You will find a spreadsheet for the timestamp calculation for the logs_edit_pattern here
smooth_duration.xlsx

I will try, maybe today, to append the calculate durations just after the manifest parsing and go back before the 12 secs and see if it wiil work for me.
I think maybe the back-end have to do with this issue because with some channel I haven't this. Maybe It will return the fragment in between even if the timestamp was not right.

What I have done for adding duration:
search for pattern after each end of chunck attribute

 else if (strcmp(el, "c") == 0)
 {
/***
**/
  findPatterns(dash->current_adaptationset_);
}

and insert a amount of duration pattern in the end when segment_durations_.data come to end:

uint32_t patternSize = adp->durationPattern.size();
uint k = adp->segment_durations_.data.size()%patternSize;
/***
**/
uint ek = k+patternSize;
 for (;k<ek;k++){
   uint32_t val  =adp->durationPattern.at(k%patternSize);
   adpm->segment_durations_.data.insert(adpm->segment_durations_.data.end(),val);
/**
**/
}

Not the best way to resolve this issue without access to the stream but I am a bit obsessed about my private data. I will try to secure my setup and will try to find a way to send the streams.

[peak3d]

for me there exist one golden rule: don't write a single line of code before you don't know 100% what you want to archive. E.g. skygo livestreams don't redownoad the manifest, because simply adding the duration of played fragments should point you to the right pattern.

You know the starting timestamp of the first fragment wich is not in ism file: its the the last ts + duration.
If you now download this new fragment, and look with bento4 into it, you should get the exact duration of this next fragment and can simply append your ism manifest file. From theory this should be continuable in an endless loop.

You can log here: https://github.com/peak3d/inputstream.adaptive/blob/master/src/common/AdaptiveTree.cpp#L102

what happens, I guess that your issue is simply a inaccuraty when dealing with the timescale values.
log fragmentduration before / after the convertion and verify the values. If the incoming value is already wrong, then we have to look deeper in bento4 why the duration is 6 smaller than expected.

[DarkAnakin]

For what I can tell, that what I have done before and I get the ffmepg error. So to verify that I have right on my speculation I will append just after the manifest parsing, e.g 1 pattern that will be ~16secondes and play starting back 16s + 6s. If It play 22s my issue will be solve. Le 6 avr. 2017 8:14 AM, "Markus Pfau" <notifications@github.com> a écrit :

…

for me there exist one golden rule: don't write a single line of code before you don't know 100% what you want to archive. E.g. skygo livestreams don't redownoad the manifest, because simply adding the duration of played fragments should point you to the right pattern. You know the starting timestamp of the first fragment wich is not in ism file: its the the last ts + duration. If you now download this new fragment, and look with bento4 into it, you should get the exact duration of this next fragment and can simply append your ism manifest file. From theory this should be continuable in an endless loop. You can log here: https://github.com/peak3d/inputstream.adaptive/blob/ master/src/common/AdaptiveTree.cpp#L102 what happens, I guess that your issue is simply a inaccuraty when dealing with the timescale values. log fragmentduration before / after the convertion and verify the values. If the incoming value is already wrong, then we have to look deeper in bento4 why the duration is 6 smaller than expected. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGxYFwfZK7vtCHctn3H9B_3y6_GSnAqnks5rtIK0gaJpZM4MxeXd> .

[peak3d]

Maybe I simply don't understand what you're exactly doing, from my POV we simply have to find the root cause: Why is the fragment duration of the first fragment read behind the fragments defined in manifest some millisecs shorter than the expected value.

Why adding some value at the end or trying to get something working if there is an reproducable issue?
Why not simply investigate the cause of the error? Finding ways to "not having" the issue is IMO not the way how to solve this one.

Edit: can you pls. log the fragment-duration here: ?
https://github.com/peak3d/inputstream.adaptive/blob/master/src/main.cpp#L1319
This must be for the first 6 fragments played the same values you find at the end of the ism manifest.

[DarkAnakin]

Ok, I think I get what you tried to say now. I didn't what to edit anything that I couldn't understand and editing the calculation with the movie_timescale may had break something else so I didn't point any attention to it.
I will try to provide you the logs this afternoon or maybe to night.

Edit1:
Search for "SetFragmentDuration" e.g last duration 19840001 * timescale 10000000 / movietimescale 10000000 => 19840001 mean that last duration before the calculation was 19840001 and the result is => 19840001.
I can't understand why 19840001 has been chosen so I think It will be you to have to come with a response. Dig in to bento4 sources don't give me any clue.
As for append duration just after the manifest work for me at least, I will stay with this for now and try to understand the fragment duration calculation this week-end.
setfragduration_logs.zip

[peak3d]

In general the fragment duration is simply the sum of all frames * frame_duration.
What Bento4 calculates should be exactly the same as in ism,
-> 19840001 looks not really good

Edit: The first duration is already not ok: 20053334

Tipp: Select "Media" = Audio in inputstream.adaptive settings.
Its much easier to read log and debug.

Edit2:
https://github.com/peak3d/inputstream.adaptive/blob/master/lib/libbento4/Core/Ap4FragmentSampleTable.cpp#L189 <-- Here a sample gets its duration

https://github.com/peak3d/inputstream.adaptive/blob/master/lib/libbento4/Core/Ap4FragmentSampleTable.cpp#L228 <-- Here the fragment duration is summed.

Interesting is line 189, is default_duration taken or does every sample has its own duration.

After the loop you have your fragment duration (and this is the place where 19840001 was calculated)

[peak3d]

Can you pls download one audio fragment if you are again coding?
Just grep one line from log and wget / curl it. thanx!

[DarkAnakin]

Any audio fragment?
I presume you what me to upload it too. So here is.

vo=1214513785459420.zip

[peak3d]

Ok, thanx, looking into the MP4 Box the duration of this fragment is:

20053332

I have a feeling that their spltting program always rounds to full 10 values.
maybe its a definition

You can try to round the fragment-duration for test here:

https://github.com/peak3d/inputstream.adaptive/blob/master/src/common/AdaptiveTree.cpp#L102

Below this line ^^ pls. add: fragmentDuration = ((fragmentDuration +9) / 10) * 10;

[DarkAnakin]

Will try it in one hour. For sure I don't understand what you saying but ((x+9)/10)*10 = x + 9. So maybe there is a zero missing somewhere or why don't just write fragmenation +=9. Le 6 avr. 2017 9:23 PM, "Markus Pfau" <notifications@github.com> a écrit : Ok, thanx, looking into the MP4 Box the duration of this fragment is: 20053332 I have a feeling that their spltting program always rounds to full 10 values. maybe its a definition You can try to round the fragment-duration for test here: https://github.com/peak3d/inputstream.adaptive/blob/master/src/common/ AdaptiveTree.cpp#L102 Below this line ^^ pls. add: fragmentDuration = ((fragmentDuration +9) / 10) * 10; — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGxYF1EkppJwi_4728pdgsjAubgmvVYhks5rtTvBgaJpZM4MxeXd> .

[peak3d]

It's an integer division assume dur=5:

(5 +9) = 14/10 = 1;
1*10 = 10;

Edit: Goal is to have all durations dividable through 10, you can also use modulo for it, I don't care.
If you look at the ism manifest, you my have noticed that all values are ending with 0.

[peak3d]

https://forums.iis.net/p/1167897/1944371.aspx#1944371

Interesting article to get the value we're looking for on an other way

[DarkAnakin]

Got it for the integer division thanks. Glad you find the solution, don't know where is this UUID so I count on you. Do you want me to test with fragmentation duration «round» anyway? Le 6 avr. 2017 21:59, "Markus Pfau" <notifications@github.com> a écrit :

…

https://forums.iis.net/p/1167897/1944371.aspx#1944371 Interesting artzicle to get the value we're looking for on an other way — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGxYF79DHRg6IrnmAhSKhIZdApczkcruks5rtUQKgaJpZM4MxeXd> .

[peak3d]

You can test with the round, it will most probably work for your example but it is not a proper way.
I'll implement the UUID thing (its existng in your sample stream) but you'll have to test it

[peak3d]

The latest commit could / should solve the issue

[DarkAnakin]

Thanks a lot. It solved. Keep up the good work.

[peak3d]

thanx for feedback!