View Issue Details

IDProjectCategoryView StatusLast Update
0000313Cinelerra-GG[All Projects] Bugpublic2020-08-16 18:44
ReporterAndrea_Paz Assigned ToPhyllisSmith  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version2019-08 
Target VersionFixed in Version2020-03 
Summary0000313: Problem rendering Ogg format
DescriptionA bug from user D. Quinton.

I have a problem achieving consistent results when rendering with ffmpeg/ogg format - the bitrate of resulting video is always unpredictable:


set bitrate to 9000000 and result is blotchy, from good 20mbps source;

set q=8 resulting bitrate varies each time Cin is started, can be very high,

set q=7 or q=6 bitrate very high, even down to q=1 still high, then set back to q=7 and bitrate is at 8.5Mbps.

some results I've had
q=9 11mbps

q=10 79mpbs

q=5 107mpbs

q=2 28mpbs

q=7 11.5mpbs

With ogg vorbis I used to succeed better. Wild bitrates only create huge files that are difficult to store.




2020-08-09 02:07

manager   ~0003892

It seems to be good enough and will close in a couple of days.


2020-08-02 08:18

reporter   ~0003862

Great feedback and thanks for making improvements to the render codecs. Its taken me ages to get here and see the bug I reported ...being located in deep jungle the last four years with no internet except for town excursions, two days per three months... boy I had no time except to hammer off some emails to the mailing list. Since June I have a satellite link up, highspeed internet.

I've just made some tests with render to Ogg with ffmpeg. Low and behold, with using the Q settings..
Q=1 2.7 mbps
Q=2 4.1 mbps
Q=3 5.9 mbps
Q=7 20.7mbps

which shows much better proportionality

and setting bitrate
1500000 produced 1.5mbps !
2600000 produced 2.6mbps !

Except that the quality must be set in the both the top bitrate field and the options field below.

And occasionally, every two renders probably, with bitrate set, reopen video preset and the bitrate has gone, and quality is back up

Having done all this, I may now settle with h265 any way.


2020-03-15 18:29

manager   ~0002904

About: [ogg @ 0x575b9620]Broken file, keyframe not correctly marked.
Yup. "Correctly marked" seems to be the issue alright. Sort of like,
your keyframes are not a mammal as far as standards go. The cinelerra
write_frame simply delivers a series of frames, and it is up to the codec
and muxer to create a sequence of frames in packets (or packet of frames).
It is not my place to say where those keyframe go. As far as I can tell, it
looks like the "granulepos" of a frame, its position, seems to be a version
dependent value to start with. Seems like the best way to decode these
files is use a linear search for keyframes, and not depend on the power of 2
method in the original code. I suspect the muxer should track the keyframe
flag, but there is no interface to force or flag keyframes (as far as I know).


2020-03-14 22:04

reporter   ~0002902

Well, I'm still seeing

[theora @ 0x57710c80]7 bits left in packet 82
[ogg @ 0x575b9620]Broken file, keyframe not correctly marked.

if I try to play file (even just demuxed with oggz-rip video! So, it was not container-level muxing bug ..I hope ....) with mplayer/libavformat demuxer..

Now, I searched a lot, and found this page, finally:
The decoder logically unpacks integers by first reading the MSb of a binary integer from the logical bitstream, followed by the next most significant bit, etc., until the required number of bits have been read. When unpacking the bytes into bits, the decoder begins by reading the MSb of the integer to be read from the most significant unread bit position of the source byte, followed by the next-most significant bit position of the destination integer, and so on up to the requested number of bits. Note that this differs from the Vorbis I codec, which begins decoding with the LSb of the source integer, reading it from the LSb of the source byte. When all the bits of the current source byte are read, decoding continues with the MSb of the next byte. Any unfilled bits in the last byte of the packet MUST be cleared to zero by the encoder.
----quote end----

Apparently Theora in ogg and vorbis in ogg not very same thing ... and ogg video usually end with .ogv ? (but this is cosmetical, unlike those keyframe errors ..)

It seems even bitstream format in theora video was not very stable until last minute?
Because lastFrameNo has version_3_2_1 added in, and because firstFrameNo is calculated relative to that, lastFrameNo, firstFrameNo, keyframeno and frameno should be frame numbers for Theora version >= 3.2.1, otherwise they're indexes.

Theora, the much-hyped video codec abandoned by On2 and adopted by Xiph, naturally needs its very own timestamp format. In usual Ogg manner, the timestamp refers to end of the display interval of the last frame obtained after decoding the last packet of the page, but not without a twist. The 64-bit timestamp is split into two fields. The first of these fields encodes the frame number, starting from one, of the key frame most recently preceding the frame to which the timestamp applies. The second timestamp field encodes the number of frames, this time starting from zero, since the most recent key frame. The bit position of the field split is specified by the Theora stream header.
And all this just after few hours of searching, not counting msgs on ffmpeg-user lists and even Cinelerra's old mail list !
from 2016 ...

Yeah for complicated multimedia world ....


2020-02-29 20:07

manager   ~0002851

OGG as a render option has been rewritten and added back as an option to the render menu. This was quite difficult, taking 2 weeks, and still may not provide the desired results. However, in at least 2 well structured cases, using ydiff with the original video and the rendered video to compare input versus output, it looks very good. Also, the sizes are comparable.


2019-11-03 00:07

manager   ~0002380

Last edited: 2020-02-29 20:02

View 2 revisions

Exactly ... in February, 2019 the code for native ogg/vorbis was removed because too many errors/not working and ffmpeg version should be better maintained. GG had been consistently fixing the errors in the native OGG code for some time but whenever a new release of the libraries ogg, vorbis, and theora became available it would be broken again. It became a nightmare to continue to repair the native ogg and so the assumption was that ffmpeg developers had more help and would keep it going.

There is no plan to pick up the old nightmare, but I will look to see if there is some way to control the out of control inconsistent results.

Issue History

Date Modified Username Field Change
2019-10-03 19:43 Andrea_Paz New Issue
2019-10-03 19:43 Andrea_Paz Tag Attached: Rendering
2019-11-03 00:07 PhyllisSmith Note Added: 0002380
2019-11-03 00:07 PhyllisSmith Assigned To => PhyllisSmith
2019-11-03 00:07 PhyllisSmith Status new => acknowledged
2020-02-29 20:02 PhyllisSmith Note Edited: 0002380 View Revisions
2020-02-29 20:07 PhyllisSmith Note Added: 0002851
2020-02-29 20:07 PhyllisSmith Status acknowledged => feedback
2020-03-14 22:04 Andrew-R Note Added: 0002902
2020-03-15 18:29 PhyllisSmith Note Added: 0002904
2020-08-02 08:18 quintao Note Added: 0003862
2020-08-09 02:07 PhyllisSmith Status feedback => resolved
2020-08-09 02:07 PhyllisSmith Resolution open => fixed
2020-08-09 02:07 PhyllisSmith Fixed in Version => 2020-03
2020-08-09 02:07 PhyllisSmith Note Added: 0003892
2020-08-16 18:44 PhyllisSmith Status resolved => closed