search

kim42083 / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

Seeking in VLC/Chrome is "quantised" #377

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What is the expected behavior? What do you see instead?
- Encode video with FFmpeg
- Open with VLC
- Seek to different points of the video.
- Seeking is "quantised", i.e. snaps to different points of the video, e.g. 
seeking to anywhere betweeen 06:30 and 10:40 will always seek to 06:30

What version are you using? On what operating system?
ffmpeg - N-35510-g0b9a69f built Nov 23rd 2011 (not sure if that's a release 
date)
vpxenc - v0.9.7-p1
Arch Linux

Can you reproduce using the vpxdec or vpxenc tools? What command line are you 
using?
Unsure how to use vpxenc. ffmpeg command:

ffmpeg -y -i lists.mp4 -f webm -vcodec libvpx -vb 600k -r 20 -acodec libvorbis 
-ab 64k -ac 1 lists.webm

Please provide any additional information below.
- Encoding to other formats with other codecs doesn't cause the same issue 
(which is why I filed a report here instead of with FFMPEG
- Debug info can be found here: 
http://superuser.com/questions/361770/ffmpeg-encoded-video-seeking-is-quantised-
in-vlc. 
- Converting under windows with the ffmpeg provided by Miro Video Converter 
doesn't cause this problem (though file size is 3x larger!). The only 
difference in output I can see is this:

Miro:
    encoder         : Lavf52.84.0
    Stream #0.0: Video: libvpx, yuv420p, 640x480, q=2-31, 600 kb/s, 1k tbn, 20 tbc
    Stream #0.1: Audio: libvorbis, 48000 Hz, 1 channels, s16, 64 kb/s
Stream mapping:

Arch Linux:
    encoder         : Lavf53.21.0
    Stream #0.0: Video: vp8, yuv420p, 640x480 [SAR 1:1, DAR 4:3], q=-1--1, 600 kb/s, 1k tbn, 20 tbc
    Stream #0.1: Audio: libvorbis, 48000 Hz, 1 channels, s16, 64 kb/s
Stream mapping:

Original issue reported on code.google.com by b.coughl...@gmail.com on 27 Nov 2011 at 7:07

GoogleCodeExporter commented 9 years ago

Original comment by iss...@webmproject.org on 27 Nov 2011 at 7:10

GoogleCodeExporter commented 9 years ago 
As you can see from the superuser.com link, the problem turned out to be the 
default setting for the -g option in ffmpeg (mapped to kf_max_dist), and 
doesn't appear to be a libvpx bug at all.

Original comment by ba...@091labs.com on 27 Nov 2011 at 5:38

GoogleCodeExporter commented 9 years ago 
As mentioned above, recent versions of ffmpeg have changed the mapping to leave 
kf_max_dist (-g) at the library default level if unset by the user.
libvpx's default is 9999 frames.

Original comment by jz...@google.com on 6 Dec 2011 at 11:31