May 12

I’ll read and review soon a new python book from Packt: Mastering Object Oriented Python.

So far I just read the introduction, the book so far seems nice and I might leverage it while writing my python implementation of kramdown (since there isn’t anything even close to it).

May 12

I just committed the ebuild in Portage and noticed that Homebrew already updated its Formula.

I spent some time in Berlin at LinuxTAG manning the VideoLAN booth and feeding people with VLC and Libav chocolate (many thanks to Borgodoro for providing me with their fine goods).

During the weekend we held the VideoLAN association meeting in the SoundCloud office, thanks a lot again for the wonderful venue.

Unmask in Gentoo

I’m slowly getting a tinderbox up with the help of Flameeyes so we can make sure nothing unexpected happens, the new refcounted API for Frames and Packets makes quite compelling updating from 9 even if we’ll keep updating both release branches for the next year and half.

You can help

There are a number of packets that depend on old 0.8 ffmpeg application and it won’t really work with the current avconv nor with the ffmpeg provided by the recent versions since the new option parsing code written by Anton ended up there as well. Most of those application are either fully orphaned or they have patches to work with avconv because the Debian and Ubuntu developers took care of it. Nikoli provided me with a list.

HWAccel 1.2

This week-end I eventually merged hwaccel1.2 and I hope to get the AVResample updates finalized by this week.

There had been some discussion regarding backporting the latter to release 10 since they simplify a bit porting to the new resampling library.

Rotation reporting API

Vittorio was working on a mean to export the rotation matrix from MOV and SEI NALs since a while. The devil is usually in the details and I guess it had been an hell of fun for him. Even more since he switched continent meanwhile.

After the Linus rant about not having the automagic support for rotation, we had some decent pressure applied to get it out so people will be able to enjoy it. Hopefully it will appear by the week end as well.

May 03

We are preparing a new set of releases with more bugfixes (some eventually fixed thanks to ubsan).

Libav 0.8

With the release of Libav 10 the 0.8 is nominally out of the maintainance window, but we’ll try to get a last update (or few more) to ease the transition, volunteers willing to add a section in the migration guides would be welcome.

Libav 9

The Plain Nine serie is actively maintained and being the last one not sporting reference-counted AVFrames, I warmly suggest to consider migrating to Libav 10.
The new release is expected to appear tomorrow, stay tuned!

Libav 10

Soon we’ll provide the first point release, we are discussing if we should backport the simplified avresample API, I’m working on since it should make much easier the life of people used to the old audio decoding API and expecting interleaved PCM as output.

Future

This weekend everybody had been also busy hammering and linting the native Opus codec Anton wrote and while at it I spent some time on finding and fixing few annoying bugs in vp9.

Libav 11 is shaping up nicely and hopefully soon I’ll get back working on libavformat (MXF, segmented formats and some more) and hopefully I’ll have a preview branch for AVScale next month, as stated this release will be source-compatible with Libav 10, Anton is already busy preparing the API cleanse for Libav 12 later this winter, but you’ll be warned by the time this release is out.

This week I’ll in Berlin for the LinuxTAG, if you have questions I’ll be happy to answer, you’ll find me either at the Gentoo or the VLC booth.

Apr 10

Everybody should remember than a 100% secure device is the one unplugged and put in a safe covered in concrete. There is always a trade-off on the impairment we inflict ourselves in order to stay safe.

Antonio Lioy

In the wake of the heartbleed bug. I’d like to return again on what we have to track problems and how they could improve.

The tools of the trade

Memory checkers

I wrote in many places regarding memory checkers, they are usually a boon and they catch a good deal of issues once coupled with good samples. I managed to fix a good number of issues in hevc just by using gcc-asan and running the normal tests and for vp9 took not much time to spot a couple of issues as well (the memory checkers aren’t perfect so they didn’t spot the faulty memcpy I introduced to simplify a loop).

If you maintain some software please do use valgrind, asan (now also available on gcc) and, if you are on windows, drmemory. They help you catch bugs early. Just beware that sometimes certain versions of clang-asan miscompile. Never blindly trust the tools.

Static analyzers

The static analyzers are a mixed bag, sometimes they spot glaring mistakes sometimes they just point at impossible conditions.
Please do not put asserts to make them happy, if they are right you just traded a faulty memory access for a deny of service.

Other checkers

There are plenty other good tools from the *san family one can use, ubsan is maybe the newest available in gcc and it does help. Valgrind has plenty as well and the upcoming drmemory has a good deal of interesting perks, if only upstream hadn’t been so particular with release process and build systems you’d have it in Gentoo since last year…

