[x264-devel] [PATCH] MPEG2 Program Stream output

Lorenzo Pallara l.pallara at avalpa.com
Mon Jan 24 09:48:20 CET 2011


Hi,

     thank you for the quick answer!

 >I wrote something like this once but didn't really see the point of it
in the cli unless you wanted to pipe instead of using libx264 for some
reason.

OpenCaster supports pipes and files as input for its multiplexing,
others software encoders supports pes output at least as file so it
should be a nice to have feature for x264 too.

 >The timestamp generation is wrong. You need to use the hrd_timing
output on each frame. In 13818-1, DTS and PTS are equivalent (within the
accuracy of the 90kHz clock) to cpb removal time and dpb removal time
respectively.

Let me try to be more verbose:

ETSI TS 101 154 states DTS and PTS shall indicate the same instant
in time than nominal cpb removal time and dpb removal time so STD and
HRD models are consistent but the timestamps in the patch for DTS and
PTS are generated by i_dts and i_pts and not
by hrd_timing struct where there are x264's cpb_removal_time and
dpb_output_time already so the patch should be changed.

To test this should be only necessary to replace DTS and PTS generation 
with:
(unsigned long long int)(p_picture->hrd_timing.cpb_removal_time * 90000) and
(unsigned long long int)(p_picture->hrd_timing.dpb_output_time * 90000)
because the values are stored as double and in seconds.

I compared the two generations:

This is an output using hrd_timing structure:

Presentation Time Stamp is: 10799, 0.1199 sec., Decode Time Stamp is:
3600, 0.0400 sec.
Presentation Time Stamp is: 25200, 0.2800 sec., Decode Time Stamp is:
7200, 0.0800 sec.
Presentation Time Stamp is: 17999, 0.1999 sec., Decode Time Stamp is:
10799, 0.1199 sec.
Presentation Time Stamp is: 14400, 0.1600 sec.
Presentation Time Stamp is: 21600, 0.2400 sec., Decode Time Stamp is:
18000, 0.2000 sec.
Presentation Time Stamp is: 39600, 0.4400 sec., Decode Time Stamp is:
21599, 0.2399 sec.
Presentation Time Stamp is: 32400, 0.3600 sec., Decode Time Stamp is:
25200, 0.2800 sec.
Presentation Time Stamp is: 28800, 0.3200 sec.

this is using the timestamp generation math starting from i_dts,
i_pts, fps num and denom integers:

Presentation Time Stamp is: 7200, 0.0800 sec., Decode Time Stamp is: 0,
0.0000 sec.
Presentation Time Stamp is: 21600, 0.2400 sec., Decode Time Stamp is:
3600, 0.0400 sec.
Presentation Time Stamp is: 14400, 0.1600 sec., Decode Time Stamp is:
7200, 0.0800 sec.
Presentation Time Stamp is: 10800, 0.1200 sec.
Presentation Time Stamp is: 18000, 0.2000 sec., Decode Time Stamp is:
14400, 0.1600 sec.
Presentation Time Stamp is: 36000, 0.4000 sec., Decode Time Stamp is:
18000, 0.2000 sec.
Presentation Time Stamp is: 28800, 0.3200 sec., Decode Time Stamp is:
21600, 0.2400 sec.
Presentation Time Stamp is: 25200, 0.2800 sec.

As far as I tested hrd_timing seemed to have small rounding errors, any
idea on how this happen?
Actually this won't impact on any decoding in the real world as they are
too small.

The other issue is cpb_removal_time was not at zero while setting
--vbv-int at zero, it should be related, isn't it?
Also this issue won't impact real decoders as any starting value is fine.

best regards,
     Lorenzo



More information about the x264-devel mailing list