[FFmpeg-devel] H264 encoding and RTP muxing - calculating pts and dts
Tue Jul 20 15:47:57 CEST 2010
On 20/07/2010 15:33, Vladimir Pantelic wrote:
> Alexandre Ferrieux wrote:
>> Side question: what is the behavior of ffmpeg when such a VFR input
>> (assuming the grabbing rate is somehow irregular) is
>> converted to a CFR container and codec like TS/mpeg2 ?
>> Suppose an input timeline with frames F1...Fn. Dots indicate time:
>> and a regular output timeline for mpeg2ts:
>> What is G4:
>> - F2 (latest) ?
>> - F3 (closest, non-causal) ?
>> - F4 (one-to-one) ?
>> - other ?
>> Also, would it be possible to tell a no-timestamps container+codec
>> like mjpeg to insert gettimeofday()-based DTS/PTS ?
> mjpeg is not a container
Well here's what I get from ffmpeg -i on my cam:
Input #0, mjpeg, from 'http://10.67.15.37:36944/mjpg/video.mjpg':
Duration: N/A, bitrate: N/A
Stream #0.0: Video: mjpeg, yuvj420p, 1280x720 [PAR 1:1 DAR 16:9], 25 tbr, 1200k tbn, 25 tbc
of course, the container is HTTP multipart/x-mixed-replace and individual frames have a mime type of image/jpeg.
but was this clarification really needed ?
>> The typical use is an IP cam, with an underpowered CPU, which is
>> rarely reaching the announced framerate, the effective
>> rate varying wildly depending on the complexity of the image.
> use a container that supports VFR
What kind of advice is that ? I don't control the way an IPcam streams data. Mjpeg over HTTP is here to stay.
My question is: is it possible to set the PTS/DTS of these no-timestamp frames to the current time ?
If not, how can people exploit those IP cams ?
More information about the ffmpeg-devel