 |
It seems to be good enough and will close in a couple of days. |
 |
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. |
|
|
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). |
 |
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: http://smeans.com/what-i-hate-about-the-theora-codec/ ---quote--- 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? https://bugzilla.mozilla.org/show_bug.cgi?id=644045 ---quote-- 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. --- Confusing! https://hardwarebug.org/2008/11/17/ogg-timestamps-explored/ Theora 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 ... https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q4/005343.html Yeah for complicated multimedia world .... |
|
|
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. |
|
|
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. |
- Anonymous
