FFMPEG produces OGV videos whose duration can't be estimated by Totem, VLC and Dragon Player

[gouessej]

Summary of the bug:
Most players under Mageia Linux are unable to run the OGV videos converted from MP4. They don't start automatically in Totem, VLC and Dragon Player, and they don't start at all in Totem and Dragon Player, they indicate that the duration is 0 seconds.

ffprobe indicates:
nb_frames=N/A
nb_read_frames=132
nb_read_packets=N/A

ffplay tells:
"Stream #1: not enough frames to estimate rate; consider increasing probesize"
but following this advice has no effect.

How to reproduce:
ffmpeg -i Video20150609_185820_.mp4 -q:v 10 -q:a 10 -analyzeduration 2147483647 -probesize 2147483647 -report -y Video20150609_185820.ogv

ffmpeg version: 2.7 (static binary build downloaded 10/06/2015)

[gouessej]

input file (MP4)

[Carl Eugen Hoyos]

Please test current FFmpeg git head and please provide an ogv file for which the other players show the correct duration.
Note that FFmpeg does show the correct duration for the output file here.

[gouessej]

I'll build FFMPEG as soon as possible. I'm under Mageia Linux 4.1, I tried with vlc 2.1.6, totem 3.10 and dragon 4.12.

Please can you tell me exactly which command you used to show the duration of the video? I'd like to use the same command.

I will provide an ogv file exhibiting the expected behaviour very soon.

[gouessej]

Firefox 31.7.0 isn't concerned by this bug.

This ogv file works flawlessly with ffplay, Mozilla Firefox, Dragon, Totem and VLC:
​https://videos.files.wordpress.com/QRXrtxyt/christel-keiser-01_fmt1.ogv

ffplay shows the correct duration (5:28).

[gouessej]

VLC 2.1.6 fails to show the correct duration in the bottom right corner for the converted video (OGV) whereas it shows the correct duration for the original video (MP4). It starts the buggy videos only on demand, when I click on the "play" button and the longer the buggy ogv video is, the longer it takes to start playing it.

Note that ffplay shows the correct duration in all cases, sorry if it wasn't clear or if my explanations were confusing.

[Carl Eugen Hoyos]

Any chance that we could test a ten seconds video instead of one second?
(I cannot reproduce your issue, totem shows the duration fine.)

Please test vlc 2.2.1, nothing else is supported.

[Carl Eugen Hoyos]

I tested the following command:

$ ffmpeg -i christel-keiser-01_fmt1.ogv out.ogv

FFmpeg, vlc and totem all show the correct duration for the output file.

[gouessej]

Replying to cehoyos:

Any chance that we could test a ten seconds video instead of one second?
(I cannot reproduce your issue, totem shows the duration fine.)

Which version of totem do you use?

Please test vlc 2.2.1, nothing else is supported.

Ok I'll try to play the video with this version of VLC.

Note that when I convert the video with this online service, dragon succeeds in playing it but totem still shows "0 seconds":
​http://video.online-convert.com

The difference is in the compatible brands: COMPATIBLE_BRANDS: isomiso2avc1mp41 (working) isom3gp4 (not working at all with dragon). In both cases, VLC 2.1.6 shows 0:00 and Totem shows "0 seconds".

[gouessej]

Replying to cehoyos:

I tested the following command:

$ ffmpeg -i christel-keiser-01_fmt1.ogv out.ogv

FFmpeg, vlc and totem all show the correct duration for the output file.

I get tons of error messages when I try to do the same:

[ogg @ 0x4246ce0] Non-monotonous DTS in output stream 0:1; previous: 14453954, current: 14453888; changing to 14453955. This may result in incorrect timestamps in the output file.
[libvorbis @ 0x407cce0] Queue input is backward in time

[gouessej]

Replying to cehoyos:

I tested the following command:

$ ffmpeg -i christel-keiser-01_fmt1.ogv out.ogv

FFmpeg, vlc and totem all show the correct duration for the output file.

