[FFmpeg-devel] H264 encoding and RTP muxing - calculating pts and dts
Alexandre Ferrieux
alexandre.ferrieux
Tue Jul 20 16:33:04 CEST 2010
On 20/07/2010 15:51, Martin Storsj? wrote:
> On Tue, 20 Jul 2010, Alexandre Ferrieux wrote:
>
>> 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.
>
> Does the libavformat http code handle multipart/x-mixed-replace - I didn't
> know that. IIRC, according to roundup issue 2044, we don't support that
> yet at least.
Looking at the code in http.c, I can see it works by "chance"
- The main HTTP answer has no content-length, and a content-type multipart/x-mixed-replace, which is ignored.
- But the individual frames do have a content-length
- The code is apparently tailored for robustness, and ends up demuxing whatever has a content-length, so it demuxes
the frames
- The body of each frame being of an autodetectable type (JFIF token), ffmpeg is not lost.
But ugly as it is, it works perfectly, except when the source's rate is too erratic. I have the feeling that a minimal
effort should be sufficient to add the "real-time VFR input" support, but no experience with the internals, hence my
question.
-Alex
More information about the ffmpeg-devel
mailing list