Avidemux Forum

https://github.com/mean00/avidemux2/commit/efa31757e7d0aed21cb5390fd27724e48a0efaab

I believe that causes an issue with copy/copy mp4 files muxed with avidemux played on PS3.

I'm guessing but it's the simplest revert test.  I would need a windows x64 .zip build to check without that commit.

The video plays normally until a few seconds left and an error code stops the video.

I don't need to give a sample because it happens with all mp4 I've muxed with May 10 nightly.  I'm not doing anything special here. any mkv x264/aac > copy/copy > mp4

Everything is fine with the last April nightly.

Quote from: Anon40213 on May 18, 2021, 02:09:25 PMI believe that causes an issue with copy/copy mp4 files muxed with avidemux played on PS3.

This is purely a demuxer thing, irrelevant for the MP4 muxer.

Please provide samples I asked for.

Quote from: Anon40213 on May 18, 2021, 02:09:25 PMI don't need to give a sample because it happens with all mp4 I've muxed with May 10 nightly.  I'm not doing anything special here. any mkv x264/aac > copy/copy > mp4

I don't have a PS3 to verify that a sample is compatible. So please provide one two – one which works, then the same video remuxed with the May 10 nightly which fails on your PS3.

I've compared the internal structure of mp4 files produced by Avidemux with bundled FFmpeg 4.2.4 (I used 2.7.8 release) vs 4.4 as well as with the regular standalone ffmpeg 4.3.x and noticed one peculiarity in the stts atom / box in the output of Avidemux with FFmpeg 4.4, which matches the behaviour of PS3 to throw an error at the end of the file: the duration of the last frame is set to zero. This is not the case with the output of the MP4 muxer in 2.7.8.

I've uploaded two short samples in a ZIP archive to https://we.tl/t-p0pLbN5bcM, the first one created with the latest Avidemux, the second one is the first file with the duration of the last frame altered to match the duration of all other frames (stts still has two entries, which I cannot modify as this would require the file to be rewritten). Please try both on PS3 and report back.

It is possible that PS3 wants to have the stts table with a single entry (all frames have the same duration), or my first guess was wrong and something else causes the problem, in this case both files will fail to play without errors.

Your samples confuse me because you used the PSP mux option so I'm left wondering if you think PS3/PSP are the same thing.  Both of them did work though because I suppose there is built in PSP compatibility there since they are both PlayStation brand.

I've realised I really do need to give samples so sorry for previously being an idiot.

https://we.tl/t-106KnZkgqj

Contains: SOURCE MKV, APRIL MP4, MAY MP4

File > Open > MKV file > Video Output: Copy > Audio Output: Copy > Output Format: MP4 Muxer > Click Configure > Muxing Format: MP4 > Optimize for Streaming: No optimization > Click OK > Save file.

Quote from: Anon40213 on May 20, 2021, 10:46:01 AMYour samples confuse me because you used the PSP mux option so I'm left wondering if you think PS3/PSP are the same thing.

Yes, definitely, had to duckduckgo both (never came in touch with such hardware).

Thank you for the samples. As both my samples worked, it is clear that the problem is not related to stts and frame duration.

My second guess is that PS3 doesn't understand or doesn't like the content of the btrt atom / box (bitrate info), written by the newer libavformat in FFmpeg 4.4 when saving in MP4 mode. This atom is not written in PSP mode and it was not written by FFmpeg versions prior to 4.4.

We probably should try to find out whether it is the pure presence of the btrt atom which confuses PS3 or whether it is not happy with its content like the maximum bitrate (which is completely fake, hardcoded in Avidemux libavformat wrapper code).

I've uploaded your MP4-MAY sample to https://we.tl/t-80LnTwLais with 3 bytes starting at offset 0x10FBB09 modified to reduce the maximum video bitrate from 9000 kbps to 4000 kbps (which should be a reasonable value).

If this change satisfies the expectations of PS3, Avidemux is at fault and I need to try to implement a fix. If the problem persists, not supporting (or silently ignoring) btrt atom is a PS3 bug and there will be no fix as using the PSP mode solves the problem (unless you need to save video without audio, which libavformat in PSP mode would refuse to do).

Unfortunately the problem indeed persisted.  I guess it's either PSP or find something else ASAP if I want to stay up to date.