Regression tests

I guess everybody is getting sick of me talking about fuzzy testing or why I spent weeks to have a fast regression test archive called playground for Libav and I’m sure everybody in Gentoo is missing the tinderbox runs Diego used to run.
Having a good and comprehensive batch of checks to make sure new code and new fixes do not have the uncalled side effect of breaking stuff is nice, coupled with git bisect makes backporting to fix issues in release branches much easier.

Debuggers

We have gdb, that works quite well, and we have lldb that should improve a lot. And many extensions on top of them. When they fail we can always rely on printf, or not

What’s missing

Speed

If security is just an acceptable impairment over performance in order not to crash, using the tools mentioned are an acceptable slow down on the development process in order not to spend much more time later tracking those issues.

The teams behind valgrind and *san are doing their best to just make the execution three-four times as slow when the code is instrumented.

The static analyzers are usually just 5 times as slow as a normal compiler run.

A serial regression test run could take ages and in parallel could make your system not able to do anything else.

Any speed up there is a boon. Bigger hardware and automation mitigates the problem.

Precision

While gdb is already good in getting you information out of gcc-compiled data apparently clang-compiled binaries are a bit harder. Using lldb is a subtle form of masochism right now for many reasons, it getting confused is just the icing of a cake of annoyance.

Integration

So far is a fair fight between valgrind and *san on which integrates better with the debuggers. I started using asan mostly because made introspecting memory as simple as calling a function from gdb. Valgrind has a richer interface but is a pain to use.

Reporting

Some tools are better than other in pointing out the issues. Clang is so far the best with gcc-4.9 coming closer. Most static analyzers are trying their best to deliver the big picture and the detail. gdb so far is incredibly better compared to lldb, but there are already some details in lldb output that gdb should copy.

Thanks

I’m closing this post thanking everybody involved in creating those useful, yet perfectible tools, all the people actually using them and reporting bugs back and everybody actually fixing the mentioned bugs so I don’t have to do myself alone =)

Everything is broken, but we are fixing most of it together.

Apr 04

In the past month or so I started helping Vittorio on adding one of the important missing feature to our h264 decoder. Multi View support.

MVC

The basic idea of this feature is quite simple, you are shooting a movie with multiple angles, something is bound to be sort of common and you’d like to ensure frame precision.

So what about encoding all the simultaneous frames captured in the same elementary stream, share across the different layers as much as you could and then let the decoder output the frames somehow?

Since we know that all the containers have problems might be not completely a bogus idea to have the codec taking care of it. Even better if the resulting aggregated bitstream is more compact than the sum of the single ones.

High level structure

What’s different in h264-mvc than the normal h264?

Random bystander

Not a lot, in fact the main layer is exactly the same and a normal decoder can just skip over the additional bits (3 NALs more or less) and just decode as usual.

Basically there is a NAL unit to signal which layer we are currently working on, a NAL to store the SPS specific per layer and a NAL to keep the actual frame data.

Beside that everything is exactly the same.

Implementation

So why it isn’t already available, you made it look easy?!

Random jb

Sadly it would be easy if the decoder we have isn’t _that_ convoluted with many components entangled in a monolithic entity, with code that grew over the years to adapt to different needs.

Architectural pain points

Per slice multithreaded decoding made the code quite hard to follow since you then have a master context, h that in certain functions is actually h0 and a slice specific copy hx that sometimes becomes h and such.

Per frame multhtreaded decoding luckily doesn’t get in the way too much for now.

Having to touch a large file of about 4k lines of code in itself isn’t _so_ nice, split view as you like for editing, you end up waiting a single core of you cpu doing the work.

Community constraints

The h264-mvc is a fringe feature for many and if you care about speed you want to not have all the cruft around slowing down. What’s is for you a feature, for many is just cruft.

  • MVC support must be completely optional or not slow down the normal decoding at all.
  • MVC support must not make the code harder to follow than it is now, so hacking your way is not an option.
  • MVC should give me a pony, purple

The plan

First take the low hanging fruits while you think what’s the best route to achieve your goal.

Random wise person

Refactor

The first step is always refactor and cleanup. As you, hopefully, do not cook on a dirty kitchen, people shouldn’t
write code on top of crufty one.

Split the monster

In Libav everything compiles quite fast beside for vc1(vc1dec.c is 6k loc) and h264(h264.c was around 6k loc).
New codecs such as vp9 or hevc landed already split in smaller chunks.

