Posted: Sat May 10, 2008 8:38 am Post subject: [Asterisk-video] mp4save(): different audio and video length
Hi,
Can we replace the video silence frame by an AMR coded silence (32 bits) ?
3C08556D944451010000006A8000000080000000000000000000000000000000
For the recording, the packet will be complete the audio stream.
For the reprompt, we can check the 32 bytes sequence and drop it (to
preserve the audio bandwidth, and not delay the video).
Regards,
Tech from i6net
Sergio Garcia Murillo a écrit :
Quote:
Hi Sven,
As I said I think that the patch is correct and I hope to apply it soon.
I'd like to get some feedback first from the people that have reported
the problem so we all now the impact of the solution and if it solves
defenetivelly the problem.
About AL2,3 an SN.. you made me have to investigate my own code and
recover my h223 spec from the bottom of one of my drawers.. jeje.. I
finished that part of the code a year ago, so IIRC I used AL2 with SN
for both audio and video.
I'll have to take a deeper look and see how did I solved the problem of
dropped packets in app_mp4 as this would not only apply to h234m, you
could have the same issue in RTP. The solution is to specify the
timestamp of the amr packet in the asterisk sample strutcture, this
would probably mean to store the received amr frame until we receive the
next to know how much delay it's between both so we behave the same as
it's been done in RTP. Then app_mp4 would calculate the audio frame
timestamp according to that and solve the issue. I'll check how much of
this is actually implemented.
About aduo/video different lengths, it's normal.. first audio is sent at
20 ms intervals and video is sent at 1/fps (for 10fps is each 100ms).
Second audio is shorted and arrives first than video, so you could have
up two frames of difference in length (200ms). If there is more
difference will have to take a deeper look at it.
Best regards
Sergio
Sven Brandau escribió:
> Hi Sergio, Hi @All,
>
> I think the solution that introduced by me works fine on none error
> prone channels.
>
> In case of errors or lost frames the patch will not have any impact. I
> understand that the adaption layer 2 for audio (AL2) and layer 3 for
> video (AL3) of H.324M can be used with optional sequence numbers (SN).
> By using sequence numbers, the receiver can detect lost frames.
>
> But the use of SN is optional and depends on the implementation of the
> H.324M stack on the mobile phone. If the phone doesn't support SN's we
> can't retrieve lost frames.
>
> In terms of the problem here with desynchronized audio/video or
> different lengths of audio/video, I guess we could solve it only on
> phones that supports sequence numbers.
>
> Am I right?
>
> Best regards,
> Sven
>
>
> Sergio Garcia Murillo wrote:
>
>> Yes, please, if anyone test it, send the results to the list so we
>> can commit the patch to the repository.
>> A priori I see it quite clea, so I think it won't do any harm at all
>> (another issue is if it solves the problem :)
>>
>> BR
>> Sergio
>>
>> Sven Brandau escribió:
>>
>>> Hi @All,
>>>
>>> recording to the questions, I've send you my patch.
>>>
>>> Please note that the patch is NOT really tested - please try it
>>> and send me your results.
>>>
>>> Patch it with (R213):
>>> patch -i app_h324m.c.patch
>>>
>>> Regards,
>>> Sven
>>>
>>>
>>>
>>>
>>> Sergio Garcia Murillo wrote:
>>>
>>>> Hi Sven
>>>>
>>>> Could you send me a patch with oyour solution?
>>>>
>>>> BR
>>>> Sergio
>>>>
>>>> ----- Original Message -----
>>>> From: Sven Brandau [mailto:brandau@gmx.de]
>>>> To: asterisk-video@lists.digium.com
>>>> Sent: Mon, 05 May 2008 15:30:33 +0200
>>>> Subject: Re: [Asterisk-video] mp4save(): different audio and video
>>>> lengths
>>>>
>>>> Hi @All,
>>>>
>>>> I'm working on a solution.
>>>>
>>>> I've found that some mobile phones (Moto K3) sending out AMR No-Data
>>>> packets, instead of comfort noise frames (AMR-SID). So I replaced the
>>>> No-Data packets with the last received AMR-SID frame (file
>>>> app_h324m.c /
>>>> function create_ast_frame). This solution worked fine for me.
>>>>
>>>> The only thing is, that the recording for audio and video starts on a
>>>> different time - audio and video is already not synchronized, but only
>>>> a few milliseconds. It depends on the mp4save option /V - waiting
>>>> for the
>>>> first I-frame.
>>>>
>>>> I'm already working on this issue and will announce my solution
>>>> here on the
>>>> mailing list.
>>>>
>>>> Regards,
>>>> Sven
>>>>
>>>> Low Yu Siang wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> May I know if anyone has solved the recording
>>>>> audio/video length problem?
>>>>>
>>>>> Tech from i6net wrote :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am going to work on it.
>>>>>>
>>>>>> But for the moment, I am qualifying the video transcoder and the
>>>>>> h324m module.
>>>>>> The Gateway (SIP -> 3G or 3G -> SIP) configuration
>>>>>>
>>>>> locks after some secondes or minutes if it use the
>>>>> transcoder.
>>>>>
>>>>>> 2 ways for the recording :
>>>>>> - Replace the silence by generating the AMR datas
>>>>>>
>>>>> with a audio silence.
>>>>>
>>>>>> - Check if we can timestamps correctly the AMR
>>>>>>
>>>>> packets in the MP4/3GP hinted file.
>>>>>
>>>>>
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Tue May 13, 2008 11:43 am Post subject: [Asterisk-video] mp4save(): different audio and video length
Hi Sergio,
I've some comments to your mail:
Sergio Garcia Murillo wrote:
Quote:
Hi Sven,
As I said I think that the patch is correct and I hope to apply it soon.
I'd like to get some feedback first from the people that have reported
the problem so we all now the impact of the solution and if it solves
defenetivelly the problem.
Agree.
Quote:
About AL2,3 an SN.. you made me have to investigate my own code and
recover my h223 spec from the bottom of one of my drawers.. jeje..
Good place for specs ;-)
Quote:
I finished that part of the code a year ago, so IIRC I used AL2 with SN
for both audio and video.
After looking to the source code of libh324, I guess the code is able to use
SN's. I think it would be not so difficult to extend the code to calculate time
stamps from SN's. But, if not every phone supports this SN feature, it would be
senseless to implement such one. I don't know the numbers of phone that support
SN's.
Quote:
I'll have to take a deeper look and see how did I solved the problem of
dropped packets in app_mp4 as this would not only apply to h234m, you
could have the same issue in RTP. The solution is to specify the
timestamp of the amr packet in the asterisk sample strutcture, this
would probably mean to store the received amr frame until we receive the
next to know how much delay it's between both so we behave the same as
it's been done in RTP. Then app_mp4 would calculate the audio frame
timestamp according to that and solve the issue. I'll check how much of
this is actually implemented.
If I understand you right, the solution would be to record the time when the
audio/video frame arrives at the libh324 and calculate the time between the
frames. So we can detect lost frames.
This would only work on bandwidth and delay constant channels, h324m is a
circuit switched technique - I mean this could work.
Quote:
About aduo/video different lengths, it's normal.. first audio is sent at
20 ms intervals and video is sent at 1/fps (for 10fps is each 100ms).
Second audio is shorted and arrives first than video, so you could have
up two frames of difference in length (200ms). If there is more
difference will have to take a deeper look at it.
Right. :-)
Quote:
Best regards
Sergio
Sven Brandau escribió:
> Hi Sergio, Hi @All,
>
> I think the solution that introduced by me works fine on none error
> prone channels.
>
> In case of errors or lost frames the patch will not have any impact. I
> understand that the adaption layer 2 for audio (AL2) and layer 3 for
> video (AL3) of H.324M can be used with optional sequence numbers (SN).
> By using sequence numbers, the receiver can detect lost frames.
>
> But the use of SN is optional and depends on the implementation of the
> H.324M stack on the mobile phone. If the phone doesn't support SN's we
> can't retrieve lost frames.
>
> In terms of the problem here with desynchronized audio/video or
> different lengths of audio/video, I guess we could solve it only on
> phones that supports sequence numbers.
>
> Am I right?
>
> Best regards,
> Sven
>
>
> Sergio Garcia Murillo wrote:
>> Yes, please, if anyone test it, send the results to the list so we
>> can commit the patch to the repository.
>> A priori I see it quite clea, so I think it won't do any harm at all
>> (another issue is if it solves the problem :)
>>
>> BR
>> Sergio
>>
>> Sven Brandau escribió:
>>> Hi @All,
>>>
>>> recording to the questions, I've send you my patch.
>>>
>>> Please note that the patch is NOT really tested - please try it
>>> and send me your results.
>>>
>>> Patch it with (R213):
>>> patch -i app_h324m.c.patch
>>>
>>> Regards,
>>> Sven
>>>
>>>
>>>
>>>
>>> Sergio Garcia Murillo wrote:
>>>> Hi Sven
>>>>
>>>> Could you send me a patch with oyour solution?
>>>>
>>>> BR
>>>> Sergio
>>>>
>>>> ----- Original Message -----
>>>> From: Sven Brandau [mailto:brandau@gmx.de]
>>>> To: asterisk-video@lists.digium.com
>>>> Sent: Mon, 05 May 2008 15:30:33 +0200
>>>> Subject: Re: [Asterisk-video] mp4save(): different audio and video
>>>> lengths
>>>>
>>>> Hi @All,
>>>>
>>>> I'm working on a solution.
>>>>
>>>> I've found that some mobile phones (Moto K3) sending out AMR No-Data
>>>> packets, instead of comfort noise frames (AMR-SID). So I replaced the
>>>> No-Data packets with the last received AMR-SID frame (file
>>>> app_h324m.c /
>>>> function create_ast_frame). This solution worked fine for me.
>>>>
>>>> The only thing is, that the recording for audio and video starts on a
>>>> different time - audio and video is already not synchronized, but only
>>>> a few milliseconds. It depends on the mp4save option /V - waiting
>>>> for the
>>>> first I-frame.
>>>>
>>>> I'm already working on this issue and will announce my solution
>>>> here on the
>>>> mailing list.
>>>>
>>>> Regards,
>>>> Sven
>>>>
>>>> Low Yu Siang wrote:
>>>>> Hi,
>>>>>
>>>>> May I know if anyone has solved the recording
>>>>> audio/video length problem?
>>>>>
>>>>> Tech from i6net wrote :
>>>>>> Hi,
>>>>>>
>>>>>> I am going to work on it.
>>>>>>
>>>>>> But for the moment, I am qualifying the video transcoder and the
>>>>>> h324m module.
>>>>>> The Gateway (SIP -> 3G or 3G -> SIP) configuration
>>>>> locks after some secondes or minutes if it use the
>>>>> transcoder.
>>>>>> 2 ways for the recording :
>>>>>> - Replace the silence by generating the AMR datas
>>>>> with a audio silence.
>>>>>> - Check if we can timestamps correctly the AMR
>>>>> packets in the MP4/3GP hinted file.
>>>>>
>>
--
----------------------------------------------------------------------
Dipl. Ing. Sven Brandau Software Systems Architect
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum