[Ffmpeg-devel] [BUG] no video transcoding
Mon Apr 23 12:55:06 CEST 2007
> to comment a little more on this as it seem to be a popular bug ;)
> On Sun, Apr 15, 2007 at 08:13:37AM -0000, Wolfram Gloger wrote:
> > Ok that's probably true -- although I maintain the patch is correct,
> no it is not, cur_dts was approximately correct before and completely
> wrong after the patch
How so? cur_dts was set to some more or less random packet's dts
that was the last one parsed in av_find_stream_info().
Then the packet queue is flushed and the next packet read has a
(sometimetimes significantly) smaller dts value.
This leads to a hard error (dts < cur_dts) for valid DVB streams.
It is just a matter of luck if you don't hit this situation.
After the patch, cur_dts becomes AV_NO_PTS_VALUE -- how can that
be "completely wrong". Please elaborate.
I might agree about your "approximately correct" in the sense that
it hides another problem.
> > With both patches (i.e. in current svn) we lose all the cur_dts values
> > after av_find_stream_info(), so if the first packets don't contain
> > timestamps, we are in trouble generating any.
> > Baptiste, does the appended patch fix your case?
Yes that would be interesting to know.
> > It just remebers the first valid dts encountered
> > and restores them after av_find_stream_info().
> > (I have posted it before but only now regression-tested it..)
> this patch is a mess, and is rejected
> passing the cur_dts through 5 functions so that they then somewhere
> in a deeply nested one get restored is not acceptable, even less so
> without ANY documentation of these new parameters
I already said I didn't like it myself.. It was posted first as a
test to see whether we have identified the problem.
I suspect that reverting 8465 will hide the problem, but
please give me until tonight when I will allocate some time
for investigating this problem a bit more. My analysis so far:
1. Initial frames have no valid dts -> cur_dts is set to AV_NO_PTS_VALUE
2. Somehow in line 629 of current utils.c, cur_dts is set
to a small negative value (you already said that negative
timestamps are OK...)
3. compute_pkt_fields cannot discern between a negative timestamp
and an overflow and truncates the small negative value to a huge
positive one (for the common case of 33 bit timestamps)
4. At this stage we are definitely in trouble
(however it is another question why the nice "timestamp discontinuity"
logic in ffmpeg.c cannot cope with this)
More information about the ffmpeg-devel