[FFmpeg-devel] H264 encoding and RTP muxing - calculating pts and dts

[Alexandre Ferrieux]

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