Is there a ffmpeg ticket or commit about this change they made? I'd at least like to find out why this change had to be implemented all of a sudden.

This FFmpeg enhancement was committed 4 year 8 months ago: avformat/movenc: implement writing of the btrt box.
It took that long from git master to release (ffmpeg devs are definitely not happy about that) bug report with patch until the enhancement made it into git master.

I looked into their code and I am not sure that it makes a lot of sense to write this optional atom. The problem is the maximum bitrate. Avidemux doesn't know it when it saves a video stream and while libavformat does a splendid job calculating the average bitrate, it uses the user-supplied value as the max bitrate if it is greater than the average (else we get max bitrate = average bitrate). It also doesn't calculate the buffer size (or it cannot guess anything reasonable).

Why does using the PSP muxing mode pose a problem for you?

Well, I throw my hands up.  You say it doesn't make much sense, seemingly only one person asked for it for streaming.  Couldn't they have created their own ffmpeg build with the patch?  So what about not streaming, that's why I select no optimization isn't it, to not have this atom? Or is playing a mp4 file for private viewing classified as streaming?

PSP feels dirty, it's for PSP.  What if I wanna play the mp4 elsewhere in the future and this PSP mux is an issue.

For a fully correct assessment of PS3 compatibility, here is the SOURCE remuxed with the Avidemux off the current git master with FFmpeg patched to skip writing btrt atoms: https://we.tl/t-MYh9BfWook

Quote from: Anon40213 on May 21, 2021, 11:48:27 AMPSP feels dirty, it's for PSP.  What if I wanna play the mp4 elsewhere in the future and this PSP mux is an issue.

I don't think this can be a problem. At worst, you will need to remux the file to the usual MP4.

Quote from: Anon40213 on May 21, 2021, 11:48:27 AMYou say it doesn't make much sense, seemingly only one person asked for it for streaming.

Well, writing software is not about majorities, it is mostly about merits.

Quote from: Anon40213 on May 21, 2021, 11:48:27 AMCouldn't they have created their own ffmpeg build with the patch?

They actually did. But as always, hardly anyone (for sure no-one with a PS3) tested developer builds.

Quote from: Anon40213 on May 21, 2021, 11:48:27 AMSo what about not streaming, that's why I select no optimization isn't it, to not have this atom?

This atom is standard-compliant and (formally) valid. There is no reason not to write it, apart from catering for broken implementations of the standard. The default streaming optimization rewrites the entire file to move the moov atom to the head of the file, without it a player cannot even know what is in the file unless it has read the end of the file which is only possible when either the server supports seeking or the entire file has been downloaded.

All that said, I still believe that the libavformat should have handled max bitrate calculation internally and both assuming the bit_rate field of AVCodecParameters struct may match the maximum bitrate and setting max bitrate to the average bitrate when this filed is at its default value (zero) make no sense.

Quote from: eumagga0x2a on May 21, 2021, 12:00:54 PMFor a fully correct assessment of PS3 compatibility, here is the SOURCE remuxed with the Avidemux off the current git master with FFmpeg patched to skip writing btrt atoms: https://we.tl/t-MYh9BfWook

The plot thickens, it still has the error.

I also tried with the mediafire mp4 via the ffmpeg ticket out of curiousity and it outright refused to play it with the same error.

I've uploaded three more samples in a ZIP, the names of the files are self-explanatory, please try and report back: https://we.tl/t-t9YD4iUqDJ

The samples created with ffmpeg were generated by

ffmpeg -i MP4-APRIL.mp4 -c copy output-filename.mp4
where output-filename.mp4 is a placeholder for whatever I used to describe the properties. Regarding the new sample created with Avidemux, FFmpeg in Avidemux was patched not only to skip writing the btrt atom but also to assign the last frame the same duration as the previous one instead of zero (which makes all frames the same duration).

The latest ffmpeg adds a colr (color primaries / transfer function / matrix / range info) atom to the equation.

Quote from: Anon40213 on May 22, 2021, 10:42:47 AMThe plot thickens, it still has the error.

So it is not the btrt atom *headscratch*

Error
adm-remuxed-from-april-no-btrt-no-zero-duration

Both OK
ffmpeg-v432-remuxed-from-april
latest-ffmpeg-remuxed-from-april