GNOME Bugzilla – Bug 603070
two-pass (bitrate-based) encoding in pitivi is not easy (requires two manual renders)
Last modified: 2018-05-09 12:40:11 UTC
Exporting in 720/30p from Pitivi using mp3 and XViD VBR creates the same filesize file, no matter the bitrate requested. It uses about 25 mbps bitrate, even if I told it I want an average of 5 mbps. If I use constant bitrate, it does give me the bitrate/filesize I am after. The bug only happens when using VBR. This is Ubuntu 9.10 btw with no third party packages, just whatever found in their various repositories.
This reminds me a bit of bug #593466, if it's related at all.
Eugenia, which codec and container did you choose ? What exact settings did you apply ? Screenshots of main output settings window and individual codec settings window will do
Created attachment 148626 [details] project properties and export settings
Screenshot attachment added, showing project properties and export settings.
The problem is that it's a 2-pass encoding. During the first pass it will not take into account the bitrate but only generate the statistics file, and when you re-encode the 2nd pass it will take it into account. Here are the file sizes of rendering a 27s video: After 1st pass: 59735208 bytes (17 699 320 bits/s) After 2nd pass: 4433922 bytes ( 1 313 754 bits/s) Providing a generic interface for 2 pass encodings is in the todo list. The problem is detecting if encoding elements can do 2-pass-encodings. Dunno whether I should close this bug or not (or whether we have an existing duplicate bug regarding two pass encoding)
I see. I guess you can defer it as a usability/UI bug rather than as it was suggested. I mean, when I saw that dialog, I thought that it was just a 1-pass VBR encoding, not "1 pass out of the 2 passes".
Retitling for clarity / searchability... I hope I understood the explanation correctly. I'm still wondering if Bug #593466 is the same thing though.
Tried rendering a simplistic timeline with ogg/theora/vorbis and tried with two different bitrate settings : 512 and 1024: -rw-r--r-- 1 bilboed bilboed 3695114 Dec 4 16:17 simple-1024.ogg -rw-r--r-- 1 bilboed bilboed 2064803 Dec 4 16:16 simple-512.ogg Seems to work here. Jeff, can you check again ?
This bug is about automating "multiple pass" rendering; comment #8 is probably about bug #593466 instead (and I just figured out why it happens), so reopening.
As I understand it, GStreamer itself deals with "pipelines" and does not really think in terms of passes, as such, this should be dealt with in gnonlin or GES. Pitivi should not have to know about the innards of multipass rendering, it should be transparent. Pitivi should just "ask for a multipass rendering" and let ges/gnonlin do their magic.
There is no plan to handle two pass encoding more gracefully in GStreamer. That could be a feature of gst-transcoder, but there is no plan there either. Please re-open if there is an idea for a better approach
(In reply to Olivier Crête from comment #11) > There is no plan to handle two pass encoding more gracefully in GStreamer. > That could be a feature of gst-transcoder, but there is no plan there either. Not sure where that should be handled tbh. gst-transcoder, having this feature in gst-transcoder wouldn't help with GES implementation :-)