In reality, I need a video that is cross-platform. Android, for
example, doesn't like *.mov videos, using the default Samsung Video
Player on Samsung Galaxy S series.
This is why *please please please* allow people to encode videos, that
work everywhere, and document the process.
Everywhere (for me) is defined as: Samsung Galaxy S3 - to S7 (Android
4+), Chromebook (preferably), iPhone (4S)+, iPad 2+ (Apple iOS),
MacBook (Mac OS X), Windows 7+ (10), and Debian Linux. (Windows XP
also needed, and it works with 3rd party codecs).
And I want it to work out-of-the-box using stock media player and
stock codecs, if possible.
The best candidate for such a video would be H.264/MPEG-4-AVC
(High-Profile) codec in MP4 container and with 2-channel AAC-LC audio
(and using yuv420p colorspace and limited timebase and up to Full HD
1080p and up to 30 fps and ... well too many "ands").
I require a good quality Full HD 1080p videos and 2-channel stereo sound.
I never realized that the problem is so difficult with videos, while
MP3 audio and JPEG (and PNG) images work great everywhere,
out-of-the-box, for videos the problem is so hard to crack.
And closing bugs without resolution doesn't help my use-case either.
Maybe we need some kind of input parameter that will check lots of
stuff to produce compatible videos, specifically check for timebase
(limit 100k), fps (limit up to 30 framerate), colorspace (limit to
yuv420p only), audio (limit 2-channel and AAC-LC or MP3 audio), and
limited bitrate (maybe level 5.0?).
What I really need is some kind of a "limited" MP4 profile, that works
Maybe a good solution to my problem is to introduce a new flag to
ffmpeg encoder like "-compatible" which will enforce all those limits
upon encoded video, but guarantee that things will work in all popular
On Wed, Oct 12, 2016 at 5:04 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2016-10-12 16:03 GMT+02:00 Thomas Worth <d...@rarevision.com>:
>> On Wed, Oct 12, 2016 at 2:50 AM, Carl Eugen Hoyos <ceffm...@gmail.com>
>>> 2016-10-12 9:31 GMT+02:00 Thomas Worth <d...@rarevision.com>:
>>> > Has anyone actually looked at the MP4 file, BrokenVideo-8min.mp4?
>> Just look at mdhd and you'll see what I'm talking about.
> This is the second comment today that could be misinterpreted:
> Please remember that not everybody is a native speaker and
> be more careful.
> Allow me a question:
> Did you test with any non-QT based player?
> If your analysis were right, nothing could play the sample, so I
> believe it is safe to say that your analysis cannot be correct.
>> Upon closer inspection, there is definitely a problem. The
>> 10000000 you are referring to is in the wrong place in the
>> video track's mdhd atom. mdhd should be 32 bytes,
>> according to the Apple specification for QuickTime, which
>> the MP4 file format is based upon.
> You are of course right that isom is based on mov but you
> are missing two (important) things:
> There is a difference between mov and isom.
> Alexey told us that he needs QT compatibility but he told
> FFmpeg that he absolutely doesn't care about QT, he
> requested an isom file (and that's why FFmpeg did not try
> to create a QT-compatible file and did not warn that the file
> is not QT-compatible).
>> The mdhd in Alexey's file is 44 bytes. mdhd should look
>> like this:
>>  //size
>>  //'mdhd'
>>  //version
>>  //flags
>>  //creation time
>>  //modification time
>>  //time scale
>>  //duration
> The mdhd atom in the file is version 1 and has 64bit time and
> duration fields and is therefore twelve bytes larger than a
> version 0 mdhd atom.
> Thank you for finally solving the question why QT fails!
> Carl Eugen
> ffmpeg-user mailing list
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
-Alexey Eromenko "Technologov"
ffmpeg-user mailing list
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".