[FFmpeg-devel] Evaluation of flag AVFMT_TS_DISCONT
Mon Dec 20 09:02:34 CET 2010
Am 17.12.2010 13:25, schrieb Michael Niedermayer:
> On Fri, Dec 17, 2010 at 10:28:27AM +0100, Philip Spitzlinger wrote:
>> Hello everybody,
>> I am encounting problems when copying packets from MPEG2 Streams to a
>> new MPEG2 stream using the function av_interleaved_write_packet(...)
>> It complains about "non monotone timestamps" as the previous packet and
>> the packet to be written have the same timestamp as read from the source
>> This is even due to the fact that the output format has the flag
>> AVFMT_TS_DISCONT set, which as documented in avformat.h explicitly
>> allows non monotone timestamps.
>> Unfortunately this flag is not evaluated in the
>> av_interleaved_write_packet() function, which gives me the error
>> Wouldn't it be more correct to evaluate this flag at this time and allow
>> the non monotone timestamp if the flag is set?
>> Is there a certain reason why this flag is simply ignored at this time?
> muxing needs valid timestamps, its needed for various buffering things and
> for decissions on when to sent and repeat various packets for
> Thus demuxer -> muxer always requires dicontinuities to be removed. One
> could then store the actual packets with the discontinuous timestamps
> but thats currently unsupported, iam also not sure what it would be good
> for. Do you know of some use case that requires specific discontinuous ts?
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
In my special case, the read packages already have discontinous timestamps.
What I want to do is to simply package them into another videostream
with the same properties as the source-stream, thus implementing a
And here comes the timestamp problem, which won't let me write the
packages to the outputstream as they don't have monotone timestamps :-(
Maybe there is another way to tackle this but this?
I am using the av_read_frame(...) function to read the package from the
stream and then use the av_interleaved_write_frame(...) function to write it
to my destination stream.
Of course I am setting the properties of my destination stream as close
to the ones of my source stream as possible ( e.g. start_time is to be
altered, etc... )
As far as I could find out, this is the way it is implemented in ffmpeg.c
More information about the ffmpeg-devel