[Matplotlib-devel] switch default to h264

[Chris Barker]

This is all a huge pain! So thanks so much Eric! Sounds like you have a
good plan.

-CHB


On Mon, Aug 15, 2016 at 11:27 AM, Eric Firing <efiring at hawaii.edu> wrote:

> It's all incredibly confusing, as the wikipedia article shows.  The first
> problem is the distinction between the container format and the codec; both
> have to be recognized and handled properly by an application.  The file
> extension generally is more indicative of the container than the codec.
>
> MPEG-4 seems to be an umbrella that can cover a wide variety actual
> codecs, one of which is h264, and that at least implies a file format
> ("version 2").
>
> Specifying the mpeg4 codec in animation, with avconv or ffmpeg, seems to
> result in the use of a codec "mpeg4 (Simple Profile)"--but I suspect this
> might depend on how avconv or ffmpeg was built.  Specifying h264 results in
> use of the newer and more efficient h264 encoder, which is what I am
> proposing to make the default.
>
> One problem: h264 (at least as implemented in ffmpeg and avconv) can't
> handle frame dimensions that include an odd number of pixels, but mpeg4
> can.  Regardless of whether h264 is the default, we should trap this error
> at an early stage; otherwise it leads to a non-obvious failure mode.
>
> I need to do a little more testing before submitting any PR.  I want to
> identify the conditions that were leading to video files that were
> completely corrupted.  When I was trying to get things working I was not
> keeping track of what I was doing, so I need to backtrack and make a set of
> examples.
>
> Eric
>
> On 2016/08/15 7:38 AM, Benjamin Root wrote:
>
>> As I stated in my book:
>>
>> "While I will not claim to possess anything more than a passing
>> familiarity with movie formats, I recognize that neither do many other
>> people. For those who have had experience editing and creating movies
>> and understand these concepts far more extensively, you can skip this
>> section; be assured that I could not possibly add any new knowledge. For
>> those reading on, there are likely to be some over-simplifications. As
>> such, this section is only intended to provide enough information to
>> successfully render animations and avoid pitfalls and should not be
>> considered authoritative."
>>
>> My quick research at the time found that while mpeg4 and h.264 weren't
>> strictly equivalent, for all intents and purposes they could be
>> considered as such. And it is my understanding that avconv and such were
>> treating it as the same (unless explicitly told not to). If I am wrong
>> in this regard, please refer to the previous paragraph and kindly file
>> an errata for my book.
>>
>> Cheers!
>> Ben Root
>>
>>
>> On Mon, Aug 15, 2016 at 1:23 PM, Chris Barker <chris.barker at noaa.gov
>> <mailto:chris.barker at noaa.gov>> wrote:
>>
>>
>>
>>     On Mon, Aug 15, 2016 at 6:21 AM, Benjamin Root <ben.v.root at gmail.com
>>     <mailto:ben.v.root at gmail.com>> wrote:
>>
>>         In my research for the animation chapter of my book, I also came
>>         to the conclusion that the `mpeg4` codec in a .mp4 container was
>>         the best bet for out-of-the-box compatibility across platforms.
>>
>>
>>         Ben -- is that H.264? It seem "mpeg 4" is not well defined. from
>>         Wikipedia:
>>
>>
>>
>>     "MPEG-4 is still an evolving standard and is divided into a number
>>     of parts. Companies promoting MPEG-4 compatibility do not always
>>     clearly state which "part" level compatibility they are referring to."
>>
>>     Sigh.
>>
>>
>>
>>          The one place where that format didn't work was MS PowerPoint
>>         on Windows (but, oddly enough, it worked on PowerPoint on MacOSX).
>>
>>
>>     That's because PPT punts to the "system" for decoding -- it has
>>     little if any built-in support. A freakin' nightmare.
>>
>>
>>         Note, I did that test a couple of years ago on a Windows 7
>>         machine, so I don't know if that limitation is still valid.
>>
>>
>>     I think H.264 is getting better and better supported.
>>
>>     Question: how is MPL planning to support it? Is there a
>>     not-too-hard-to-install cross platform lib???
>>
>>     -CHB
>>
>>
>>
>>     --
>>
>>     Christopher Barker, Ph.D.
>>     Oceanographer
>>
>>     Emergency Response Division
>>     NOAA/NOS/OR&R            (206) 526-6959 <tel:%28206%29%20526-6959>
>>     voice
>>     7600 Sand Point Way NE   (206) 526-6329 <tel:%28206%29%20526-6329>
>>  fax
>>     Seattle, WA  98115       (206) 526-6317 <tel:%28206%29%20526-6317>
>>     main reception
>>
>>     Chris.Barker at noaa.gov <mailto:Chris.Barker at noaa.gov>
>>
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160817/066934bd/attachment.html>