Also make sure we set a valid track index sid and a valid track edit rate in
order for the index to be useful.
Signed-off-by: Marton Balint <cus@passwd.hu>
da9cc22d5b allowed the MOV muxer to relay a custom stream handler name,
whether populated from the input stream or user-set. However, the entry
key didn't match the key set by the MOV demuxer, so it wasn't
effective. Fixed.
Due to the change, four FATE refs have to be updated. Verified that the
target payload of the tests hasn't changed in terms of CRC.
In 9152c1e495, the mpegts parser was taught how to parse
PMT sections which contained multiple tables. That commit
fixed parsing of PMT packets from some cable providers,
which included a special SCTE table (0xc0) before the
standard program map table (0x2).
Sometimes, however, the combined 0xc0 and 0x2 tables are
larger than a single TS packet (188 bytes). The mpegts parser
already attempts to parse sections which span multiple packets,
but still assumed that the split section only contained one
table.
This patch fixes parsing of such a sample[1].
Before:
Input #0, mpegts, from 'combined-pmt-tids-split.ts':
Duration: 00:00:01.26, start: 39188.931756, bitrate: 597 kb/s
Program 1
No Program
Stream #0:0[0xeff]: Audio: ac3, 48000 Hz, mono, fltp, 64 kb/s
Stream #0:1[0xefd]: Audio: mp3, 0 channels, fltp
Stream #0:2[0xefe]: Unknown: none
After:
Input #0, mpegts, from 'combined-pmt-tids-split.ts':
Duration: 00:00:01.27, start: 39188.931756, bitrate: 589 kb/s
Program 1
Stream #0:0[0xefd]: Video: h264 ([27][0][0][0] / 0x001B), none, 59.94 fps, 59.94 tbr, 90k tbn, 180k tbc
Stream #0:1[0xefe](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 384 kb/s
Stream #0:2[0xeff](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, mono, fltp, 64 kb/s
Stream #0:3[0xf00]: Data: scte_35
Stream #0:4[0xf01]: Unknown: none (ETV1 / 0x31565445)
Stream #0:5[0xf02]: Unknown: none (ETV1 / 0x31565445)
Stream #0:6[0xf03]: Unknown: none ([192][0][0][0] / 0x00C0)
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] https://s3.amazonaws.com/tmm1/combined-pmt-tids-split.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For chapter images, the mov demux produces streams with disposition set
to attached_pic+timed_thumbnails. This patch fixes to properly recognize
streams that should be encoded as cover image (ones with only and only
attached_pic disposition set).
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Find codec tag for attached images using appropriate list of
supported image formats.
This fixes writing the cover image to m4v/m4a and other container
formats that do not allow these codecs as a track.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found by Chrome's ClusterFuzz: http://crbug.com/849062.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A generic lavf flag for AAC LATM packetization for the RTP muxer was
added in ef409645f0 and then made inert 20 days later in 0832122880
when a private muxer option was added and the generic flag no longer
read.
This validates that the common encryption saio/saiz atoms only appear
when the data is actually encrypted. This also ignores those atoms
in clear content.
Found by Chrome's ClusterFuzz: http://crbug.com/850389
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If start_time is not set, ffmpeg takes the duration from the global
movie instead of the per stream duration.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We already do this for audio, but it should be done for video too.
If we don't, seeking back to the start of the file, for example, can
become quite broken, since the first N packets will have repeating
and nonmonotonic PTS, yet they need to be decoded even if they are
to be discarded.
Signed-off-by: Sasi Inguva <isasi@isasi.mtv.corp.google.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Found by Chrome's ClusterFuzz: https://crbug.com/847060
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The producer reference time box supplies relative wall-clock times
at which movie fragments, or files containing movie fragments
(such as segments) were produced.
The box is mainly useful in live streaming use cases. A media player
can parse the box and utilize the time fields to measure and improve
the latency during real time playout.
This utility function creates 64-bit NTP time format as per the RFC
5905.
A simple explaination of 64-bit NTP time format is here
http://www.beaglesoft.com/Manual/page53.htm
Yet another case of forgotten 0 =! EOF translation.
While the documentation for this specific synchronous read
function does not mention it, the documentation for
`sftp_async_read` documents it, as well as looking at the
implementation of this function leads one to find
`if (handle->eof) { return 0; }`.
Reported by stnutt on IRC.
Applicable only to webm output format.
By default all the segment filenames end with .m4s extension.
When someone chooses webm output format, we recommend they also override the relevant segment name options to end with .webm extension. This patch will issue a warning for he same
Right now segment file format is chosen to be either mp4 or webm based on the codec format.
This patch makes that choice configurable by the user, instead of being decided by the muxer.
Also with this change per-stream choice segment file format(based on codec type) is not possible.
All the output audio and video streams should be in the same file format.
Both stream_id and stream_identifier are used in this file,
and have different meanings. The latter comes from the
stream_identifier_descriptor.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Without this some operations might overflow (undefined behavior)
even though the index adding loop would never execute
No testcase known
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This massively reduces the detection of random data as low score mp3
It may improve security by making it harder to read non multimedia data
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This new optional flag makes it easier to deal with mpegts
samples where the PMT is updated and elementary streams move
to different PIDs in the middle of playback.
Previously, new AVStreams were created per PID, and it was up
to the user to figure out which streams had migrated to a new PID
(by iterating over the list of AVProgram and making guesses), and
switch seamlessly to the new AVStream during playback.
Transcoding or remuxing these streams with ffmpeg on the CLI was
also quite painful, and the user would need to extract each set
of PIDs into a separate file and then stitch them back together.
With this new option, the mpegts demuxer will automatically detect
PMT changes and feed data from the new PID to the original AVStream
that was created for the orignal PID. For mpegts samples with
stream_identifier_descriptor available, the unique ID is used to
merge PIDs together. If the stream id is not available, the demuxer
attempts to map PIDs based on their position within the PMT.
With this change, I am able to playback and transcode/remux these
two samples which previously caused issues:
https://tmm1.s3.amazonaws.com/pmt-version-change.tshttps://kuroko.fushizen.eu/videos/pid_switch_sample.ts
I also have another longer sample in which the PMT changes
repeatedly and ES streams move to different pids three times
during playback:
https://tmm1.s3.amazonaws.com/multiple-pmt-change.ts
Demuxing this sample with the new option shows several new log
messages as the PMT changes are handled:
[mpegts] detected PMT change (program=1, version=3/6, pcr_pid=0xf98/0xfb7)
[mpegts] re-using existing video stream 0 (pid=0xf98) for new pid=0xfb7
[mpegts] re-using existing audio stream 1 (pid=0xf99) for new pid=0xfb8
[mpegts] re-using existing audio stream 2 (pid=0xf9a) for new pid=0xfb9
[mpegts] detected PMT change (program=1, version=6/3, pcr_pid=0xfb7/0xf98)
[mpegts] detected PMT change (program=1, version=3/4, pcr_pid=0xf98/0xf9b)
[mpegts] re-using existing video stream 0 (pid=0xf98) for new pid=0xf9b
[mpegts] re-using existing audio stream 1 (pid=0xf99) for new pid=0xf9c
[mpegts] re-using existing audio stream 2 (pid=0xf9a) for new pid=0xf9d
[mpegts] detected PMT change (program=1, version=4/5, pcr_pid=0xf9b/0xfa9)
[mpegts] re-using existing video stream 0 (pid=0xf98) for new pid=0xfa9
[mpegts] re-using existing audio stream 1 (pid=0xf99) for new pid=0xfaa
[mpegts] re-using existing audio stream 2 (pid=0xf9a) for new pid=0xfab
[mpegts] detected PMT change (program=1, version=5/6, pcr_pid=0xfa9/0xfb7)
Signed-off-by: Aman Gupta <aman@tmm1.net>
With these fields, the user has enough information to
detect PMT changes and switch to new streams when the PMT
is updated with new ES pids.
To do so, the user would monitor the AVProgram they're interested
in for changes to pmt_version. If the version changes, they would
iterate over the program's streams to find new streams added with
the updated version number.
If new versions of streams are found, then the user would first try
to replace existing streams where stream_identifier matched.
If stream_identifier is not available, then the user would compare
pmt_stream_idx instead to replace the stream that was previously
at the same position within the PMT.
Signed-off-by: Aman Gupta <aman@tmm1.net>
These fields will allow the mpegts demuxer to expose details about
the PMT/program which created the AVProgram and its AVStreams.
In mpegts, a PMT which advertises streams has a version number
which can be incremented at any time. When the version changes,
the pids which correspond to each of it's streams can also change.
Since ffmpeg creates a new AVStream per pid by default, an API user
needs the ability to (a) detect when the PMT changed, and (b) tell
which AVStream were added to replace earlier streams.
This has been a long-standing issue with ffmpeg's handling of mpegts
streams with PMT changes, and I found two related patches in the wild
that attempt to solve the same problem:
The first is in MythTV's ffmpeg fork, where they added a
void (*streams_changed)(void*); to AVFormatContext and call it from
their fork of the mpegts demuxer whenever the PMT changes.
The second was proposed by XBMC in
https://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135036.html,
where they created a new AVMEDIA_TYPE_DATA stream with id=0 and
attempted to send packets to it whenever the PMT changed.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Some filtered mpegts streams may erroneously include PMTs for
programs that are not advertised in the PAT. This confuses ffmpeg
and most players because multiple audio/video streams are created
and it is unclear which ones actually contain data.
See for example https://tmm1.s3.amazonaws.com/unknown-pmts.ts
In this sample, the PAT advertises exactly one program. But the
pid it points to for the program's PMT contains PMTs for other
programs as well. This is because the broadcaster decided to
re-use the same pid for multiple program PMTs.
The hardware that filtered the original multi-program stream
into a single-program stream did so by rewriting the PAT to
contain only the program that was requested. But since it just
passed through the PMT pid referenced in the PAT, multiple PMTs
are still present for the other programs.
Before:
Input #0, mpegts, from 'unknown-pmts.ts':
Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s
Program 4
Stream #0:2[0x41]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
Stream #0:3[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:4[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 128 kb/s
No Program
Stream #0:0[0x31]: Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv), 90k tbr, 90k tbn, 90k tbc
Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp
Stream #0:5[0x51]: Video: mpeg2video ([2][0][0][0] / 0x0002), none, 90k tbr, 90k tbn
Stream #0:6[0x54](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels
With skip_unknown_pmt=1:
Input #0, mpegts, from 'unknown-pmts.ts':
Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s
Program 4
Stream #0:0[0x41]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
Stream #0:1[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 128 kb/s
Signed-off-by: Aman Gupta <aman@tmm1.net>
Parses the video_stream_descriptor (H.222 2.6.2) to look
for the still_picture_flag. This is exposed to the user
via a new AV_DISPOSITION_STILL_IMAGE.
See for example https://tmm1.s3.amazonaws.com/music-choice.ts,
whose video stream only updates every ~6 seconds.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For seekable mpegts streams, duration is calculated from
pts by seeking to the end of the file for a pts and subtracting
the initial pts to compute a duration.
This can be expensive in terms of added latency during
probe, especially when streaming over a network. This new
option lets you skip the duration calculation, which is useful
when you don't care about the value and want to save some overhead.
This patch is particularly useful when dealing with live mpegts
streams. Normally such streams are not seekable, so durations
are not calculated. However in my case I am dealing with a seekable
live mpegts stream (networked access to a .ts file which is still
being appended to).
Signed-off-by: Aman Gupta <aman@tmm1.net>
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>
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.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
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>
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This mimics the logic flow in all the other callbacks
(pat_cb, sdt_cb, m4sl_cb), and avoids calling skip_identical()
for non PMT_TID packets.
Since skip_identical modifies internal state like
MpegTSSectionFilter.last_ver, this change prevents unnecessary
reprocessing on some streams which contain multiple tables in
the PMT pid. This can be observed with streams from certain US
cable providers, which include both tid=0x2 and another unspecified
tid=0xc0.
Signed-off-by: Aman Gupta <aman@tmm1.net>
This can "demux" .vpy files. Autodetection of .vpy scripts is
intentionally not done, because it would be a major security issue. You
need to force the format, for example with "-f vapoursynth" for the
FFmpeg CLI tools.
Some minor code copied from other LGPL parts of FFmpeg.
I did not find a good way to test a few of the more obscure VS features,
like VFR nodes, compat pixel formats, or nodes with dynamic size/format
changes. These can be easily implemented on demand.
This code will print a warning if any user agent is set - even if the
API user used the proper non-deprecated "user_agent" option.
This change should not even break anything, because even if the user
sets the deprecated "user-agent" option, http.c copies it to the
"user_agent" option anyway.
If the API user doesn't set avg_frame_rate, matroskaenc will write the
current timebase as "default duration" for the video track. This makes
no sense, because the "default duration" implies the framerate of the
video. Since the timebase is forced to 1/1000, this will make the
resulting file claim 1000fps.
Drop it and don't write the element. It's optional, so it's better not
to write it if the framerate is unknown.
Strangely does not require FATE changes.
Enables one to test possibly nonstandard formats such as Opus or
FLAC in ISOBMFF, among other things.
This becomes much more useful if output segment format becomes an
option, or if the WebM segment feature gets removed.
It has not ever been working and has not been validated,
Additionally, mention that the segment file names should be changed
to end with webm instead of m4s, which is utilized for ISOBMFF
fragments.
The specs says that the the first color component in the color array is
not alpha, but simply 0.
Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov
Signed-off-by: Marton Balint <cus@passwd.hu>
1. an audio component with an ISO_639_language_descriptor in the PMT with the
audio_type field set to 0x03
2. a supplementary_audio_descriptor with the editorial_classification field set
to 0x01
3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a component_type field
with the service_type flags set to Visually Impaired
Tested-by: Łukasz Krzciuk <lkrzciuk@vewd.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The track's media duration from the mdhd atom takes precedence
over both the stts and elst atom for calculating and setting
the track's total duraion.
Technically, we shouldn't be using the stts atom at all for
calculating stream durations.
This fixes incorrect stream and final packet durations on files
with edit lists that are longer than the media duration.
The FATE changes are expected, and output is more correct (the
AAC frame is not 1028 samples).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The av_rc4_crypt() documentation allows src == dst.
Silences the following warning:
libavformat/rtmpcrypt.c:304:36: warning: passing argument 2 of 'av_rc4_crypt' discards 'const' qualifier from pointer target type
Reported-by: Reino Wijnsma
There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in DASH.
Hence in this muxer we will focus on supporting VP9 in MP4
Have verified playout support of VP9+MP4 in Chrome and Firefox.
Should be useful for muxers that require values as defined in the
vpcc atom but don't need to write the atom itself.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes a warning:
libavformat/dashdec.c:1900:65: warning: argument to 'sizeof' in 'memcpy' call is the same pointer type 'struct fragment *' as the destination; expected 'struct fragment' or an explicit length
This doesn't support saio atoms with more than one offset.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Similar to 4c9c4fe8b2, but for durations. This fixes#7151, where
the report duration and bitrate on a mpegts stream is wildly off
due to the dvb_teletext stream's timings.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In write only mode, the TCP receive buffer's data keeps growing with
http response messages and the buffer eventually becomes full.
This results in zero tcp window size, which in turn causes unwanted
issues, like, terminated tcp connection. The issue is apparent when
http persistent connection is enabled in hls/dash live streaming use
cases. To overcome this issue, the logic here reads the buffer data
when a file transfer is completed, so that any accumulated data in
the recieve buffer gets flushed out.
reference hls support fmp4 file from draft-pantos-http-live-streaming-20
the spec describes version 7 of hls protocol
Suggested-by: Ronak <ronak2121@yahoo.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This refactors get_cookies to simplify some code paths, specifically for
skipping logic in the while loop or exiting it. It also simplifies the logic
for appending additional values to *cookies by replacing strlen/malloc/snprintf
with one call av_asnprintf.
This refactor fixes a bug where the cookie_params AVDictionary would get leaked
if we failed to allocate a new buffer for writing to *cookies.
- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.
This doesn't support:
- Different sample descriptor holding different encryption info.
- Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes https://trac.ffmpeg.org/ticket/2798
This makes movenc handle AV_DISPOSITION_ATTACHED_PIC and write
the associated pictures in iTunes cover atom. This corresponds
to how 'mov' demuxer parses and exposes the cover images when
reading.
Most of the existing track handling loops properly ignore
these 'virtual streams' as MOVTrack->entry is never incremented
for them. However, additional tests are added as needed to ignore
them.
Tested to produce valid output with:
ffmpeg -i movie.mp4 -i thumb.jpg -disposition✌️1 attached_pic \
-map 0 -map 1 -c copy movie-with-cover.mp4
The cover image is also copied correctly with:
ffmpeg -i movie-with-cover.mp4 -map 0 -c copy out.mp4
AtomicParseley says that the attached_pic stream is properly
not visible in the main tracks of the file.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
The logic is applicable only when use_template is enabled and use_timeline
is disabled. The logic monitors the flow of segment indexes. If a streams's
segment index value is not at the expected real time position, then
the logic corrects that index value.
Typically this logic is needed in live streaming use cases. The network
bandwidth fluctuations are common during long run streaming. Each
fluctuation can cause the segment indexes fall behind the expected real
time position. Without this logic, players will not be able to consume
the content, even after encoder's network condition comes back to
normal state.
availability time of Nth segment = availabilityStartTime + (N*segment duration) - availabilityTimeOffset.
This field helps to reduce the latency by about a segment duration in streaming mode.
@availabilityStartTime specifies the anchor for the computation of the earliest
availability time (in UTC) for any Segment in the Media Presentation.
As per this requirement, the @AvailabilityStartTime should be set to the
wallclock time at which the first frame of the first segment begins encoding.
But, it was getting set only when the first segment was completely ready. Making
the required correction in this patch. This correction is mainly needed to reduce
the latency in live streaming use cases.
Calling 'write_manifest' from 'write_header' was causing creation of
first MPD with invalid values. Ex: zero @duration param value. Also,
the manifest files (MPD or M3U8s) should be created when at-least
one media frame is ready for consumption.
When use_template is enabled and use_timeline is disabled, typically
it is required to generate the segments at the configured segment duration
rate on an average. This commit is particularly needed to handle the
segmentation when video frame rates are fractional like 29.97 or 59.94 fps.
There are use cases where average segment duration needs to be configured
and muxer is expected to maintain the average segment duration. So, using
the name 'min_seg_duration' will be misleading. So, changing the parameter
name to 'seg_duration', where it can be minimum segment duration or average
segment duration based on the use-case. The additional updates needed for
this functinality are made the sub-sequent patches of this patch series.
The HLSContext struct contains fields which duplicate the data stored in the
avio_opts field. This change removes those fields in favor of avio_opts, and
updates the code accordingly.
The original patch caused the buffer pointed to by new_cookies in open_url to be
leaked. The only thing that buffer is used for is to store the value until it
can be passed to av_dict_set. To fix the leak, v2 of the patch simply calls
av_dict_set with the AV_DICT_DONT_STRDUP_VAL flag, so that the dictionary takes
ownership of the memory instead of copying it again.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Richard Shaffer <rshaffer@tunein.com>
The rw_timeout option is currently not applied when opening media playlist,
segment, or encryption key URLs. This can cause the HLS demuxer to block
indefinitely, even when the rw_timeout option has been specified. This change
simply enables carrying over the rw_timeout option when the demuxer opens these
URLs.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Richard Shaffer <rshaffer@tunein.com>
