[Asterisk-video] mp4save, bad video length XD
Sergio Garcia Murillo
sergio.garcia at fontventa.com
Tue Nov 4 08:24:55 CST 2008
Hi Borja,
RTP timestamps are the *CORRECT* information, silence and lost packets
are correctly detected and fixed by looking at the RTP timestamps.
Bad timestamps is a softphone problem, that if needed to be deal should
be handled by asterisk in the RTP reception code, overriding the rtp
timestamp with the reception time. I don't understand your burst problem.
Extracting a track from a mp4 file removes all timing information, so
it's normal that it does not work with silences or packet lost.
For audio/video sync there is only one good way also, RTCP sender
reports. The other approach is to calculate the delay between the first
audio packet and the first video packet, but due to jitters, video
capturing, encoding and send times, the audio and video synchronization
won't be perfect.
If there is a bug in the software that is causing troubles I'll be more
than glad to solve, but the methods explained above are the only ones
that are possible.
BR
Sergio
borja.sixto at i6net.com escribió:
> Hi Sergio,
>
> Some users, like me, use the mp4save application with SIP Video Phones.
>
> Due to the variable quality of the internet transport and the conformance of the
> Video SIP Phone (generate silences, bursts, lost packets, bad timestamps...).
> The application mp4save cannot be use in this kind of use cases because it is
> only based on timestamps.
>
> In most cases we have an unsynchronized video recording.
>
> With the h324m, generally it works fin, but I remember that I had see some
> recordings unsynchronized due to the handset (that don't generate silence marks
> and stop the audio sending...). In most case the reprompt works fine too, but
> the conversion with FFmpeg compact the audio sequence (it don' care about the
> audio time marks) and generate a video content unsynchronized...
>
> Regards y Saludos,
>
>
> Borja
>
>
> Selon Sergio Garcia Murillo <sergio.garcia at fontventa.com>:
>
>
>> Why do you mean with "it doe snot support lost or burst messages"?
>>
>> There are only two ways of achieve audio and video syncronization.
>> The first would be getting acces to the RTCP sender reports, which I
>> think it's not possible right now directly, would only work on RTP
>> channels and would require to modify all the previous stored data when
>> the first sr is received. The second would be to set the global
>> timestamp of a packet based on the reception time as it's done in
>> app_h324m.
>>
>> I would recomend to use the "wait video" flag, that will also wait for
>> the first intra frame and if there is no silence suppresion the audio
>> and video will be correctly synchronised.
>>
>> BR
>> Sergio
>>
>> borja.sixto at i6net.com escribió:
>>
>>> Hola Alberto (it seems that this subjet generate a lot of interest from
>>>
>> spanish
>>
>>> guys...),
>>>
>>> The duration of the video is wrong.
>>> I think your Sip Phone set a bad timestamp (set always 327327).
>>> (the native module use the timestamp to calculate the duration/time).
>>>
>>> The mp4save module have some limitations (once is that it not support lost
>>>
>> or
>>
>>> burst messages... and not garanty the video/audio synchronization).
>>> It works better with 3G video calls.
>>>
>>> Regards and Saludos,
>>>
>>>
>>> Borja
>>>
>>>
>>>
>>>
>>> Selon aj2r <ajrodriguez at fidesol.org>:
>>>
>>>
>>>
>>>> I'm not allowed to send attached files that exceed 40k, so I've pasted a
>>>> part of the dump
>>>>
>>>> mp4file test.mp4, track 1, samples 536, timescale 8000
>>>> sampleId 1, size 160 duration 160 time 0 00:00:00.000
>>>> sampleId 2, size 160 duration 160 time 160 00:00:00.020
>>>> sampleId 3, size 160 duration 160 time 320 00:00:00.040
>>>> sampleId 4, size 160 duration 160 time 480 00:00:00.060
>>>> sampleId 5, size 160 duration 160 time 640 00:00:00.080
>>>> sampleId 6, size 160 duration 160 time 800 00:00:00.100
>>>> sampleId 7, size 160 duration 160 time 960 00:00:00.120
>>>> sampleId 8, size 160 duration 160 time 1120 00:00:00.140
>>>> sampleId 9, size 160 duration 160 time 1280 00:00:00.160
>>>> sampleId 10, size 160 duration 160 time 1440 00:00:00.180
>>>> sampleId 11, size 160 duration 160 time 1600 00:00:00.200
>>>> sampleId 12, size 160 duration 160 time 1760 00:00:00.220
>>>> sampleId 13, size 160 duration 160 time 1920 00:00:00.240
>>>> sampleId 14, size 160 duration 160 time 2080 00:00:00.260
>>>> sampleId 15, size 160 duration 160 time 2240 00:00:00.280
>>>> sampleId 16, size 160 duration 160 time 2400 00:00:00.300
>>>> sampleId 17, size 160 duration 160 time 2560 00:00:00.320
>>>> sampleId 18, size 160 duration 160 time 2720 00:00:00.340
>>>> sampleId 19, size 160 duration 160 time 2880 00:00:00.360
>>>> sampleId 20, size 160 duration 160 time 3040 00:00:00.380
>>>> sampleId 21, size 160 duration 160 time 3200 00:00:00.400
>>>> ...............
>>>>
>>>> mp4file test.mp4, track 2, samples 536, timescale 8000
>>>> sampleId 1, size 32 duration 160 time 0 00:00:00.000 S
>>>> sampleId 2, size 32 duration 160 time 160 00:00:00.020 S
>>>> sampleId 3, size 32 duration 160 time 320 00:00:00.040 S
>>>> sampleId 4, size 32 duration 160 time 480 00:00:00.060 S
>>>> sampleId 5, size 32 duration 160 time 640 00:00:00.080 S
>>>> sampleId 6, size 32 duration 160 time 800 00:00:00.100 S
>>>> sampleId 7, size 32 duration 160 time 960 00:00:00.120 S
>>>> sampleId 8, size 32 duration 160 time 1120 00:00:00.140 S
>>>> sampleId 9, size 32 duration 160 time 1280 00:00:00.160 S
>>>> sampleId 10, size 32 duration 160 time 1440 00:00:00.180 S
>>>> sampleId 11, size 32 duration 160 time 1600 00:00:00.200 S
>>>> sampleId 12, size 32 duration 160 time 1760 00:00:00.220 S
>>>> sampleId 13, size 32 duration 160 time 1920 00:00:00.240 S
>>>> sampleId 14, size 32 duration 160 time 2080 00:00:00.260 S
>>>> sampleId 15, size 32 duration 160 time 2240 00:00:00.280 S
>>>> sampleId 16, size 32 duration 160 time 2400 00:00:00.300 S
>>>> sampleId 17, size 32 duration 160 time 2560 00:00:00.320 S
>>>> sampleId 18, size 32 duration 160 time 2720 00:00:00.340 S
>>>> sampleId 19, size 32 duration 160 time 2880 00:00:00.360 S
>>>> sampleId 20, size 32 duration 160 time 3040 00:00:00.380 S
>>>> sampleId 21, size 32 duration 160 time 3200 00:00:00.400 S
>>>> sampleId 22, size 32 duration 160 time 3360 00:00:00.420 S
>>>> ..............
>>>>
>>>> mp4file test.mp4, track 3, samples 66, timescale 90000
>>>> sampleId 1, size 16232 duration 0 time 0 00:00:00.000 S
>>>> sampleId 2, size 3102 duration 327327 time 0 00:00:00.000 S
>>>> sampleId 3, size 142 duration 327327 time 327327 00:00:03.636 S
>>>> sampleId 4, size 2610 duration 327327 time 654654 00:00:07.273 S
>>>> sampleId 5, size 1913 duration 327327 time 981981 00:00:10.910 S
>>>> sampleId 6, size 194 duration 327327 time 1309308 00:00:14.547 S
>>>> sampleId 7, size 146 duration 327327 time 1636635 00:00:18.184 S
>>>> sampleId 8, size 273 duration 327327 time 1963962 00:00:21.821 S
>>>> sampleId 9, size 404 duration 327327 time 2291289 00:00:25.458 S
>>>> sampleId 10, size 870 duration 327327 time 2618616 00:00:29.095 S
>>>> sampleId 11, size 918 duration 327327 time 2945943 00:00:32.732 S
>>>> sampleId 12, size 1270 duration 327327 time 3273270 00:00:36.369 S
>>>> sampleId 13, size 1619 duration 327327 time 3600597 00:00:40.006 S
>>>> sampleId 14, size 2445 duration 327327 time 3927924 00:00:43.643 S
>>>> sampleId 15, size 2216 duration 327327 time 4255251 00:00:47.280 S
>>>> sampleId 16, size 2363 duration 327327 time 4582578 00:00:50.917 S
>>>> sampleId 17, size 2524 duration 327327 time 4909905 00:00:54.554 S
>>>> sampleId 18, size 2174 duration 327327 time 5237232 00:00:58.191 S
>>>> sampleId 19, size 1529 duration 327327 time 5564559 00:01:01.828 S
>>>> sampleId 20, size 778 duration 327327 time 5891886 00:01:05.465 S
>>>> sampleId 21, size 769 duration 327327 time 6219213 00:01:09.102 S
>>>> sampleId 22, size 1449 duration 327327 time 6546540 00:01:12.739 S
>>>> ........
>>>>
>>>> mp4file test.mp4, track 4, samples 66, timescale 90000
>>>> sampleId 1, size 532 duration 0 time 0 00:00:00.000 S
>>>> sampleId 2, size 136 duration 327327 time 0 00:00:00.000 S
>>>> sampleId 3, size 48 duration 327327 time 327327 00:00:03.636 S
>>>> sampleId 4, size 92 duration 327327 time 654654 00:00:07.273 S
>>>> sampleId 5, size 92 duration 327327 time 981981 00:00:10.910 S
>>>> sampleId 6, size 48 duration 327327 time 1309308 00:00:14.547 S
>>>> sampleId 7, size 48 duration 327327 time 1636635 00:00:18.184 S
>>>> sampleId 8, size 48 duration 327327 time 1963962 00:00:21.821 S
>>>> sampleId 9, size 48 duration 327327 time 2291289 00:00:25.458 S
>>>> sampleId 10, size 48 duration 327327 time 2618616 00:00:29.095 S
>>>> sampleId 11, size 48 duration 327327 time 2945943 00:00:32.732 S
>>>> sampleId 12, size 48 duration 327327 time 3273270 00:00:36.369 S
>>>> sampleId 13, size 92 duration 327327 time 3600597 00:00:40.006 S
>>>> sampleId 14, size 92 duration 327327 time 3927924 00:00:43.643 S
>>>> sampleId 15, size 92 duration 327327 time 4255251 00:00:47.280 S
>>>> sampleId 16, size 92 duration 327327 time 4582578 00:00:50.917 S
>>>> sampleId 17, size 92 duration 327327 time 4909905 00:00:54.554 S
>>>> sampleId 18, size 92 duration 327327 time 5237232 00:00:58.191 S
>>>> sampleId 19, size 92 duration 327327 time 5564559 00:01:01.828 S
>>>> sampleId 20, size 48 duration 327327 time 5891886 00:01:05.465 S
>>>> sampleId 21, size 48 duration 327327 time 6219213 00:01:09.102 S
>>>> sampleId 22, size 92 duration 327327 time 6546540 00:01:12.739 S
>>>> ..............
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> El lun, 03-11-2008 a las 21:45 +0100, Borja SIXTO escribió:
>>>>
>>>>
>>>>> Can you dump the track (mp3trackdump) and compare the 2 tracks ?
>>>>>
>>>>> Alberto José RodrÃguez RodrÃguez a écrit :
>>>>>
>>>>>
>>>>>> Can you help me with app_mp4?
>>>>>>
>>>>>> El lun, 03-11-2008 a las 18:14 +0100, Borja SIXTO escribió:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi alls,
>>>>>>>
>>>>>>> The mp4save use timestamps to mark the video sequence.
>>>>>>> Some SIP phones not pay attention about that a set wrong values...
>>>>>>>
>>>>>>> The app_h324m have the same problem, Sergio...
>>>>>>>
>>>>>>> I have made this modification to the app_h324m (all the frame of the
>>>>>>> same sample must have the same timestamp, Asterisk use relative
>>>>>>> "timestamps" by the use of samples !) :
>>>>>>> /* Rest of values*/
>>>>>>> send->src = "h324m";
>>>>>>> if (vt->first)
>>>>>>> send->samples = vt->samples;
>>>>>>> else
>>>>>>> send->samples = 0;
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>>>> Borja
>>>>>>>
>>>>>>>
>>>>>>> Sergio Garcia Murillo a écrit :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Umm.. it seems that it has calculated the fps wrong
>>>>>>>>
>>>>>>>> 176x144 @ 0.279218 fps
>>>>>>>>
>>>>>>>> How have you recorded the file?
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Sergio
>>>>>>>>
>>>>>>>> aj2r escribió:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hello, when I save a video with mp4save, I obtain a wrong mp4 file.
>>>>>>>>> The video track length is n times larger than the audio track length
>>>>>>>>> which is the actual length.
>>>>>>>>>
>>>>>>>>> mp4info output:
>>>>>>>>> mp4info version 1.5.0.1
>>>>>>>>> /tmp/test.mp4:
>>>>>>>>> Track Type Info
>>>>>>>>> 1 audio G.711 uLaw, 21.780 secs, 64 kbps, 8000 Hz
>>>>>>>>> 2 hint Payload PCMU for track 1
>>>>>>>>> 3 video H.263, 469.168 secs, 3 kbps, 176x144 @ 0.279218 fps
>>>>>>>>> 4 hint Payload H263-1998 for track
>>>>>>>>>
>>>>>>>>> Any idea? Thanks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>>>>
>>>>>>>> asterisk-video mailing list
>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>>>
>>>>>>> asterisk-video mailing list
>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>
>>>>> asterisk-video mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>
>>>>>
>>>> --
>>>> Alberto José RodrÃguez RodrÃguez
>>>> Fundación I+D del Software Libre
>>>> Parque Tecnológico de Ciencias de la Salud
>>>> BIC Granada-CEEI
>>>> Avda. de la Innovación, 1
>>>> 18100 Armilla (Granada)
>>>> Tlf. 958750457
>>>> ajrodriguez at fidesol.org
>>>> www.fidesol.org
>>>>
>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>
>>>> asterisk-video mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>
>>>>
>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-video mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-video/attachments/20081104/d040409f/attachment-0001.htm
More information about the asterisk-video
mailing list