mozilla / nestegg Goto Github PK

The current handling of BlockDuration, DiscardPadding, and BlockAdditions in nestegg_read_packet assume that the elements appear in a specific order and position, i.e. (BlockDuration, DiscardPadding, BlockAdditions). This is not required by the WebM format (and Matroska format), as the only element ordering requirements appear to be those specified in http://matroska.org/technical/order/index.html.

Each of the reader functions for these elements is called in the above mentioned order from nestegg_read_packet, and work by peeking at the next element in the stream for the expected element, and reading it if present or failing if not.

If nestegg encountered a file with a different ordering to that currently expected, e.g. (DiscardPadding, BlockDuration), it would fail to read either element.

The parsing for each of these elements need to be removed from nestegg_read_packet and moved into the core parsing loop, where arbitrary element orderings can be handled.

Would it be possible to add a function to return the DefaultDuration value for a track, so one can e.g. get the framerate for a constant-framerate video stream without having to read in frames and take timestamp differences?

I've got a patch that adds this functionality as nestegg_track_default_duration() at: http://achurch.org/patch-pile/nestegg/git-f462231/default-duration.diff

Hi all,

I would like to test my alpha video webm file,
whoch application supports it? I tried to use chrome, and to set chrome vp8 alpha flags , but Its missing, is it supported?

Thanks!

trying to use an installed version of nestegg does not work,
nestegg/nestegg.h inclues "_stdint.h" which is not installed.

Recently the WebM format was extended by alpha support and I'm wondering if libnestegg already supports parsing alphachannel.

It was implemented by using BlockAdditional:
http://wiki.webmproject.org/alpha-channel

Here are the relevant source changes:

• libvpx issue: http://code.google.com/p/webm/issues/detail?id=135
• libvpx encoder commit: http://git.chromium.org/gitweb/?p=webm/webm-tools.git;a=blob;f=alpha_encoder/alpha_encoder.cc;h=3cb425b982362f0b4d9d911f2f07e9c7d441c5d1;hb=32bea5b47377d59e31b81457f758801132d74c0c
• chromium issue: http://code.google.com/p/chromium/issues/detail?id=242357
• chromium commit: https://chromiumcodereview.appspot.com/13886011
• sample webm file: http://updates.html5rocks.com/2013/07/Alpha-transparency-in-Chrome-video
• sample libvpx decoder with alpha support: http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/vpx_video_decoder.cc (not using libnestegg)

Since chromium is not using libnestegg I'm not sure if nestegg is already supporting parsing BlockAdditional content and if its able to detect presence of the alpha channel (new flag).

Also important might be:
AlphaMode = 0x53C0

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libvpx/source/libvpx/libmkv/EbmlIDs.h

The libvpx project did not provide a decoder sample with alpha support so I'm a bit stuck figuring out how to read alpha data with libnestegg. (Their previous decoder samples are based on libnestegg: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libvpx/source/libvpx/vpxdec.c)

It would be helpful to get a comment if this a currently supported feature or if something needs to be done to support it.

Thanks

We need to add a small redistributable sample file to test/media, add the test to test/regress.test, and generate the new output.

Ideally that'd also include updating the test output to include the result of nestegg_packet_offsets.

CC @fallaciousreasoning

I am working on a project that is using the vpx library to play webm content. I was testing the library's ability to deal with truncated files. I got some strange results. I started with a 1.8M file. Truncating it to 38394 bytes 'works', as in the file plays normally until it runs out of data. Truncating it to 38395 bytes causes nestegg_init to fail (so I end up getting no video at all) while truncating it to 39396 bytes also 'works'. Here is what I'm seeing with debugging messages turned on:

