On 03/19/2013 06:14 AM, Anton Khirnov wrote:
> 
> On Tue, 19 Mar 2013 00:31:44 +0100, Luca Barbato <[email protected]> wrote:
>> Most formats do not support negative timestamps, shift them to avoid
>> unexpected behaviour and a number of bad crashes.
>> ---
>>
>> Now with fate updated, I need to doublecheck why mkv results change, should
>> not happen.
>>
>>
>>  libavformat/avformat.h    |  12 ++
>>  libavformat/ffmenc.c      |   1 +
>>  libavformat/matroskaenc.c |   3 +-
>>  libavformat/mux.c         |  25 ++-
>>  libavformat/oggenc.c      |   1 +
>>  tests/ref/fate/rv40       | 460 
>> +++++++++++++++++++++++-----------------------
>>  tests/ref/fate/wtv-demux  | 278 ++++++++++++++--------------
>>  tests/ref/lavf/asf        |   4 +-
>>  tests/ref/lavf/mkv        |   2 +-
>>  tests/ref/lavf/mpg        |   2 +-
>>  tests/ref/lavf/ts         |   2 +-
>>  tests/ref/seek/lavf-asf   |  54 +++---
>>  tests/ref/seek/lavf-mkv   |  44 ++---
>>  tests/ref/seek/lavf-mpg   |  54 +++---
>>  tests/ref/seek/lavf-ts    |  54 +++---
>>  15 files changed, 515 insertions(+), 481 deletions(-)
>>
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index 067a787..9462779 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -360,6 +360,7 @@ typedef struct AVProbeData {
>>  #define AVFMT_TS_NONSTRICT 0x20000 /**< Format does not require strictly
>>                                          increasing timestamps, but they must
>>                                          still be monotonic */
>> +#define AVFMT_TS_NEGATIVE  0x40000 /**< Format allows negative timestamps 
>> If not set the timestamp will be shifted so they start from 0. */
>>  
>>  /**
>>   * @addtogroup lavf_encoding
>> @@ -431,6 +432,17 @@ typedef struct AVOutputFormat {
>>       *         A negative number if unknown.
>>       */
>>      int (*query_codec)(enum AVCodecID id, int std_compliance);
>> +
>> +    /**
>> +     * Offset to remap timestamps to be non-negative.
>> +     * Expressed in timebase units.
>> +     */
>> +    int64_t offset;
>> +
>> +    /**
>> +     * Timebase for the timestamp offset.
>> +     */
>> +    AVRational *offset_timebase;
> 
> Sorry, but no.
> This is a horrible horrible hack. I cannot imagine how one fixed offset per
> format could ever be sufficiently generic for such situations.
> 
> It's better to leave such offsetting to the caller IMO.

I disagree. That is a lot of complexity put onto the user in order to
get basic working muxing in very common situations.

-Justin

_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to