On Wed, 27 Apr 2016 at 11:32 Mark Thompson <s...@jkqxz.net> wrote: > 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 > > I agree, this isn't a TS file and so the demuxer shouldn't be able to handle it without handling wireshark dumps etc. I'm not aware on any further headers required for TS in RTP however.
Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
