[FFmpeg-devel] PTS/DTS inaccuracy in PES

[Tomer Barletz]

On Tue, Jan 6, 2009 at 4:57 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Jan 06, 2009 at 08:44:57AM +0200, Tomer Barletz wrote:
>> Hi Michael,
>>
>> On Mon, Jan 5, 2009 at 8:25 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Mon, Jan 05, 2009 at 06:15:57PM +0200, Tomer Barletz wrote:
>> >> Hi  everyone,
>> >> Lately I've been working on the TS muxer from the gsoc repository, in
>> >> order to fix some PCR timing issues.
>> >> I've submitted a patch to fix these issues, and the output TS looks
>> >> nice and accurate now.
>> >>
>> >> However, I'm currently experiencing some problems with the (video) PES
>> >> PTS/DTS accuracy.
>> >> After analysing the PES, I can see significant irregularities with the
>> >> stream - the PTS and DTS values looks correct at first, but they will
>> >> lose accuracy exponentially very soon.
>> >>
>> >> I've started to look at the code, and figured that the location where
>> >> these values are calculated is at
>> >> libavformat/utils.c::compute_pkt_fields; but this method is quite
>> >> difficult to understand, specifically the blocks starting at 837, and
>> >> 877 (I don't want to paste the code here, since it's pretty long).
>> >> Can someone please shed some light on this?
>> >
>> > compute_pkt_fields() is used on the demuxer side, not the muxer.
>> >
>> > Also keep in mind H264 in MPEG-* is not supported. We are lacking
>> > correct timestamp interpolation as described in H.222 & 264!
>> > So if your problems are with H264 (you didnt say which codec) then
>> > the problem is near certainly there.
>> > If it is H264, the fix is to fix the AVParser for H.264 and
>> > compute_pkt_fields() in the way its decribed in H.222/264 ...
> [...]
>> >From your message, I understand that MPEG-2 video is supported.
>> But yet, I see the same results when wrapping it in a PES.
>
> well, you should elaborate on what exactly is wrong and provide some
> test sample or if its reproduceabel with any pick one already on mphq
> so we have the same sample ...
>
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFJY3E9YR7HhwQLD6sRAlgEAJ9p0Y/niY/hxzQnxojTlrUTrxA+LgCeLxCr
> XLAyaaDkIKAYcwSd7iTsuTE=
> =PSCE
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>

The following file was created with the "new" TS muxer:
http://rapidshare.com/files/180404351/test.ts.html

It was transcoded from a VC-1 stream, using the following command line
(latest svn):
ffmpeg -i Coral_Reef_Adventure.wmv -vcodec mpeg2video -s 720x480
-aspect 4:3 -b 5000k -maxrate 5000k -minrate 5000k -r 29.97 -bufsize
1835008 -threads 2 -an test.ts

As I said before - ffplay/mplayer will play this file with no
complaints, even though it is not MPEG compliant (inaccurate PTS/DTS
values).

Tomer