[FFmpeg-devel] [PATCH] ffmpeg/web/index: add news describing GSoC 2015 program outcome

Ganesh Ajjanagadde gajjanag at mit.edu
Sun Sep 27 15:44:33 CEST 2015


On Sun, Sep 27, 2015 at 8:37 AM, Stefano Sabatini <stefasab at gmail.com> wrote:
> ---
>  src/index | 234 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 234 insertions(+)
>
> diff --git a/src/index b/src/index
> index 9d12a7b..8937172 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,240 @@
>      News
>    </h1>
>
> +  <a id="gsoc2015_result"></a><h3>September 27th, 2015, GSoC 2015 results</h3>
> +
> +  <p>
> +    FFmpeg participated to the latest edition of
> +    the <a href="http://www.google-melange.com/gsoc/homepage/google/gsoc2015">Google
> +    Summer of Code</a> Project. FFmpeg got a total of 8 assigned
> +    projects, and 7 of them were successfull.
> +  </p>
> +
> +  <p>We want to thank <a href="https://www.google.com">Google</a>, the
> +    participating students, and especially the mentors who joined this
> +    effort. We're looking forward participating to the next GSoC
> +    edition!
> +  </p>
> +
> +  <p>
> +    Below you can find a brief description of the final outcome of
> +    each single project.
> +  </p>
> +
> +  <h4>Basic servers for network protocols, mentee: klaxa, mentor: Nicolas George</h4>

any reason real name of the mentee is not used here but is used in the
body para?

> +
> +  <p>
> +    Stephan Holljes's project for this session of Google Summer of Code was to
> +    implement basic HTTP server features for libavformat, to complement the
> +    already present HTTP client and RTMP and RTSP server code.
> +  </p>
> +
> +  <p>
> +    The first part of the project was to make the HTTP code capable of accepting
> +    a single client; it was completed partly during the qualification period and
> +    partly during the first week of the summer. Thanks to this work, it is now
> +    possible to make a simple HTTP stream using the following commands:
> +    <pre>
> +      ffmpeg -i /dev/video0 -listen 1 -f matroska \
> +      -c:v libx264 -preset fast -tune zerolatency http://:8080
> +      ffplay http://localhost:8080/
> +    </pre>
> +  </p>
> +
> +  <p>
> +    The next part of the project was to extend the code to be able to accept
> +    several clients, simultaneously or consecutively. Since libavformat did not
> +    have an API for that kind of task, it was necessary to design on. This part
> +    was mostly completed before the midterm and applied shortly afterwards.
> +    Since the ffmpeg command-line tool is not ready to serve several clients,
> +    the test ground for that new API is an example program serving hard-coded
> +    content.
> +  </p>

design on -> design one

> +
> +  <p>
> +    The last and most ambitious part of the project was to update ffserver to
> +    make use of the new API. It would prove that the API is usable to implement
> +    real HTTP servers, and expose the points where more control was needed. By
> +    the end of the summer, a first working patch series was undergoing code
> +    review.
> +  </p>
> +
> +  <h4>Browsing content on the server, mentee: Mariusz SzczepaƄczyk, mentor: Lukasz Marek</h4>
> +
> +  <p>
> +    Mariusz finished an API prepared by FFmpeg community and implemented
> +    Samba directory listing as qualification task.

nit: by FFmpeg community -> by the FFmpeg community

> +  </p>
> +
> +  <p>
> +    During the program he extended the API with possibility to remove and
> +    rename files on remote servers. He implemented/finished the
> +    implementation of these features for file, Samba, SFTP, and FTP
> +    protocols.
> +  </p>

nit: with possiblity -> with the possibility

implemented/finished: is the vagueness necessary because some of these
were completed and others not? Otherwise, I prefer the more explicit
"implemented and finished".

> +
> +  <p>
> +    At the end of the program, Mariusz provided a sketch of implementation
> +    for HTTP directory listening.
> +  </p>
> +
> +  <h4>Directshow digital video capture, mentee: Mate Sebok, mentor: Roger Pack</h4>
> +
> +  <p>
> +    Mate was working on directshow input from digital video sources. He
> +    got working input from ATSC input sources, with specifiable tuner.
> +  </p>
> +
> +  <p>
> +    The code has not been committed, but a patch of it was sent to the
> +    ffmpeg-devel mailing list for future use.
> +  </p>
> +
> +  <p>
> +    The mentor plans on cleaning it up and committing up, at least for the
> +    ATSC side of things. Mate and the mentor are still working trying to
> +    finally figure out how to get DVB working.
> +  </p>

committing up - never heard this usage, perhaps "committing it" or
even a simple "committing"?

