Regression: some H.264/AVC videos inside FLV don't play correctly
As reported in: http://forum.videolan.org/viewtopic.php?p=188914#p188914
There some FLV files which have H.264/AVC video inside that don't work correctly in VLC. It seems like they shutter during playback. VLC doesn't give any error messages and the issue isn't related to CPU usage.
Sample file to show this issue: http://rapidshare.com/files/209451332/shutter.flv.html Tested on 0.9.8a and 1.0.0-git under Win32.
Activity
added Severity::normal Type::bug Version::master git + 1 deleted label
changed milestone to %Bugs paradize
assigned to @fenrir and unassigned @Courmisch
added Component::Demuxers label and removed 1 deleted label
changed milestone to %1.0.0-release
New link for the video (no limits). http://koti.mbnet.fi/raiska/video.flv Problem also exists in VLC 1.1.0-git-20090525-2206
21:49 < nefrir> ah, yes ffmpeg output wrong pts 21:49 < thedj> yes i feared something like that. 21:49 < nefrir> now is it ffmpeg or the file, I am not sure ? 21:49 < funman> ffmpeg can reencode the file fine 21:49 < xtophe> nefrir: but ffplay plays it ok 21:49 < nefrir> because it mostky ignore pts 21:49 < nefrir> and recreate them 21:50 < xtophe> nefrir: so it's not a vlc bug. blocker-- 21:52 < funman> well vlc should handle this case 21:52 < nefrir> you either trust timestamp or not 21:52 < nefrir> if you don't, well it's a window open for a lot of trouble too 21:52 < nefrir> so ... 21:53 < funman> how are the timestamps wrong : they go backward or somethign? 21:53 < xtophe> but why 0.9.x vlc plays correctly then? 21:53 < xtophe> or is it only on win with old contrib ? 21:54 < nefrir> the dts is ok, the pts is not 21:54 < nefrir> the pts goes backward because dts == pts on this file, but it is using B 21:54 < funman> b = bidirectional ? 21:55 -!- kiamnetrem [n=SavageX_@Z9d17.z.pppool.de] has quit [Remote closed the connection] 21:55 < nefrir> yep 21:56 < funman> if the pts increment is always the same we could detect bframe with wrong pts and skip it ? 21:57 < nefrir> we don't know it is a b at the demux level 21:57 < nefrir> and beside with h264 it can be normal to have B instead of P (ie with same timestamp) 21:59 < funman> we know 21:59 < funman> p_sys->p_ff_pic->pict_type == FF_B_TYPE 21:59 < nefrir> that's at the decoder 21:59 < funman> oops :/ 22:00 < nefrir> and as I said, with h264, B can be used instead of P 22:00 < nefrir> ie not reordered
After looking at flvdec.c logs, it is not a real regression of ffmpeg.
The commit r15841 (ffmpeg) adds support for pts in the demuxer. Sadly it seems that some flv files are bugged and does not have a valid pts value. So the commit simply allowed us to see that error.
In [d1bf1bcf], I simply ignore pts when they might be invalid, basically reverting the effect of r15841 in ffmpeg.
I think this ticket could be closed as invalid as it's the file that is buggy.
added Status::fixed label
