сб, 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_avcultra.html#tabs-1

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.


"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.