> +
> +  <h4>Implementing full support for 3GPP Timed Text Subtitles, mentee: Niklesh Lalwani, mentors: Philip Langdale</h4>
> +
> +  <p>
> +    Niklesh's project was to expand our support for 3GPP Timed Text
> +    subtitles. This is the native subtitle format for mp4 containers, and
> +    is interesting because it's usually the only subtitle format supported
> +    by the stock playback applications on iOS and Android devices.
> +  </p>
> +
> +  <p>
> +    ffmpeg already had basic support for these subtitles which ignored all
> +    formatting information - it just provided basic plain-text support.
> +  </p>
> +
> +  <p>
> +    Niklesh did work to add support on both the encode and decode side for
> +    text formatting capabilities, such as font size/colour and effects like
> +    bold/italics, highlighting, etc.
> +  </p>
> +
> +  <p>
> +    The main challenge here is that Timed Text handles formatting in a very
> +    different way from most common subtitle formats. It uses a binary
> +    encoding (based on mp4 boxes, naturally) and stores information
> +    separately from the text itself. This requires additional work to track
> +    which parts of the text formatting applies to, and explicitly dealing
> +    with overlapping formatting (which other formats support) but Timed
> +    Text does not - so it requires breaking the overlapping sections into
> +    separate non-overlapping ones with different formatting.
> +  </p>
> +
> +  <p>
> +    Finally, Niklesh had to be careful about not trusting any size
> +    information in the subtitles - and that's no joke: the now infamous
> +    Android stagefright bug was in code for parsing Timed Text subtitles.
> +  </p>
> +
> +  <p>
> +    All of Niklesh's work is committed and was released in ffmpeg 2.8.
> +  </p>
> +
> +<h4>libswscale refactoring, mentee: Pedro Arthur, mentors: Michael Niedermayer, Ramiro Polla</h4>
> +
> +  <p>
> +    Pedro Arthur has modlularized the vertical and horizontal scalers.
> +    To do this he designed and implemented a generic filter framework
> +    and moved the existing scaler code into it. These changes now allow
> +    easily adding removing, splitting or merging processing steps.
> +    The implementation was benchmarked and several alternatives where
> +    tried to avoid speedloss.
> +  </p>

modl.. -> modularized
where tried -> were tried

> +
> +  <p>
> +    He also added gamma correct scaling support.
> +    An example to use gamma corrected scaling would be:
> +    <pre>
> +      ffmpeg -i input -vf scale=512:384:gamma=1 output
> +    </pre>
> +  </p>

gamma correct scaling -> gamma corrected scaling

> +
> +  <p>
> +    Pedro has done impressive work considering the short time available,
> +    and he is a FFmpeg comitter now. He continues to contribute to
> +    FFmpeg, and has fixed some bugs in libswscale after GSoC has
> +    ended.
> +  </p>

comitter -> committer

> +
> +  <h4>AAC Encoder Improvements, mentee: Rostislav Pehlivanov, mentor: Claudio Freire</h4>
> +
> +  <p>
> +    Rostislav Pehlivanov has implemented PNS, TNS, I/S coding and main
> +    prediction on the native AAC encoder. Of all those extensions, only
> +    TNS was left in a less-than-usable state, but the implementation has
> +    been pushed (disabled) anyway since it's a good basis for further
> +    improvements.
> +  </p>
> +
> +  <p>
> +    PNS replaces noisy bands with a single scalefactor representing the
> +    energy of that band, gaining in coding efficiency considerably, and
> +    the quality improvements on low bitrates are impressive for such a
> +    simple feature.
> +  </p>
> +
> +  <p>
> +    TNS still needs some polishing, but has the potential to reduce coding
> +    artifacts by applying noise shaping in the temporal domain (something
> +    that is a source of annoying, notable distortion on low-entropy
> +    bands).
> +  </p>
> +
> +  <p>
> +    Intensity Stereo coding (I/S) can double coding efficiency by
> +    exploiting strong correlation between stereo channels, most effective
> +    on pop-style tracks that employ panned mixing. The technique is not as
> +    effective on classic X-Y recordings though.
> +  </p>
> +
> +  <p>
> +    Finally, main prediction improves coding efficiency by exploiting
> +    correlation among successive frames. While the gains have not been
> +    huge at this point, Rostislav has remained active even after the GSoC,
> +    and is polishing both TNS and main prediction, as well as looking for
> +    furhter improvements to make.
> +  </p>

furhter -> further

> +
> +  <p>
> +    In the process, the MIPS port of the encoder was broken a few times,
> +    something he's also working to fix.
> +  </p>
> +
> +  <h4>Animated Portable Network Graphics (APNG), mentee: Donny Yang, mentor: Paul B Mahol</h4>
> +
> +  <p>
> +    Donny Yang implemented basic keyframe only APNG encoder as qualification
> +    task, later he wrote kind of interframe compression via various blend
> +    modes. Current implementation tries all blend modes and picks one which
> +    takes the smallest amount of memory.
> +  </p>

as qualification -> "as the qualification" or "as a qualification"
depending on whether the qualification task is unique.
change the , before later to a ; (or IMO a . with a fresh sentence)
wrote kind of -> vague, ambiguous between "kind of wrote" and "wrote a
type of". I think you wanted a "wrote a type of".
Current implementation -> The current implementation

> +
> +  <p>
> +    Special care was taken to make sure that the decoder plays correctly
> +    all files found in wild and that the encoder produces files that can
> +    be played in browsers that support APNG.
> +  </p>

found in wild -> found in the wild

> +
> +  <p>
> +    During his work he was tasked to fix any encountered bug in the
> +    decoder due to the fact that it doesn't match APNG
> +    specifications. Thanks to this work, the also long standing bug in the
> +    PNG decoder has been fixed.
> +  </p>

Maybe reference the trac ticket number?
the also long standing bug -> "a long standing bug" is simpler and
conveys the same thing

> +
> +  <p>
> +    For latter work he plans to continue working on the encoder, making
> +    possible to select which blend modes will be used in the encoding
> +    process, which could speed up encoding of APNG files.
> +  </p>

making possible -> making it possible
remove the ,  add a . and say "This could speed up encoding of APNG files."

> +
>    <a id="pr2.8"></a><h3>September 9th, 2015, FFmpeg 2.8</h3>
>    <p>
>      We published release <b><a href="download.html#release_2.8">2.8</a></b> as new major version.
> --
> 1.9.1

Please note that James beat me to a review and some stuff may be redundant.

>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


More information about the ffmpeg-devel mailing list