Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Suggested-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: runtime error: left shift of 1876744317 by 16 places cannot be represented in type 'int'
Fixes: 6799/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5115274731716608

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Marton Balint <cus@passwd.hu>

The seek functions use first_timestamp, so keep that up to date as
old segments drop off the playlist.
Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Jun Zhao <mypopydev@gmail.com>

Rename the nal_unit_name to hevc_nal_unit_name, will add a
h264_nal_unit_name function.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>

Signed-off-by: Jun Zhao <mypopydev@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

A few days ago ossfuzz stoped testing new FFmpeg as it run out of diskspacee

https://oss-fuzz-build-logs.storage.googleapis.com/index.html

An alternative would be to revert the API.

This changes for example
-rwxr-x--- 1 michael michael 144803654 May 14 12:54 tools/target_dec_ac3_fixed_fuzzer*
to
-rwxr-x--- 1 michael michael  30333852 May 14 12:51 tools/target_dec_ac3_fixed_fuzzer*

Which should massively decrease space requirements
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The change in 309d6607 to call device_init
when doing derivation missed this case - we should only call it if we
actually made a new device.

Regression since ece068a7.
Signed-off-by: Marton Balint <cus@passwd.hu>

My conversation from AVFormatContext->filename to AVFormatContext->url was
wrong in this case because get_chunk_filename uses filename as an output
buffer, and not as an input buffer.

Fixes ticket #7188.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Aman Gupta <aman@tmm1.net>

The GetBitContext is effectively empty in them.
Signed-off-by: James Almer <jamrial@gmail.com>

http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=20180513001958Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

This does require libmysofa with today's latest commit (https://github.com/hoene/libmysofa/commit/08f243d1ec35f6f794aedeb4b187d9f9353bdbc1).
They already had a pkg-config file, but the dependencies weren't setup right. Until now.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

avcodec/vp3: Check that there will be sufficient input for the coded fragments in unpack_superblocks()

Fixes: Timeout
Fixes: 6292/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4871218218926080

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

This should be included as `<lilv/lilv.h>`, same as is done in af_lv2.c.
Forcing the extra lilv-0 breaks platforms where the include dir is
`/usr/include/lilv/lilv.h` rather than
`/usr/include/lilv-0/lilv/lilv.h`.

The new include path works for both, because the `pkg-config --cflags`
includes `-I/usr/include/lilv-0`.

reported by Mindless` on IRC

Signed-off-by: Aman Gupta <aman@tmm1.net>

Fixes PMT parsing in some mpegts streams which contain
multiple tables within the PMT pid. Previously, the parser
assumed only one table was present in each packet, and discarded
the rest of the section data after attempting to parse the first
table.

A similar issue was documented in the BeyondTV software[1], which
helped me diagnose the same bug in the ffmpeg mpegts demuxer. I also
tried DVBInspector, libdvbpsi's dvbinfo, and tstools' tsinfo to
help debug. The former two properly read PMTs with multiple tables,
whereas the last has the same bug as ffmpeg.

I've created a minimal sample[2] which contains the combined PMT.
Here's what ffmpeg probe shows before and after this patch:

Before:

    Input #0, mpegts, from 'combined-pmt-tids.ts':
      Duration: 00:00:01.08, start: 4932.966167, bitrate: 741 kb/s
      Program 1
      No Program
        Stream #0:0[0xf9d]: Audio: ac3, 48000 Hz, mono, fltp, 96 kb/s
        Stream #0:1[0xf9b]: Audio: mp3, 0 channels, fltp
        Stream #0:2[0xf9c]: Unknown: none

After:

    Input #0, mpegts, from 'combined-pmt-tids.ts':
      Duration: 00:00:01.11, start: 4932.966167, bitrate: 718 kb/s
      Program 1
        Stream #0:0[0xf9b]: Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv, top first), 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
        Stream #0:1[0xf9c](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
        Stream #0:2[0xf9d](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, mono, fltp, 96 kb/s

With the patch, the PMT is parsed correctly so the streams are
created in the correct order, are associated with "Program 1",
and their codecs are set correctly.

[1] http://forums.snapstream.com/vb/showpost.php?p=343816&postcount=201
[2] https://s3.amazonaws.com/tmm1/combined-pmt-tids.tsSigned-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Same as previous commit but for mpegts inside HLS.
Signed-off-by: Aman Gupta <aman@tmm1.net>

This allows remuxing streams from one mpegts container to another,
without requiring avformat_find_stream_info() (or using `ffmpeg
-probesize 32` on the cli).
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

SMPTE 386M (D-10) lists 4 as value to be used
SMPTE 377-1-2009 says
    "The definitions of 00h (coSiting) and 04h (Rec 601) are equivalent. The value of 04h is deprecated. New
     MXF encoders shall use the value of 00h instead."
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>