You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Twitter web interface does not accept files generated by the muxer. The web interface says: “Your media file could not be processed,” but does not give a detailed error.
The application built with minimp4 uses minih264 and the Fraunhofer FDK AAC for the audio part.
The problem only occurs if the mp4 has an audio track. Uploading an mp4 with one video track is accepted.
Copying the streams with FFmpeg without recoding fixes the issue. The command-line command used is ffmpeg -i out.mp4 -codec:a copy -codec:v copy fixed.mp4. Uploading fixed.mp4 is working.
When comparing the two files with the web tool https://www.onlinemp4parser.com the issue is located to the atom ESDS. The FFmpeg one is longer.
Modyfing the static int mp4e_flush_index(MP4E_mux_t *mux) function seems to fix the issue.
Here is the modified part:
ATOM_FULL(BOX_esds, 0);
if (tr->vsps.bytes > 0)
{
int dsi_bytes = tr->vsps.bytes - 2; // - two bytes size field
int dsi_size_size = od_size_of_size(dsi_bytes);
int dcd_bytes = dsi_bytes + dsi_size_size + 1 + (1 + 1 + 3 + 4 + 4);
dcd_bytes += 3; // FraKtus +3
int dcd_size_size = od_size_of_size(dcd_bytes);
int esd_bytes = dcd_bytes + dcd_size_size + 1 + 3;
esd_bytes += 9; // FraKtus, added 3 0x80 0x80 0x80 and section 6 of 6 bytes
#define WRITE_OD_LEN(size) if (size > 0x7F) do { size -= 0x7F; WRITE_1(0x00ff); } while (size > 0x7F); WRITE_1(size)
WRITE_1(3); // OD_ESD
WRITE_1(0x80); WRITE_1(0x80); WRITE_1(0x80); // FraKtus
WRITE_OD_LEN(esd_bytes);
WRITE_2(0); // ES_ID(2) // TODO - what is this?
WRITE_1(0); // flags(1)
WRITE_1(4); // OD_DCD
WRITE_1(0x80); WRITE_1(0x80); WRITE_1(0x80); // FraKtus
WRITE_OD_LEN(dcd_bytes);
if (tr->info.track_media_kind == e_audio)
{
WRITE_1(MP4_OBJECT_TYPE_AUDIO_ISO_IEC_14496_3); // OD_DCD
WRITE_1(5 << 2); // stream_type == AudioStream
} else
{
// http://xhelmboyx.tripod.com/formats/mp4-layout.txt
WRITE_1(208); // 208 = private video
WRITE_1(32 << 2); // stream_type == user private
}
WRITE_3(tr->info.u.a.channelcount * 6144/8); // bufferSizeDB in bytes, constant as in reference decoder
WRITE_4(0); // maxBitrate TODO
WRITE_4(0); // avg_bitrate_bps TODO
WRITE_1(5); // OD_DSI
WRITE_1(0x80); WRITE_1(0x80); WRITE_1(0x80); // FraKtus
WRITE_OD_LEN(dsi_bytes);
for (i = 0; i < dsi_bytes; i++)
{
WRITE_1(tr->vsps.data[2 + i]);
}
// FraKtus ->
WRITE_1(6); // ???
WRITE_1(0x80); WRITE_1(0x80); WRITE_1(0x80);
WRITE_1(1); WRITE_1(2);
// -> FraKtus
}
The modified parts have a FraKtus comment.
I do not have enough expertise to say that this should be added to master, but I hope it can fix some users' issues.
The files generated are accepted by all majors social networks (Instagram, TikTok, Twitter, YouTube...) and plays fine on macOS. FFmpeg does not complain when processing them, even at a verbose level.
Thank you for the beautiful minip4 and mnih264 projects! They allow creating fast and light applications with no dependencies.
The text was updated successfully, but these errors were encountered:
Should fix issue lieff#25 - I'm not sure where in the spec this is defined,
but I've found references that in MP4 files, the SLConfigDescriptor
is required, and needs to be set to 2, see http://gpac.sourceforge.net/tutorial/bifs_part3.htm
The Twitter web interface does not accept files generated by the muxer. The web interface says: “Your media file could not be processed,” but does not give a detailed error.
The application built with minimp4 uses minih264 and the Fraunhofer FDK AAC for the audio part.
The problem only occurs if the mp4 has an audio track. Uploading an mp4 with one video track is accepted.
Copying the streams with FFmpeg without recoding fixes the issue. The command-line command used is ffmpeg -i out.mp4 -codec:a copy -codec:v copy fixed.mp4. Uploading fixed.mp4 is working.
When comparing the two files with the web tool https://www.onlinemp4parser.com the issue is located to the atom ESDS. The FFmpeg one is longer.
This discussion, a little bit old, give some details:
https://stackoverflow.com/questions/30998150/build-an-esds-box-for-an-mp4-that-firefox-can-play
Modyfing the static int mp4e_flush_index(MP4E_mux_t *mux) function seems to fix the issue.
Here is the modified part:
The modified parts have a FraKtus comment.
I do not have enough expertise to say that this should be added to master, but I hope it can fix some users' issues.
The files generated are accepted by all majors social networks (Instagram, TikTok, Twitter, YouTube...) and plays fine on macOS. FFmpeg does not complain when processing them, even at a verbose level.
Thank you for the beautiful minip4 and mnih264 projects! They allow creating fast and light applications with no dependencies.
The text was updated successfully, but these errors were encountered: