[FFmpeg-devel] Collection of patches

[Michael Niedermayer]

On Wed, Apr 23, 2008 at 01:55:13PM +0200, Thorsten Jordan wrote:
> 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.

thanks


> 
> 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.

Iam really scared


> 
> 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.

Nonsense, the problem has nothing to do with mts
This is about packets not begining exactly at the file start
the same will happen with any random ts file that has been cut by dd.
Our naive seeking code assumes packets do start exactly at the file
start, the idea to fix the case where its exactly 4 bytes off in a hack like
you do is insane. ... And the idea to write a seperate demuxer for that is
even more insane.

Proper fix below (which i will apply in 24h unless mans objects)

Index: libavformat/mpegts.c
===================================================================
--- libavformat/mpegts.c	(revision 12867)
+++ libavformat/mpegts.c	(working copy)
@@ -90,6 +90,9 @@
     AVFormatContext *stream;
     /** raw packet size, including FEC if present            */
     int raw_packet_size;
+
+    int pos47;
+
     /** if true, all pids are analyzed to find streams       */
     int auto_guess;
 
@@ -1046,6 +1049,8 @@
     if (p >= p_end)
         return;
 
+    ts->pos47= url_ftell(ts->stream->pb) % ts->raw_packet_size;
+
     if (tss->type == MPEGTS_SECTION) {
         if (is_start) {
             /* pointer field present */
@@ -1379,7 +1384,7 @@
     uint8_t buf[TS_PACKET_SIZE];
     int pcr_l, pcr_pid = ((PESContext*)s->streams[stream_index]->priv_data)->pcr_pid;
     const int find_next= 1;
-    pos = ((*ppos  + ts->raw_packet_size - 1) / ts->raw_packet_size) * ts->raw_packet_size;
+    pos = ((*ppos  + ts->raw_packet_size - 1 - ts->pos47) / ts->raw_packet_size) * ts->raw_packet_size + ts->pos47;
     if (find_next) {
         for(;;) {
             url_fseek(s->pb, pos, SEEK_SET);

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080423/8b3281d0/attachment.pgp>