2014-02-25, 16:45
Hi all,
I'm debugging a small issue that is annoying me as hell. I have mpegts files that are created by ArgusTV when recording from a DVB-T source.
When I try to play them, probing the input file is OK. I can see that avformat_find_stream_info returns the proper duration, etc.
(called from DVDDemuxFFMpeg::Open)
After a few seconds of play, the duration spikes from the initial (correct) 43 minutes to about 18 hours, 21 minutes. After some digging I found that the
info is taken from DVDDemuxFFMpeg::GetStreamLength which takes it from the format context.
I can see that there are several frames that return with duration 0 after av_read_frame in the Read() method. Actually, the packet returns with duration 0
and very large pts/dts values that after conversion using timebase they become the 18h:21m. Later on there is some processing of the duration values
and in this case the format context duration is updated using those large values.
I suspect there is a problem with the file itself, maybe some bad frames that cause ffmpeg's parser to bail out without giving proper values. I'm trying to debug
ffmpeg now with some log prints but I'd like to know -
Is it enough to detect such a scenario by checking if the packet duration is 0? Currently there is no such check in the code. The code will check for invalid
pts/dts values (NOPTS or 0 set) but doesn't check the duration.
I'm currently digging deeper and will see if detecting duration=0 is helping any... If so, are you even interested in adding such a check?
I'm debugging a small issue that is annoying me as hell. I have mpegts files that are created by ArgusTV when recording from a DVB-T source.
When I try to play them, probing the input file is OK. I can see that avformat_find_stream_info returns the proper duration, etc.
(called from DVDDemuxFFMpeg::Open)
After a few seconds of play, the duration spikes from the initial (correct) 43 minutes to about 18 hours, 21 minutes. After some digging I found that the
info is taken from DVDDemuxFFMpeg::GetStreamLength which takes it from the format context.
I can see that there are several frames that return with duration 0 after av_read_frame in the Read() method. Actually, the packet returns with duration 0
and very large pts/dts values that after conversion using timebase they become the 18h:21m. Later on there is some processing of the duration values
and in this case the format context duration is updated using those large values.
I suspect there is a problem with the file itself, maybe some bad frames that cause ffmpeg's parser to bail out without giving proper values. I'm trying to debug
ffmpeg now with some log prints but I'd like to know -
Is it enough to detect such a scenario by checking if the packet duration is 0? Currently there is no such check in the code. The code will check for invalid
pts/dts values (NOPTS or 0 set) but doesn't check the duration.
I'm currently digging deeper and will see if detecting duration=0 is helping any... If so, are you even interested in adding such a check?