Opening file: /tmp/test1.webm
0x7ff9b4114520 debug: ctx 0x7ff9b4114520
0x7ff9b4114520 debug: single master element 1a45dfa3 (ID_EBML)
0x7ff9b4114520 debug: -> using data 0x7ff9b4114550 (48)
0x7ff9b4114520 debug: element 4286 (ID_EBML_VERSION) -> 0x7ff9b4114550 (0)
0x7ff9b4114520 debug: element 42f7 (ID_EBML_READ_VERSION) -> 0x7ff9b4114568 (24)
0x7ff9b4114520 debug: element 42f2 (ID_EBML_MAX_ID_LENGTH) -> 0x7ff9b4114580 (48)
0x7ff9b4114520 debug: element 42f3 (ID_EBML_MAX_SIZE_LENGTH) -> 0x7ff9b4114598 (72)
0x7ff9b4114520 debug: element 4282 (ID_DOCTYPE) -> 0x7ff9b41145b0 (96)
0x7ff9b4114520 debug: element 4287 (ID_DOCTYPE_VERSION) -> 0x7ff9b41145c8 (120)
0x7ff9b4114520 debug: element 4285 (ID_DOCTYPE_READ_VERSION) -> 0x7ff9b41145e0 (144)
0x7ff9b4114520 debug: parent element 18538067
nestegg_init status was: -1

I started looking at the code, but that is way over my head. Is there anything that can be done to more gracefully handle these files?

I'm on 64-bit debian linux, tried with tags 1.0.0 and 1.1.0. I'm hesitant to include a test file because it is encrypted, and I don't know if I can disclose the encryption key...

thanks

_set_allocator checks if realloc acts like free when passed in 0 for the second argument (falling back to a wrapper if not), but if the allocator is set via nestegg_set_halloc_func then there is no such check. In Firefox, we started using nestegg_set_halloc_func, but our realloc does not free, so we were leaking for a few months.

It would be good if there was at least an assert when you try to register a non-freeing realloc.

The easiest way to implement this check, just using the passed-in realloc, would leak on failure, but that's probably okay, because you are only going to run it once.

I hacked up a bit of an implementation of this, but it isn't great, because you really want to use a non-leaking check for the standard _set_allocator: https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1055322&attachment=8474872

nestegg_track_audio_params() returns params->rate == 0 on big endian machines for Webm.

Noticed this in Firefox, but this also happens with a master-checkout of nestegg and make && make check:

=========================================
   libnestegg 0.1git: ./test-suite.log
=========================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test/regress
==================

--- ./test/media/detodos.webm.ok    2019-08-19 15:42:07.776490667 +0200
+++ /tmp/tmp.smhiBL2lWA 2019-08-19 17:26:50.942396884 +0200
@@ -1,7 +1,7 @@
 1 2920000608 20832 1
 1 3 1 0
 7ee6872f42345d2f717a88b33668ff11cc6d0a25 19
-48000.000000 1 16 6500000 80000000
+0.000000 1 16 6500000 80000000
 0 1 0 8 0 8362763d1961389c12879b7e2f3b27c9ba1b42cf 37 [...]
FAIL test/regress.test (exit status: 1)

As discussed with @tysmith.

Some documentation here: https://github.com/google/oss-fuzz/tree/master/docs

When trying to build outside the source tree, nestegg/nestegg-stdint.h can't be found and compilation fails:

In file included from ../nestegg/src/nestegg.c:12:
../nestegg/include/nestegg/nestegg.h:11:10: fatal error: 'nestegg/nestegg-stdint.h' file not found
#include <nestegg/nestegg-stdint.h>

Steps to reproduce:

1. git clone https://github.com/kinetiknz/nestegg.git
2. (cd nestegg && autoreconf --install)
3. (mkdir build && cd build && ../nestegg/configure)
4. (cd build && make)

I see the following clang warnings when compiling Firefox with Xcode 8.3's clang version:

media/libnestegg/src/nestegg.c:1077:8 [-Wsometimes-uninitialized] variable 'r' is used uninitialized whenever switch case is taken
media/libnestegg/src/nestegg.c:1078:8 [-Wsometimes-uninitialized] variable 'r' is used uninitialized whenever switch case is taken

If nestegg library is built with MSVC, the audio rate returned by nestegg_track_audio_params is reported as "0". I believe it's down to commit #65: the __FLOAT_WORD_ORDER__ macro is not defined in MSVC.