[FFmpeg-devel] Collection of patches

[Thorsten Jordan]

Michael Niedermayer schrieb:
> On Wed, Apr 23, 2008 at 09:15:40AM +0200, Thorsten Jordan wrote:
>> Michael Niedermayer schrieb:
>>> On Tue, Apr 22, 2008 at 12:36:02PM +0200, Thorsten Jordan wrote:
>>> [...]
>>>> So thanks for reading so far and here are the patches:
>>>>
>>>> Make AVCHD (mts) files give better PTS values, as PCR packets are
>>>> scanned ignoring the mts<->ts difference:
>>>> mts_pcr_parse_syncbyte_check.patch
>>> mans ?
>> it may look a bit hackish but shows up a problem when decoding .mts
>> files, as they are not handled specially by ffmpeg. The TS demuxer just
>> scans for the next 0x47 startcode, skipping the 4 bytes of the counter
>> that are stored in each mts-"packet" before the TS part. Since the first
>> byte of that counter is <= 0x3f, that patch should be valid (it can
>> never be 0x47). Imho the demuxer should handle mts specially, because
>> what if any of the bytes 1-3 of that counter are 0x47 by coincidence?
> 
> Now your patch looks really wrong. Where can i find a .mts file?
I have uploaded a file avchd_camera_testfile.mts to subdirectory
avchd_camera_testfile in MPlayer/incoming like as for a bugreport.

MTS has 192-byte-sized packets, of which the first four bytes are a big
endian counter (some kind of time stamp, like pcr) and the rest 188
bytes are a normal TS packet. The exact meaning of the counter is
unknown to me and I couldn't find info on the net. The
open-source-software "TSMuxeR" writes a copy of the PCR to it, like when
streaming TS/HDV to a camera, however the lower nibbles of the counter
look like they have a special meaning, like isochronous packets on
firewire transport.

Imho it would be best to write a dedicated mts demuxer that uses the ts
demuxer, but "knows" of the gaps between TS packets.

My patch checks if the first byte of the buffer is 0x47 (always true for
ts) and if not to advance 4 bytes (it assumes mts then), and decode the
PCR from there.

I can't tell any more in which file on which PCR this caused problems,
but it should appear in all AVCHD-files, as they use PAFF and also don't
contain timestamps for bottom fields, giving the pts-guessing in
libavformat a hard time.

-- 
Regards, Thorsten