Arrays should generally be deleted with delete[]. Also, this operator's behaviour (as well as the normal delete's) is well defined on null pointers (it's a no-op), so the if is totally needless.
The m_nalBuffer member was incremented in the loop while copying, which naturally led to the pointer being invalid when the destructor is executed in order to delete the array. The code was replaced with an equivalent std::copy call.
Also, replaced the invalid delete with delete[].
Fixes#395.
Bintray builds have been created every night since the 5th of December. Not only
is this caused by a runaway "0" at the end of the line responsible for updating
the commit.txt file (oh, those long lines!), but Bintray has been returning the
200 OK code when attempting an update of the file despite also returning an
error and the file not actually being updated :
{"message":"Version 'latest' has been published for more than 365 days. Files can only be uploaded to a version within 365 days from its publish date."}
Hopefully, creating a version in the "commit" package with the same version as
the nightlies will solve this problem.
H264 standard states "log2_max_mv_length_horizontal and log2_max_mv_length_vertical indicate the maximum absolute value of a decoded horizontal and vertical motion vector component, respectively, in ¼ luma sample units, for all pictures in the coded video sequence. [ ] The value of log2_max_mv_length_horizontal shall be in the range of 0 to 15, inclusive. The value of log2_max_mv_length_vertical shall be in the range of 0 to 15, inclusive".
However some hardware decoders seem to produce log2_max_mv_length with values of 16.
* CMake tweaks to make the project more linux packager friendly
- Add install target for tsMuxerGUI
- Add install for contributed desktop file
- Install icon for desktop file
- Don't check for C when all sources are C++.
Long overdue fixes to the warnings in file_unix.cpp. Also, move the POSIX-exclusive fcntl.h include from file.h to file_unix.cpp and remove MSVC warning suppression related to exception specifications, which were also removed as they have been deprecated since C++11.
* When parsing a stream other than AVC with the AVC deserializer, allow early return and avoid false AVC detection.
* Solve signed/unsigned mismatch in comparisons
Previous versions used the "last output directory" when opening the "Browse"
dialog in the main window, using the current "File name" only if the "last
output directory " is not yet defined. This change reverses this, which means
that the folder of the path currently entered as the "File name" will be used
as the folder to display. The file name will be carried over to the dialog.
Fixes#372 .
Pointers to widgets can be simply compared directly against the pointers in the
UI struct, which is admittedly less fragile than relying on object names for the
same purpose.
Commit #351 corrects the Mediainfo "8 compatible" to "Blu-ray compatible", however the Blu-ray players (eg Sony x700) do not detect anymore Dolby Vision after the change:
see https://forum.doom9.net/showthread.php?p=1924124#post1924124
So this patch reverts DV version to previous v1 -we have to live with the Mediainfo "8 compatible" until we can have more info on the v2 descriptor structure and players compatibility.
m_processedMessages is never used in a context where the ordering of the elements matter, so it makes it a perfect candidate for converting to std::unordered_set.
With the H264 option 'Insert SEI and VUI data if absent' or 'Always rebuild SEI and VUI data':
In case timing SEIs are not found, all SEIs (timing and non timing) are currently removed nd replaced with timing SEIs.
This patch corrects this: only the timing SEIs are removed, the non-timing SEIs (such as private date e.g. x264 decoding parameters) are kept.
See https://forum.doom9.net/showthread.php?p=1924053#post1924053 : from the ffmpeg and mediainfo codes, the Dolby spec version 1 seems to be incorrect: the compatibility id should be before the dependency_pid, and this has been corrected in version 2.
As per Dolby whitebook, VUI parameters in the stream are compulsory for profiles 5, 8.1 and 8.4 but are optional for the other profiles.
Detection of profiles is re-written to account for the cases where there VUI parameters are unspecified.
In case coded field is detected (i.e. the picture is composed of a top field and a bottom field), the incrementation of the poc (coded picture order count) must be done every two frames.
However the detection of the coded filed in tsMuxer is wrong:
frame_mbs_only_flag = 1 means that the picture is coded frame.
frame_mbs_only_flag = 0 means that the picture can be either coded frame (m_field_pic_flag = 0) or coded field (m_field_pic_flag = 1).
This patch corrects the bug, and solves issue #306 .
updateTracksComboBox() was called after the indices are updated, but before the
row being removed is actually removed from the trackLV structure. This caused
the new generated track descriptions to refer to invalid tracks.
Indices in both combo boxes must be updated, since an audio track index might
have changed when a subtitle track is removed and vice versa : there is only one
array which holds information about tracks that these combo boxes reference via
the data contained in their items' UserRoles.
tsMuxer currently sets back the DTS (Decoding Time Stamp) during the muxing if the frame depth (i.e. difference between encoded picture number and decoded picture number) is found >1.
This is wrong: the frame depth should be checked -and the DTS set back- before the muxing commences.
This commits solves this.
Dan Bryant