Despite the error messages during the conversion, I confirm that vlc and totem show the correct duration for this output file on my machine too. Note that the converted file is smaller than the original file. The frame rate is 25.

[gouessej]

When I do this:
ffmpeg -i Video20150609_185820_.mp4 Video20150609_185820.ogv

the video is horrible but works in all tested players and they show the correct duration. Note that this time I see COMPATIBLE_BRANDS: isomiso2avc1mp41 when using ffplay.

[gouessej]

When I add "-q:v 6", the compatible brands are again isomiso2avc1mp41 but the wrong duration appears anew in Totem and VLC. The problem seems to come from that.

[gouessej]

In the meantime, I confirm that VLC 2.1.6 shows the right duration on longer ogv videos, I've just tried with a converted video during about 18 seconds. There is just a problem of startup on very short videos sometimes but it has probably nothing to do with ffmpeg.

The problem is still there with totem and dragon.

[gouessej]

The duration is still wrong (00:00) in VLC 2.1.6 on a longer video when I include the part that prints "Stream #1: not enough frames to estimate rate; consider increasing probesize" with ffmpeg.

I'll upload this long video on my FTP soon.

[gouessej]

I can't compile VLC 2.2.1:
codec/avcodec/video.c: In function ‘InitVideoDec’:
codec/avcodec/video.c:344:25: erreur: ‘CODEC_FLAG_OUTPUT_CORRUPT’ undeclared (first use in this function)

p_context->flags |= CODEC_FLAG_OUTPUT_CORRUPT;

codec/avcodec/video.c:344:25: note: each undeclared identifier is reported only once for each function it appears in
Makefile:13985: recipe for target 'codec/avcodec/libavcodec_plugin_la-video.lo' failed
Makefile:17327: recipe for target 'all-recursive' failed
Makefile:7725: recipe for target 'all' failed
Makefile:2233: recipe for target 'all-recursive' failed
Makefile:2117: recipe for target 'all' failed
make: * [all] Error 2

[gouessej]

Wrong duration (00:00 and --:--) in VLC 2.1.6 for the long OGV video

[gouessej]

The long video whose duration is wrongly shown (00:00 and --:--) in VLC 2.1.6 in its bottom right corner is here:
​http://tuer.sourceforge.net/videos/Video20150609_185820.ogv

The upload is still in progress.

[Carl Eugen Hoyos]

If your distribution does not offer current vlc, you have to compile it with internal FFmpeg.

[Carl Eugen Hoyos]

Replying to gouessej:

​http://tuer.sourceforge.net/videos/Video20150609_185820.ogv

410

[Carl Eugen Hoyos]

Replying to gouessej:

When I add "-q:v 6", the compatible brands are again isomiso2avc1mp41

I cannot reproduce this.

but the wrong duration appears anew in Totem and VLC.

I cannot reproduce this.

[gouessej]

Replying to cehoyos:

Replying to gouessej:

​http://tuer.sourceforge.net/videos/Video20150609_185820.ogv

410

I'll upload another video that doesn't exceed the max size but with a duration greater than one second, sorry.

[gouessej]

You can find the original file (longer, 3 seconds) here:
​http://tuer.sourceforge.net/videos/Video20150609_185820_.mp4

the converted file:
​http://tuer.sourceforge.net/videos/Video20150609_185820.ogv

and the report:
​http://tuer.sourceforge.net/videos/ffmpeg-20150613-185812.log

[gjdfgh]

Have you considered that ogv should not be used? It's a terrible container format, and issues like this one are the least problem.

Use mkv instead.

[gouessej]

Are those warnings important? I'm compiling the very latest version of FFMPEG.

libavformat/utils.c: In function ‘av_stream_get_end_pts’:
libavformat/utils.c:119:5: attention : ‘pts’ is deprecated (declared at libavformat/avformat.h:861) [-Wdeprecated-declarations]

return st->pts.val;

libavformat/utils.c: In function ‘avformat_find_stream_info’:
libavformat/utils.c:3039:9: attention : ‘max_analyze_duration’ is deprecated (declared at libavformat/avformat.h:1407) [-Wdeprecated-declarations]