Shuffling the code should be simple enough, so we had h264.c split in h264_slice.c, h264_mb.c and such. That helps having shorter (re)build time and makes you easier to focus.

Untangle it

Vittorio tried to remove the dependency over the mpeg12 context in order to make easier to follow the code, it was one of the pending issues since years. Now h264 doesn’t require mpeg12 in order to build, that will make probably happier our friends working on Chrome and everybody else needing to have _just_ few selected features in their build.

Pave the road

Once you divided the problem in smaller sub problems (parsing the new nals, store the information in an appropriate data structure, do the actual decoding and store the results somewhere accessible) you can start working on adapting the code to fit. That means reordering some code, splitting functions that would be shared and maybe slay some bugs hidden in the code weed while at it.

So far

We are halfway!

Random optimist

Done

We got the frame splitting, nal parsing pretty much in working shape and is not sent for review just because in itself is not
useful.

Doing

The frame data decoding is pending some patches from me that try to simplify the slice header parsing so enough of it could be shared w/out adding more branches. I hacked it once and I know the approach used works.

The code to store multiple views in a single frame has a whole blueprint being evaluated.

To Do

Test the actual decoding and hopefully make so the frame reference code behaves as expected, this will be probably the most annoying and time consuming task if we are unlucky. That code bites.

Mar 24

New release

After several months spent finalizing, we are now pleased to announce the release of Libav 10.

One of the main features of this release is the addition of reference-counted data buffers to Libav and their use in various structures. Specifically, the data buffers used by AVPacket and AVFrame can now be reference counted, which should allow to significantly simplify many use cases. In addition, reference-counted AVFrames> can now be used in libavfilter, avoiding the need for a separate libavfilter-specific frame structure. Frames can now be passed straight from the decoders into filters or from filters to encoders.

These additions made it necessary to bump the major versions of libavcodec, libavformat, libavdevice, libavfilter, and libavutil, which was accompanied by dropping some old deprecated APIs. These libraries are thus not ABI- or API- compatible with the previous release. All the other libraries (libavresample and libswscale) remain ABI- and API-compatible.

Another major point is the inclusion of the HEVC (AKA H.265, the successor of H.264) decoder in the main codebase. It was started in 2012 as a Libav Google Summer of Code project by Guillaume Martres and subsequently completed with the assistance of the OpenHEVC project and several Libav developers.

As usual, this release also contains support for other new formats, many smaller new features and countless bug fixes. We can highlight a native VP9 decoder, with encoding provided through libvpx, native decoders for WebP, JPEG 2000, and AIC, as well as improved WavPack support with encoding through libwavpack, support for more AAC flavors (LD – low delay, ELD – enhanced low delay), slice multithreading in libavfilter, or muxing chapters in ASF. Furthermore a few new filters have been introduced, namely compand, to change audio dynamics, framepack, to create stereoscopic videos, asetpts, to set audio pts, and interlace, to convert progressive video to interlaced. Finally there is more fine-grained detection of host and target libc, which should allow better portability to various cross compilation scenarios.

See the Changelog file for a fuller list of significant changes.

You can download the new release, as usual, from our download page.

Release 10 took a lot of time to get out, mostly due the fact we spent lots of time to help downstream to adapt to the new API and we tried our best to provide patches to most of the projects we were aware of.

Now we are settled to have migration guides so the next API breaking releases won’t require that much effort.

Thanks

I want to thank everybody in the Libav team for spending that much time on the annoying, depressing and unrewarding task of coping with the release process, fixing fringe bugs, bake patches for projects not really used and help cleaning up the documentation.

Special thanks also go to the people from VideoLan and mpv since they helped us a lot in many different ways (testing, giving feedback on the new APIs and also provide patches) and to the Google security team that provided me on short notice a large batch of samples for HEVC and VP9 that I used to validate the new decoders.

Future releases

Release process update

This is the plan for the next 4 releases (spanning more or less from spring till winter), it is the result of all the feedback regarding our release process and requests.

Enough people, mostly mpv, vlc and other downstreams tracking us by git commit, would like to have quicker major releases. The API changes
introduced are mostly caused by us trying to satisfy their needs after all.

On the other hand, a good amount of people, distribution managers/packagers and the people tending to orphaned packages used but not really developed further, have quite a problem keeping up with the changes if the API gets incompatible too often.

