> > Note that In your original MPEG-2 stream, with B-frames, the frames
>> will be in decoding order, which is different from the display order,
>> and thus different from the order of frames in the resulting MPEG-4
>> stream (because that doesn't have B frames). In particular, the
>> present
Ross Finlayson schrieb:
>> How is the timeval structure mapped onto the 32bit presentation time in
>> the RTP packet, what interval do I have to add to fPresentationTime to
>> make RTP timestamp increase by 3600 (i.e. one frame duration @25Hz)?
>>
>
> Receiving code should not need to care abo
>How is the timeval structure mapped onto the 32bit presentation time in
>the RTP packet, what interval do I have to add to fPresentationTime to
>make RTP timestamp increase by 3600 (i.e. one frame duration @25Hz)?
Receiving code should not need to care about RTP timestamps. (Only
the LIVE555 RT
> Note that In your original MPEG-2 stream, with B-frames, the frames
> will be in decoding order, which is different from the display order,
> and thus different from the order of frames in the resulting MPEG-4
> stream (because that doesn't have B frames). In particular, the
> presentation
>Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
> micalg=sha1; boundary="ms050109060700050902090703"
>
>Hi!
>
>I'm transcoding MPEG-2 (with B-Frames) into MPEG-4 (without
>B-Frames, just I and P). Currently I'm just transcoding video, but
>later the tr
Hi!
I'm transcoding MPEG-2 (with B-Frames) into MPEG-4 (without B-Frames,
just I and P). Currently I'm just transcoding video, but later the
transcoded streams should by able to be synchronised with the source's
audio stream:
> Audio
|
