[FFmpeg-devel] Allow MPEGTS and KLV metadata remuxing

[Michael Niedermayer]

On Sun, Jan 17, 2016 at 01:24:29PM +0100, Stefano Sabatini wrote:
> Hi,
> 
> the attached patches allow to remux MPEGTS files containing KLV
> metadata. Since there are two kinds of metadata (synchronous and
> asynchronous), the first patch creates side data which stores the
> stream ID used to distinguish the two kind of packets, which is
> otherwise lost.
> 
> At the moment, I'm storing a single byte in the side data
> (corresponding to the stream ID), but the metadata could be extended
> to contain more information.
> 
> The second patch disables monotonicity checks for data packets in the
> muxer. Indeed there is a case where several data packets can have the
> same PTS/DTS in MPEGTS so it should be enabled at least for this
> special case (either explicitly enabling this for MPEGTS -
> e.g. through a capability flag, or enabling an option to disable the
> montonicity check, whatever people prefer).
> 
> Comments are very welcome.
> -- 
> FFmpeg = Funny & Fabulous Meaningful Picky Exxagerate Guru

>  libavcodec/avcodec.h    |    7 +++++++
>  libavcodec/avpacket.c   |    1 +
>  libavformat/mpegts.c    |   12 +++++++++++-
>  libavformat/mpegtsenc.c |   27 ++++++++++++++++++++-------

breaks fate
--- ./tests/ref/acodec/s302m    2016-01-17 18:42:03.168224316 +0100
+++ tests/data/fate/acodec-s302m        2016-01-18 00:19:04.128650317 +0100
@@ -1,4 +1,4 @@
-2d1494ad78292dca556fd079ec27f28d *tests/data/fate/acodec-s302m.mpegts
+8601644c674752c62ca35567a0294eef *tests/data/fate/acodec-s302m.mpegts
 1589164 tests/data/fate/acodec-s302m.mpegts
 f9b6528eee1aea04640ee83400c78689 *tests/data/fate/acodec-s302m.out.wav
 stddev:  986.97 PSNR: 36.44 MAXDIFF:18642 bytes:  1058400/  1056708

 [...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160118/5428b41f/attachment.sig>