Seeking through .flv files is very slow
VLC gets stuck for 10s on my machine after seeking through a .flv file. The "--avcodec-hw none -VXv" switches make no difference, problem not present on ffplay.
Activity
VLC version is 3.0.0git from 11 October. Every .flv file I have and that was downloaded from youtube is affected.
(you can obtain a sample from here: http://is.gd/b8t9wW )
Also, in case it's useful, the build switches were:
./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --disable-dependency-tracking --enable-aa --enable-alsa --enable-dca --enable-dvbpsi --enable-fast-install --enable-flac --enable-freetype --enable-fribidi --enable-glx --enable-gnomevfs --enable-gnutls --enable-httpd --enable-jack --enable-kate --enable-libass --enable-libcddb --enable-sftp --enable-swscale --enable-libmpeg2 --enable-mad --enable-avcodec --enable-postproc --enable-faad --enable-a52 --enable-dca --enable-libproxy --enable-lirc --enable-live555 --enable-lua --enable-mkv --enable-mod --enable-ogg --enable-optimizations --disable-oss --enable-pulse --enable-pvr --enable-real --enable-realrtsp --enable-smb --enable-sout --enable-speex --enable-taglib --enable-theora --enable-v4l2 --enable-vcd --enable-vcdx --enable-visual --enable-vorbis --enable-waveout --enable-xcb --enable-xvideo --with-default-font=/usr/share/fonts/truetype/FreeSerifBold.ttf --with-default-monospace-font=/usr/share/fonts/truetype/FreeMono.ttfAdded attachment:
Added attachment:
Replying to [comment:9 cehoyos]:
Could you point us to a sample again? The link above does not work anymore.
Here it is http://www.mediafire.com/?1phi9o7wc2jdwz1 . I also wonder if this could be a ffmpeg packaging issue on my distro. I will try making it as close as possible to the libav package and report back.
Replying to [comment:12 michaelni]:
when vlc opens this file and after it seeks, vlc fetches apparently 10seconds of audio packets, if one tries to seek again or exit before these packets have been played vlc gets "stuck" for a few seconds, if one waits these 10sec before seeking then it seems to work fine
How are you building VLC ? And which version of ffmpeg/libav are you using btw?
when parsing the flv, libavformat fails to parse a metadata packet and returns this in a new data stream, this data stream with only a single packet seems to confuse vlc and cause this 10sec seek stuck bug thing. ive fixed the parsing in libavformat (ffmpeg git master) and also changed the code so that such parse failures should no longer result in such a data stream. Ill try to backport this fix and workaround to the ffmpeg release branches so it should be in future ffmpeg releases. VLC should not fail to seek though even if theres a nearly empty data stream
Replying to [comment:15 michaelni]:
when parsing the flv, libavformat fails to parse a metadata packet and returns this in a new data stream, this data stream with only a single packet seems to confuse vlc and cause this 10sec seek stuck bug thing. ive fixed the parsing in libavformat (ffmpeg git master) and also changed the code so that such parse failures should no longer result in such a data stream. Ill try to backport this fix and workaround to the ffmpeg release branches so it should be in future ffmpeg releases. VLC should not fail to seek though even if theres a nearly empty data stream
That's great. I applied your commits dc0edf2 and 993b5a2 to ffmpeg 2.3.5 and so far the problem appears to be gone. Two questions: do I need to apply any of the other patches to libavformat/flvdec.c you pushed at the same time and most important of all, do you think they're safe for general use?
Thanks again for your efforts, this issue had plagued me for months!
Replying to [comment:16 Aloysius]:
I applied your commits dc0edf2 and 993b5a2 to ffmpeg 2.3.5 and so far the problem appears to be gone. Two questions: do I need to apply any of the other patches to libavformat/flvdec.c you pushed at the same time and most important of all, do you think they're safe for general use?
The 2 should be enough, and they should be safe though of course like with any other bugfix unexpected regressions are never impossible
Replying to [comment:17 michaelni]:
The 2 should be enough, and they should be safe though of course like with any other bugfix unexpected regressions are never impossible
Ok. Well, if you think there is no way to address the problem on the vlc end, I suppose this bug can be closed.
Or perhaps an internal flv decoder could be added?
added Status::not VLC label
