GNOME Bugzilla – Bug 752279
decodebin: high-quality videos in ogv format fail to preroll/play
Last modified: 2018-05-05 15:45:39 UTC
Some versions of GStreamer (1.0 and 0.10) can't detect audio in high-bitrate ogv files (bitrate > 25MBit) and subsequently fails playback completely. I thought that FFMPEG was to blame as I used it to convert a MP4 file into OGV but it's not the case. HOW TO TEST: - download this video: http://www.datafilehost.com/d/ef48cf14 - enter "ffmpeg -i Video20150609_185820.mp4 -q:v 7 out.ogv" - open this video with Totem, Dragon Player or another video player based on GStreamer EXPECTED: - the video runs flawlessly RESULT: - it doesn't start, it shows "0 seconds" as a duration. In the best case, it just shows the very first frame I reproduce this bug under Mageia Linux 4. This comment might be particularly helpful: https://trac.ffmpeg.org/ticket/4613#comment:43
This bug is reproducible with Totem 3.10 and Dragon 4.12.
Thanks for the bug report. Could you make available the .ogv output file as well please?
I have just uploaded a short sample (several seconds) here: http://www.datafilehost.com/d/ac33bdb7
Thanks, I can reproduce this with git master. Likely an issue in decodebin or multiqueue. A manual pipeline works: gst-launch-1.0 filesrc location=752279.ogv ! oggdemux name=d d. ! queue ! theoradec ! queue ! xvimagesink d. ! queue ! vorbisdec ! queue ! progressreport update-freq=1 ! pulsesink
You're welcome. Should the manual pipeline work in this case with an older version of GStreamer?
It looks like the video part of multiqueue fills up to 2 MB while its audio part is empty. This happens after buffers have flown both to audio and video, so there is no size increase allowed anymore IIRC. The 2 MB are made of only 9 buffers. Indeed, this variant of Tim-Philipp Müller's line hangs (replacing queue with multiqueue): gst-launch-1.0 filesrc location=~/Samples/Video20150609_185820.ogv ! oggdemux name=d d. ! multiqueue name=M ! theoradec ! queue ! xvimagesink M. ! vorbisdec ! queue ! progressreport update-freq=1 ! pulsesink Though I do get a frame shown, while gst-play-1.0 does not show a frame at all, which is an unexpected difference at first glance.
Indeed, bumping AUTO_PLAY_SIZE_BYTES in gst/playback/gstdecodebin2.c fixes it. The file does seem to be very coarsely muxed. I count about 60 Theora frames before the first Vorbis data page. These frames come in a lot of pages, so it's not that the muxer was waiting for a page to fill. The first Vorbis page after those 2 seconds of video is 1.1 seconds I think (granpos divided by 44100 to get second ts IIRC).
(In reply to Vincent Penquerc'h from comment #7) > Indeed, bumping AUTO_PLAY_SIZE_BYTES in gst/playback/gstdecodebin2.c fixes > it. > > The file does seem to be very coarsely muxed. I count about 60 Theora frames > before the first Vorbis data page. These frames come in a lot of pages, so > it's not that the muxer was waiting for a page to fill. The first Vorbis > page after those 2 seconds of video is 1.1 seconds I think (granpos divided > by 44100 to get second ts IIRC). Is it caused by the conversion? What is to blame?
I think gst is to blame here, due to its arbitrary "sanity" limits. The muxer that created that file did seem to take the mickey though. While two seconds' worth of video may not be that bad usually, that's a lot in this case. To fix this, we could increase the multiqueue limits, but it's an arbitrary limit so you can always make a file that needs even higher limits, so I'm not sure what to do here to be honest.
(In reply to Vincent Penquerc'h from comment #9) > I think gst is to blame here, due to its arbitrary "sanity" limits. > The muxer that created that file did seem to take the mickey though. While > two seconds' worth of video may not be that bad usually, that's a lot in > this case. > > To fix this, we could increase the multiqueue limits, but it's an arbitrary > limit so you can always make a file that needs even higher limits, so I'm > not sure what to do here to be honest. The original video in OGV is longer, would it be useful? What do you mean about the muxer? Is there a way of mitigating the problem except than lowering the quality?
The video I got from the hosting site is enough to show the problem, there is no need for a longer video. Mitigating the problem in this particular case would mean telling the muxer (ffmpeg ?) to minimize the amount of video it pushes at once into the Ogg stream, so that there is less of it between the comparatively rare audio pages. I think what might be happening is that the muxer uses large audio pages, and outputs them when they reach some set size. If the muxer has a way to set the page latency, setting a lower latency should help get smaller audio pages out more often, which means this will decrease the amount of video frames piling up. Decreasing audio page size may also have the same effect, if the muxer can do that. Of course, this does not fix the overall issue, just this particular case of you encoding this video.
I think it needs to be muxed that way according to the ogg muxing rules, based on the output produced by the vorbis encoder (a 1 second chunk at the beginning). The only way it could be muxed differently is if the vorbis output was in smaller chunks. I suspect the audio at the beginning compresses very well (like silence). The limit is probably still from the time when 320x240 streams ruled the world, I'm sure there are other bugs about problems with pre-rolling of high-bitrate streams (4k etc.).
Those particular pages need to be muxed that way, but I was trying to say that reencoding with smaller audio pages would cause more audio pages, and thus better time muxing. The first Vorbis data page has somehting like 130 packets or so. And it wouldn't be Ogg specific as you say. I can post a patch to bump the limit if you think it's a good idea to try that. As for the value... As a data point, 6 MB isn't enough for this particular video, 7 MB is.
This issue is exactly same as https://bugzilla.gnome.org/show_bug.cgi?id=733235 In the issue, it just increases multiqueue size when one of singlequeue is filled. And with the patch, this file can be played well. Could you review it?
(In reply to Justin J. Kim from comment #14) > This issue is exactly same as > https://bugzilla.gnome.org/show_bug.cgi?id=733235 > In the issue, it just increases multiqueue size when one of singlequeue is > filled. And with the patch, this file can be played well. Thank you very much for your investigation, your patch and your pugnacity. > > Could you review it? I would appreciate that a maintainer spends some time in reviewing your patch. This bug prevents me from adopting the OGV format peacefully.
Based on the description of the issue, this bug doesn't happen with decodebin3 (where there isn't mystical multiqueue sizes).