<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Hi Borja,<br>

<br>

RTP timestamps are the *CORRECT* information, silence and lost packets

are correctly detected and fixed by looking at the RTP timestamps. <br>

<br>

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.&nbsp; I don't understand your burst

problem.<br>

<br>

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.<br>

<br>

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.<br>

<br>

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>

<br>

BR<br>

Sergio <br>

<br>

<a class="moz-txt-link-abbreviated" href="mailto:borja.sixto@i6net.com">borja.sixto@i6net.com</a> escribi&oacute;:

<blockquote cite="mid:1225806511.491052af06d53@imp.online.net"

 type="cite">

  <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:sergio.garcia@fontventa.com">&lt;sergio.garcia@fontventa.com&gt;</a>:

  </pre>

  <blockquote type="cite">

    <pre wrap="">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

<a class="moz-txt-link-abbreviated" href="mailto:borja.sixto@i6net.com">borja.sixto@i6net.com</a> escribi&oacute;:

    </pre>

    <blockquote type="cite">

      <pre wrap="">Hola Alberto (it seems that this subjet generate a lot of interest from

      </pre>

    </blockquote>

    <pre wrap="">spanish

    </pre>

    <blockquote type="cite">

      <pre wrap="">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

      </pre>

    </blockquote>

    <pre wrap="">or

    </pre>

    <blockquote type="cite">

      <pre wrap="">burst messages... and not garanty the video/audio synchronization).

It works better with 3G video calls.

Regards and Saludos,

Borja

Selon aj2r <a class="moz-txt-link-rfc2396E" href="mailto:ajrodriguez@fidesol.org">&lt;ajrodriguez@fidesol.org&gt;</a>:

      </pre>

      <blockquote type="cite">

        <pre wrap="">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&Atilde;&sup3;:

        </pre>

        <blockquote type="cite">

          <pre wrap="">Can you dump the track (mp3trackdump) and compare the 2 tracks ?

Alberto Jos&Atilde;&copy; Rodr&Atilde;&shy;guez Rodr&Atilde;&shy;guez a &Atilde;&copy;crit :

          </pre>

          <blockquote type="cite">

            <pre wrap="">Can you help me with app_mp4?

El lun, 03-11-2008 a las 18:14 +0100, Borja SIXTO escribi&Atilde;&sup3;:

            </pre>

            <blockquote type="cite">

              <pre wrap="">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-&gt;src = "h324m";

            if (vt-&gt;first)

            send-&gt;samples = vt-&gt;samples;

            else

            send-&gt;samples = 0;

Regards,

Borja

              </pre>

              <blockquote type="cite">

                <pre wrap="">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&Atilde;&sup3;:

                </pre>

                <blockquote type="cite">

                  <pre wrap="">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

                  </pre>

                </blockquote>

                <pre wrap="">_______________________________________________

--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--

asterisk-video mailing list