[FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

[Mark Thompson]

On 24/04/16 23:24, Michael Niedermayer wrote:
> On Sun, Apr 24, 2016 at 11:27:32AM +0100, Mark Thompson wrote:
>> On 24/04/16 03:53, Michael Niedermayer wrote:
>>> 0x47 is expected to be at [0] but the affected files contain something
>>> else sometimes in its place that starts with 0x80 and is 12 bytes long
>>> it contains some counter or timestamp
>>> without the code above it will almost always work but if the counter
>>> contains a 0x47 in it resync can start at the wrong byte
>>>
>>> I dont know what created these kind of files, so even if iam not
>>> hit by a bus i think i am not too usefull here
>>> i was hoping a bit my patch would lead to someone recognizing this ...
>>
>> Sounds like an RTP header.  (You can certainly imagine a very sucky RTP receiver not bothering to do anything with the headers and hoping it all works out.)
>>
>> Is it a 16-bit counter in the third and fourth bytes, and a 32-bit timestamp in the fifth to eighth?  <https://tools.ietf.org/html/rfc3550#section-5>
>>
>> (Alternatively, link me to the sample and I'll have a look at it.)
> 
> http://samples.ffmpeg.org/ts/01c56b0dc1.ts

Hmm.  So it does look like an RTP header, with the version correct, payload type for MPEG-TS and the sequence number in the right place.  However, the timestamp and SSRC are always zero, and it lacks the subheader required by RFC 2250 for this sort of MPEG-TS-in-RTP stream.

I don't see how you could sanely create a file like this - it's like someone has heard of RTP and thinks they should put RTP headers on things without actually considering what they mean.

Unless someone can show what created this file and that it might make more, I suggest that the hack workaround should be removed.  The simple scan for 0x47 is a more consistent behaviour in the presence of broken files, even though it doesn't work in this particular case.

Thanks,

- Mark