[FFmpeg-user] ISO mp4 Major Brand field non-compliant

[Owl Owl]

Carl,

You likely need a Chromecast to reproduce this specific event. It's
possible there is an emulator, but I have not attempted that.

Playing an mp4 created by ffmpeg on Chromecast has never worked for me.

I can confirm that changing the major type alone using the brand command
line switch did not fix this problem. Example: "-brand mp41" did not work.
While it appeared to successfully set the major brand, it still would not
play on Chromecast.


I can confirm that when using the command "MP4Box -brand mp41:0 file.mp4",
the output was also playable with Chromcast. Meaning, it doesn't matter if
we use mp41 or mp42, both are playable.


Through further investigation, it does not appear to be entirely the
major_brand/minor_brand field. Hex editing those fields to the same values
do not produce a playable video. That said, I would like to reference you
to the ISO standard:


http://l.web.umkc.edu/lizhu/teaching/2016sp.video-communication/ref/mp4.pdf


Specifically, take a look at section 4.3.1 (page 12 in that pdf):
The type ‘isom’ (ISO Base Media file) is defined in this section of this
specification, as identifying files that
conform to the first version of ISO Base Media File Format.
More specific identifiers can be used to identify precise versions of
specifications providing more detail. *This *
*brand should not be used as the major brand*; this base file format should
be derived into another
specification to be used. There is therefore no defined normal file
extension, or mime type assigned to this
brand, nor definition of the minor version when ‘isom’ is the major brand.

I have put in bold the section I believe is relevant to this part of the
conversation. Thus, why I believe ffmpeg's implementation of mp4 to be
non-compliant with the ISO standard.

Aside from that, i ran the following command to view any macro differences
between the two:
vimdiff <(MP4Box -info BigBuckBunny_2.mp4 2>&1) <(MP4Box -info
BigBuckBunny_2.orig.mp4 2>&1)

In this, there are three major differences:
1) The isom vs mp41 as mentioned above
2) A note about "Chroma format 0 - Luma bit depth 8 - chroma bit depth 8".
Probably not relevant to the playback issue
3) The version that works has a note: "File suitable for progressive
download (moov before mdat)". This seems relevant to playback and would
probably constitute a format change that would cause chromecast to work or
not. Is there a way to tell ffmpeg to use this progressive download type
when formatting the mp4 output? Is so, that might also fix this issue.

Best,

Mike


On Oct 24, 2016 05:03, "Carl Eugen Hoyos" <ceffmpeg at gmail.com> wrote:

> 2016-10-24 4:04 GMT+02:00 Owl Owl <whootandahalf at gmail.com>:
> > Folks,
> >
> > I've been attempting to stream videos that I have created with ffmpeg
> > to my chromecast using a local webserver. The process is very simple:
> >
> > 1) Encode the video with ffmpeg into an mp4 container
> > 2) Start webserver hosting that file
>
> > 3) Tell chromecast to play said video
>
> Do I understand correctly that I need a physical chromecast
> device to reproduce?
>
> > It had been failing for quite a while
>
> Do you mean it worked before?
>
> > but the "BigBuckBunny" example was working perfectly.
> > Investigating further, I discovered that there is a Major and
> > Minor brand field in the header of the mp4 and, as it turns
> > out, ffmpeg inserts "isom" as the major brand and "512" as
> > the minor.
> >
> > I discovered the following bug report from about 9 months ago:
> > https://trac.ffmpeg.org/ticket/5178?cversion=0&cnum_hist=15
> >
> > Sadly, it appears that that report has been ignored.
>
> This is not true (and I don't understand how the reason for this
> claim could be a misunderstanding).
> On the contrary, I tried my best to explain a misunderstanding
> about how FFmpeg and MP4Box work to the OP (the same
> misunderstanding that you may have, see my question below),
> the OP knew better than me though;-(
>
> > It's unclear to me reading through the comments the reason
> > for "needs_more_info" being the status.
>
> Two things were missing:
> No answer was given to the question which player fails with
> isom files made with FFmpeg. (You seem to have answered
> this.)
> It wasn't verified if changing the major type helps.
>
> > If nothing else, the fact that it's ISO non-compliant, and for no
> > good reason that I can tell, should be enough.
>
> > The MP4Box workaround command mentioned in that bug
> > tracker worked for me to correct ffmpeg's mistake.
>
> > However, the "-brand" option did not work
>
> Sorry if I misunderstand this (I am not a native speaker):
> Do you mean you used the -brand option but the output files
> were (binary) identical no matter what argument you passed?
>
> Or do you mean you tried "-brand mp41", chromecast
> still didn't play the output file but you still believe that we
> just have to change the major (and minor) type and
> playback would work?
> This seems very unlikely to me but you seem to disagree?
>
> > nor should either of those options be required to obtain a
> > playable mp4 from ffmpeg.
>
> Many players, including WMP and (some versions of) QT
> play isom files written with FFmpeg...
>
> > Steps to reproduce the problem:
> > 1) Download BigBuckBunny:
> > http://commondatastorage.googleapis.com/gtv-videos-bucket/
> sample/BigBuckBunny.mp4
>
> This is an mp42 file. FFmpeg does not support writing mp42 files.
> I suspect it is possible but not completely trivial to fix this.
>
> Please test the brand option (or use your favorite binary editor)
> and report back to verify or falsify your analysis.
>
> Then ask the chromecast people what it is that they don't like
> about the FFmpeg file / what their requirements regarding isom
> are.
>
> Carl Eugen
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".