max_analyze_duration = ic->max_analyze_duration;

[gouessej]

Replying to gjdfgh:

Have you considered that ogv should not be used? It's a terrible container format, and issues like this one are the least problem.

Use mkv instead.

Webm videos don't work very well on very low end machines, especially computers whose CPU has a single core.

If the FFMPEG team considers that OGV shouldn't be used, then OGV shouldn't be supported in FFMPEG. I really do my best to help the developers to reproduce this bug, I have already spent hours and I'm going to try with the very latest version when the compilation has come to an end.

[gjdfgh]

WebM is different from Matroska (WebM only supports VP8 and VP9.)

Matroska itself does support exactly the same codecs as OGV, and more. This includes Theora and Vorbis (the codecs you apparently want to use). The CPU usage for decoding will be exactly the same. Matroska isn't slower to read than OGV either.

You are probably under the mistaken impression that Matroska is inherently slower than OGV, because you've only looked at Matroska files using H264. H264 is indeed slower to decode than Theora, but again, you can use Theora in Matroska.

(By the way, while I'm not entirely sure, I bet using mpeg2 would possibly be faster to decode than Theora, because FFmpeg likely has more optimizations for such an ubiquitous codec as mpeg. But I'm just guessing and don't have the knowledge or numbers to back this up.)

[gouessej]

Replying to gjdfgh:

WebM is different from Matroska (WebM only supports VP8 and VP9.)

Matroska itself does support exactly the same codecs as OGV, and more. This includes Theora and Vorbis (the codecs you apparently want to use). The CPU usage for decoding will be exactly the same. Matroska isn't slower to read than OGV either.

You are probably under the mistaken impression that Matroska is inherently slower than OGV, because you've only looked at Matroska files using H264. H264 is indeed slower to decode than Theora, but again, you can use Theora in Matroska.

(By the way, while I'm not entirely sure, I bet using mpeg2 would possibly be faster to decode than Theora, because FFmpeg likely has more optimizations for such an ubiquitous codec as mpeg. But I'm just guessing and don't have the knowledge or numbers to back this up.)

Matroska isn't supported by the html5 video tag. I don't use MP4 because I'm against software patents and I really think that webm encourages planned obsolescence.

Videopress uses ogv under the hood and the working ogv video I gave as an example was produced by Videopress. It is possible to use ogv successfully.

[gjdfgh]

Matroska isn't supported by the html5 video tag.

But OGV is? No it isn't. OGV is just a pain generator.

[gouessej]

Replying to gjdfgh:

Matroska isn't supported by the html5 video tag.

But OGV is? No it isn't. OGV is just a pain generator.

It works in Firefox, Iceweasel, Opera, Chrome and Chromium. I don't mind MS IE/Edge and Safari.

[gjdfgh]

That's actually just 2 browsers. (Or 3, if you _really_ want to count Opera as separate browser.) Anyway, you don't have any reason not to use a better format.

And OGV of all things? OGV is such a terrible nightmare technically. And you use that on purpose? Once more I lose faith in humanity.

[gouessej]

Replying to gjdfgh:

That's actually just 2 browsers. (Or 3, if you _really_ want to count Opera as separate browser.) Anyway, you don't have any reason not to use a better format.

And OGV of all things? OGV is such a terrible nightmare technically. And you use that on purpose? Once more I lose faith in humanity.

Matroska isn't supported by the video tag, otherwise it would have been an interesting solution and I tried webm before using ogv.

[gouessej]

This bug isn't reproducible in VLC 2.2.0, someone confirmed it shows the correct duration:
​http://jogamp.org/log/irc/jogamp_20150612234958.html#l33

[gouessej]

The bug is reproducible under Ubuntu 14.04 LTS with Totem 3.10.1 and Xine 0.99.7:
​http://jogamp.org/log/irc/jogamp_20150612234958.html#l49

Someone else confirmed that the bug isn't reproducible with VLC git master (2.2.1?).

[gouessej]

The gnome file manager nautilus version 3.10.1 fails to report it too as it relies on Videos (=Totem):
​http://jogamp.org/log/irc/jogamp_20150612234958.html#l66

[Carl Eugen Hoyos]

Replying to gouessej:

You can find the original file (longer, 3 seconds) here:
​http://tuer.sourceforge.net/videos/Video20150609_185820_.mp4

I converted this file with the following command line:

$ ffmpeg -i Video20150609_185820_.mp4 -q:v 6 out.ogg

The output file shows the correct duration with vlc, totem and FFmpeg here.

Please only reopen this ticket if you can provide a longer input file. Either upload to ​http://www.datafilehost.com/ (100MB limit) or read https://ffmpeg.org/bugreports.html (NO hard filesize limit).

[gouessej]

I use the following command line:
ffmpeg -i Video20150609_185820_.mp4 -q:v 10 -q:a 10 -analyzeduration 2147483647 -probesize 2147483647 -report -y Video20150609_185820.ogv

I get the following output:
ffmpeg started on 2015-06-14 at 19:39:48
Report written to "ffmpeg-20150614-193948.log"
ffmpeg version 2.7- ​http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2015 the FFmpeg developers

built with gcc 4.9.2 (Debian 4.9.2-20)
configuration: --enable-gpl --enable-version3 --disable-shared --disable-debug --enable-runtime-cpudetect --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --cc=gcc-4.9
libavutil 54. 27.100 / 54. 27.100
libavcodec 56. 41.100 / 56. 41.100
libavformat 56. 36.100 / 56. 36.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 16.101 / 5. 16.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.100 / 1. 2.100
libpostproc 53. 3.100 / 53. 3.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Video20150609_185820_.mp4':

Metadata:

major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.36.100

Duration: 00:00:03.03, start: 0.033333, bitrate: 11221 kb/s

Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 11207 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
Metadata:

handler_name : VideoHandler

Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:

handler_name : SoundHandler

Output #0, ogg, to 'Video20150609_185820.ogv':

Metadata:

major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.36.100
Stream #0:0(eng): Video: theora (libtheora), yuv420p, 1920x1080, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default)
Metadata:

handler_name : VideoHandler
encoder : Lavc56.41.100 libtheora
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41

Stream #0:1(eng): Audio: vorbis (libvorbis), 48000 Hz, stereo, fltp (default)
Metadata:

handler_name : SoundHandler
encoder : Lavc56.41.100 libvorbis
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41

Stream mapping:

Stream #0:0 -> #0:0 (h264 (native) -> theora (libtheora))
Stream #0:1 -> #0:1 (aac (native) -> vorbis (libvorbis))

Press [q] to stop, ? for help
frame= 91 fps=2.9 q=0.0 Lsize= 22066kB time=00:00:03.04 bitrate=59306.7kbits/s dup=1 drop=0
video:21862kB audio:101kB subtitle:0kB other streams:0kB global headers:7kB muxing overhead: 0.474406%

I still reproduce this bug. Totem 3.10.1 doesn't play the video and claims that the duration is "0 seconds".

[Carl Eugen Hoyos]

Replying to gouessej:

  Duration: 00:00:03.03, start: 0.033333, bitrate: 11221 kb/s

Please reopen this ticket (only) if you can provide a longer input sample.

[gouessej]

Replying to cehoyos:

Replying to gouessej:

  Duration: 00:00:03.03, start: 0.033333, bitrate: 11221 kb/s

Please reopen this ticket (only) if you can provide a longer input sample.

I'm uploading the original video (MP4, 149 MB) on Data File Host right now.

[Carl Eugen Hoyos]

Replying to gouessej:

I'm uploading the original video (MP4, 149 MB) on Data File Host right now.

Data File Host has a 100MB limit. But I strongly believe that you could find a file that is longer than three seconds but less than 100MB if you try.

[gouessej]

The MP4 file is here:
​http://www.datafilehost.com/d/ef48cf14

[Carl Eugen Hoyos]

Do I understand correctly that you actually don't want to report that GStreamer does not show a duration for the output file (it does here) but that it does not play the output file (I can reproduce that)?

[gouessej]

Replying to cehoyos:

Do I understand correctly that you actually don't want to report that GStreamer does not show a duration for the output file (it does here) but that it does not play the output file (I can reproduce that)?

Actually, I don't know what Dragon (the default KDE video player) uses but I can file a bug report against Gstreamer too. Sorry, I'm not looking for another flame war.

[Carl Eugen Hoyos]

I am just trying to understand your issue: You reported that some players do not show a duration but my guess is currently that your actual issue is that the output file did not play for you. Am I wrong?

[gouessej]

Replying to cehoyos:

I am just trying to understand your issue: You reported that some players do not show a duration but my guess is currently that your actual issue is that the output file did not play for you. Am I wrong?

I use FFMPEG to convert MP4 files from my smartphone (Samsung Galaxy 3 4G/LTE i9305) into OGV. The resulting videos can't be played in several major players whereas the original files can and those players are able to play some OGV files successfully. I think that something goes wrong during the conversion, even VLC 2.2.0 stutters a lot when playing them.

[Carl Eugen Hoyos]

The issue that GStreamer (or at least some versions of GStreamer) cannot detect audio in high-bitrate ogg files (bitrate > 25MBit) and subsequently fails playback completely can be reproduced when reencoding the attached sample Video20150609_185820_.mp4 (the duration is always correctly shown here). It works fine here with -q:v 6 and -b:v 15M (leading to ~20MBit) and fails here with -q:v 7 and -b:v 20M (leading to ~25MBit).
I don't think there is any indication for a bug in FFmpeg.
The output file does not play here with GStreamer, I believe the issue is reproducible with versions 1.0 and 0.10.

$ ffmpeg -i Video20150609_185820_.mp4 -q:v 7 out.ogv
ffmpeg version N-72941-g4ec14ce Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --enable-libtheora --enable-libvorbis
  libavutil      54. 27.100 / 54. 27.100
  libavcodec     56. 41.100 / 56. 41.100
  libavformat    56. 36.100 / 56. 36.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 17.100 /  5. 17.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Video20150609_185820_.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.36.100
  Duration: 00:00:01.03, start: 0.033333, bitrate: 10523 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 10727 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 130 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Output #0, ogg, to 'out.ogv':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.36.100
    Stream #0:0(eng): Video: theora (libtheora), yuv420p, 1920x1080, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc56.41.100 libtheora
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
    Stream #0:1(eng): Audio: vorbis (libvorbis), 48000 Hz, stereo, fltp (default)
    Metadata:
      handler_name    : SoundHandler
      encoder         : Lavc56.41.100 libvorbis
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> theora (libtheora))
  Stream #0:1 -> #0:1 (aac (native) -> vorbis (libvorbis))
Press [q] to stop, [?] for help
frame=   31 fps=7.8 q=0.0 Lsize=    3441kB time=00:00:01.04 bitrate=26962.4kbits/s dup=1 drop=0
video:3405kB audio:12kB subtitle:0kB other streams:0kB global headers:7kB muxing overhead: 0.668602%

[gouessej]

Thank you for your detailed explanations, they will be very useful to fix the bug within GStreamer. Thank you for your patience too. I'll fill a bug report against GStreamer as soon as possible.

[Carl Eugen Hoyos]

Please note that I did not test current GStreamer!
Additionally, I (strongly) suggest you do not report "no duration estimated" if your actual issue is "no playback".

[gouessej]

Replying to cehoyos:

Please note that I did not test current GStreamer!
Additionally, I (strongly) suggest you do not report "no duration estimated" if your actual issue is "no playback".

Ok but Totem 3.10.1 still shows "0 seconds" and plays nothing. I see what you mean. I'll do my best. Then, I have to get the source code of GStreamer, build it and test it with the resulting video.

[gouessej]

Bug reported against GStreamer:
​https://bugzilla.gnome.org/show_bug.cgi?id=752279