In order to help them we already opened a dedicated section to our bugzilla and started writing migration guides, but they would really like not having to patch old packages that often anyway.

Trying to satisfy those two, apparently conflicting, requirements that’s what we aim for:

  • Every odd major releases should not break the API, must happen quickly once enough features are available and just augment the API. ABI breaks still possible, thus the version bumps.
  • Major releases removing old APIs, thus normally source incompatible with downstream not tracking git, should happen at most once per season
    or twice per year.
  • All the API changes will get an entry in the migration guide when it is committed.
  • We do remain committed to backport security-impacting bugfixes through a window of API-breaking releases, thus not leaving in the cold who couldn’t or didn’t update often enough.

I hope ~8 feature improvements and ~4 api cleanups per year would make most people happy.

Next releases

Libav 11

It would just provide new features, more optimizations for the usual platforms and the new ones, support for a good number of fringe codecs, such as the elusive vp7, will be added.

As stated above no API breakages are to be expected.

Libav 12

This release will contain major changes, including possibly a new scaling library.
The wiki has a Blueprint section tracking the most prominent ones, you are welcome to discuss them with us.

What I’ll be working on

I’m personally involved in the following items:

  • Extend MXF support: The format is quite bizantine and had been extended even further over time.[libav11]
  • Hwaccel2: because the current situation is far from being easy to use.[libav11]
  • mime-type support in Input Formats: since we support as output I don’t see why we should not leverage it on input to speed-up probing formats.[libav11]
  • AVScale: a replacement to swscale, trying to be more rational and not pointlessly lose information doing all pointless intermediate conversions to YUV. Incidentally also support hardware scalers when available [libav12]
  • libmfx: Intel tried its best to give an uniform interface that spans Linux, Windows and possibly MacOSX, I have working decoders and encoders wrappers, soon also hwaccel1.2 support. [libav11]
  • MVC support: multiview support is nice to have if you want to watch your blu-ray disks. [libav11]
  • Apple VDA and VT hwaccel: Since the introduction of hwaccel1.2 supporting them properly should be easier.[libav11]

If some of them are important to you actual help or even sponsorship is welcome.

Mar 08

Recently I had to spend some time developing on MacOSX. Gentoo-Prefix sadly is getting less and less useful till we don’t make clang a first class citizen (People proposing a GSoC for it are welcome!) so I’m forced to use what’s provided by Xcode.

Clang

