сб, 27 июн. 2026 г., 04:48 Phyllis Smith <phylsmith2017@gmail.com>:
I strongly suggest to put b=100M back, alongside with comment noting that
b here changes with avcintra-class, and avcntra-class can be one of
"50", "100", "200", "300", "480"
Good idea -- I will do that tomorrow as I did not understand the reason and then Quintano can delete it himself if he does not like the size of the rendered file and get something that works for him, even if not true avcintra (line in BT #677 that he stated "Yes,, with Mov container, files are good, but huge bitrate with large files. No option similar to avcintra 100." After I change it, I will remind him in 677 of how to delete b=10m.
I think mxf_h264_b profile still more suited for this, but even with strict=-1 added there not all my random files encode. I'll experiment more.
On Fri, Jun 26, 2026 at 7:35 PM Andrew Randrianasulu < randrianasulu@gmail.com> wrote:
сб, 27 июн. 2026 г., 04:17 Phyllis Smith <phylsmith2017@gmail.com>:
Andrew, so now I am totally confused. Quintano in BT #677 thought it was working well enough for what he needed in 2025. So with the addition of "q=1" is it now working? Guess only $$$ hardware could ever check!
It was working in sense file was playable by other ffmpeg based software ...? May be at some point libavcodec was signalling g=1 in such case on its own but then stopped?
https://www.vrt.be/nl/assets/files/2024-09/Gouden_standaard_AS-VRT-AVC-intra...
See, this one for example strictly talks about
Signal Standard 4 (= HD422 1920x1080, 23.98p/25p/29.97p/50i/59.94i)
there surely others but some just blocked in russia and not in archive.org.
I strongly suggest to put b=100M back, alongside with comment noting that b here changes with avcintra-class, and avcntra-class can be one of
"50", "100", "200", "300", "480"
May be you will have better luck searching for "avcintra whitepaper". I remember reading it, just not saved sadly.
On Fri, Jun 26, 2026 at 6:52 PM Andrew Randrianasulu < randrianasulu@gmail.com> wrote:
сб, 27 июн. 2026 г., 03:42 Andrew Randrianasulu < randrianasulu@gmail.com>:
сб, 27 июн. 2026 г., 02:06 Phyllis Smith <phylsmith2017@gmail.com>:
9 of the mxf render formats have been modified as provided by Andrew and checked into GIT after I tested each of them. Reminder - the Audio only worked for me if I set the samplerate to 48000, but fps worked at either 29.x or 59.x. But the mxf_avcintra_100.mxf did NOT have the b=100m added (for the bitrate) since it was not there before and made the file huge by 10x. Size without that was comparable to that when running ffmpeg 7.x where the mxf_avcintra_100.mxf render format was working without issues.
it was NOT working :(
it made file that was avcintra in name only :(
Sorry I did not catch this earlier.
Those broadcast standards even stricter than bluray ones, so ideally we should test our output files in those big $$$ hw boxes used on TV stations. But we do not have anyone with such access ...
But this particular error was mine I think, I just slapped profile together hoping libx264 will figure it out on its own. Well, it did not!
Small file not the goal here, each frame is keyframe is (long gop h264 is awful for editing, too many frames must be decoded in weird order to get any random frame)
https://eww.pass.panasonic.co.jp/pro-av/support/content/download/EN/backup_a...
I do not think those boxes even accepted SD sized avc-INTRA ?
x264 accept it, all fine, but hw probably will not :(
May be we should add line comment in profile saying wich modes exist?
I think avcintra200 was there but we left this "to the user"
./x264.c:const char * const x264_avcintra_class_names[] = { "50", "100", "200", "300", "480", 0 };
and Sony and Panasonic has their own sub versions, ha!
Sorry for such mess. :(
For the Manual, I also finally remembered to fix Trouble.tex, section 18.7, to add the -l parameter reference that Andrew added last month to the command line description
*IgorB note*: I bcc'ed you here so that you know it went to the Mailing List and hopefully to you via the Mailing List as well as your direct email.
On Fri, Jun 26, 2026 at 9:14 AM Andrew Randrianasulu < randrianasulu@gmail.com> wrote:
> > > пт, 26 июн. 2026 г., 18:04 Phyllis Smith <phylsmith2017@gmail.com>: > >> Andrew, I believe the simplest solution, which I should have tried >> in the very beginning, is just to add these two lines to the >> mxf_avcintra_100.mxf file: >> >>> keyint_min=25 >>> x264-params keyint=25 >>> >> At least that worked for me and so far only 48000 audio samplereate >> has worked for any of the mxf render formats that I tested. I will check a >> modified mxf_avcintra_100.mxf file into GIT after I do more testing. Sorry >> for the extra work I have imposed on you. >> > > > point of avcINTRA is to have intra-only (all frames are keyframes) > file, in my understanding. > > https://www.tvtechnology.com/equipment/panasonics-avcintra-codec > > "As an intraframe approach, it captures and preserves the greatest > amount of information while offering the greatest flexibility. Unlike > long-GOP approaches, it was explicitly designed and optimized for broadcast > and production use rather than low-bandwidth distribution." > > for just h264 in mxf we have > > mxf_h264_b.mxf > > > >> >> On Fri, Jun 26, 2026 at 4:50 AM Andrew Randrianasulu < >> randrianasulu@gmail.com> wrote: >> >>> I think my patch >>> >>> "Do not set our options for mxf muxer" >>> >>> is not needed really, because it was different set of errors and >>> it only "worked" because I failed to properly change profiles during my >>> testing on Termux? I'll keep it around just in case. >>> >>> I tried to add g=1 to our DNxHR/dv mxf profiles too just in case, >>> accidently added two .seg profiles I was testing some time ago (for >>> segmented muxing) >>> >>> Changed openjpeg mxf profile to use internal jpeg2000 encoder, >>> libopenjpeg based one is seems to be gone from ffmpeg (note decoder may >>> still be there) >>> >>> Added g=25 to our mxf_h264_annex_b profile, may be it will work >>> after this change? >>> >>> Not really tested yet, too many machines (real and virt) trying to >>> do many things at once. >>> >>> >>> >>> >>>