clang is wonderful for developing, it is arguably fast at building and the generated code isn’t that bad, beside when you are using asan and it miscompiles… (reported to the asan developers, they will have a look, gcc-asan works as expected.

The warning reporting is probably one of the feature I do miss in other compilers and that’s why I added it to cparser and I’m looking forward to move to gcc-4.9.

All in all clang developers increased the usability of the compiler and made the other projects improve as well, competition in opensource does work.

LD

The linker is again different from the usual binutils, normally you do not notice it but with the new xcode you have to face it since some projects will have problems finding symbols. Again the reporting is quite good, not stellar as clang’s but when the missing symbols are C++ it does a better job than stock binutils in telling you what’s missing from where.

lldb

The new debugger probably isn’t really ready for the prime time. gdb gets its share of complaints about some of its quirks (macros system quite minimal and python interface good but not documented as it should), but it is really effective and fast to use.

lldb not. Almost every command that in gdb is a single statement in lldb it is two, usually with a compusory option. Setting breakpoints, watchers, moving through frames; everything gets more cumbersome to use.

The reporting is a little more confusing and the error messages can be misleading. And since when you are on debug there are problems and you might be under pressure, it doesn’t help at all.

While debugging some VDA hwaccel improvements for libav I got to spend quite a bit of time tracking why a pointer gets nulled. The watchpoint set to it triggered at random times in the innards of the osx memory management and I couldn’t actually see when or how that happens. I ended up writing a dummy hwaccel accessing the same fields on linux, run it through gdb and discover the actual problem in … 10minutes, code and reboots included.

I do hope we’ll see a better interface for lldb and further improvements on gdb (and hopefully make so clang + gdb and gcc + lldb interoperate better).

Feb 16

We are working on getting some few remaining bits in the tree before we could eventually branch release/10, lots of low hanging fruits are being reaped right now. Soon we’ll get the first beta out, thus freezing the featureset. If something you need doesn’t make it don’t be afraid the release/11 will be much quicker and appear in spring.

Missing from the next beta

There are a number of speed improvement people would like to land before we open the branch and that are polished this week-end.

The results of the preliminary work Vittorio and I are doing on MVC are getting merged already since they just make the h264 decoder nicer to read.

Some less famous codecs are getting some slices of attention, even if some fringe ones requiring additional data structures might not make 10.

Missing from the actual release

Downstream updates cross-distribution

We are doing our best to track which downstream projects need an API update, help is more than welcome. Soon we’ll have a tinderbox run to check what’s the status in Gentoo, Debian has already some reports and hopefully we’ll get some feedback from our friends at OpenSuse as well.

Fuzz cleansing some pending bugs

I still have some in my list and I’m fixing them while not merging the pending patchsets deemed useful for this release. Luckily that part must be finished by the last beta and not the first one.

Documentation

We are getting more data in the wiki and our doxy is getting polished and the examples section is getting richer and more structured (eventually). By the time we hit this release all the pending work on this side will be available for consumption.

Sprint in March

I decided to postpone the first Libav sprint/meeting by one month and probably the focus will change a bit, the wiki will be updated accordingly.

Feb 04

Fosdem had been great. As Libav and VLC teams we had long meetings so I manage to attend only the nouveau presentation (and miss the Gentoo activities again =_=, sorry guys).

Here a summary of what had been discussed and the outcome.

Releases

We have the next two releases more or less planned

Libav 10 End of February

The API is almost frozen, we’ll set the branch point as soon Tim and probably Vittorio land their respective audio and interlacing patches in. We’ll get few betas out during the next 2 weeks and release the following.

I’ll take care to make sure downstreams requests regarding small features get addressed, please drop me a line.

Expect the first beta by this weekend.

Libav 11 Early summer

Due the apparently conflicting requests from downstreams, that want more major releases, and distributors, that would like have API deprecation less often, this release will have just API extension and should remainĀ  backwards compatible with 10, that means that 12, due this Autumn, will contain all the planned deprecations.

The two items I’ll be working on will be hwaccel2 and avscale. Help in form of sponsorship and code is be welcome.

The other items being worked on will be: timestamps, scalable hevc, generic data structures to support certain codec features, multi-view frames, a complete dsputil overhaul, resulting in smaller code for focused downstreams (e.g. Chrome) and much more.

Libav 12 Mid Autumn

This release will contain some deprecations, more internal overhauls to make even simpler user just portions of Libav without requiring the rest of it and further improvements on codecs and container formats.

Documentation

We have a wiki! And we are not afraid to use it!

Migration Paths

Derek pointed out we should make easier to migrate from the old API to the newer ones, we have already some unfinisched migration documents. From release 10 they should be enough to move to the next one w/out having to dig into git in order to figure out what to do.

Blueprints

New features get some spotlight and preliminary documentation as well. This make easier to follow the development process since most of the time sifting irc and the mailing list is the only way to get the whole picture.

(In)formal Specifications

We have some part of our codebase implementing not-really-documented formats, I’ll move my notes about NUT in the wiki soon and probably we’ll try to extract from the libvpx sources some slightly more human-readable document.

Help and sponsorship is more than welcome since it will be a major chore.

Sprint

Real life meeting seem quite productive so this year we’ll have some short time meetings focused on fixing some of the long standing annoyances. The first one is in 2 weeks possibly, more details about it and the following will appear soon.

Conferences

We plan to be present during other conferences around the world (a list will appear later), the next one for me will be probably the LinuxTag.

If you are an organizer and you want somebody to participate, we’ll be glad to talk about multimedia and opensource.

Chocolate

This Fosdem instead of t-shirt I brought some special chocolate.

It is also for sale now.

LIbav gets a cut on the sales so if you want to try it we’ll be grateful as well. =)

Jan 30

About 26h before Fosdem (yes, the beer event is the glorious start of the conference)!

What

I’ll be around bearing chocolate and chocolate for friends and fellow members of the communities I belong to (no beers this time, sorry guys!), hopefully we’ll find some space to discuss anything you’d like to discuss with me.

Topics

  • Libav (We should also have a room to discuss some more Libav10 and Libav11 planned releases)
  • VLC (Probably most discussions during the meeting, where Felix will stab me for not having done hwaccel2)
  • Gentoo/Sabayon (Complaints and rants welcome only during the beer event)
  • Any of my other many projects (contributions welcome btw!)
  • Anything else.

Where

There might be a room to discuss for about 1 hour about Libav10 Sunday, I’ll be around the Gentoo BoF Saturday and obviously I’ll be around attending some of the events.

See you there! (hopefully)