On 27/04/18 00:33, John Pilkington wrote: > Hi: I haven't previously posted here. > > I've been on the mythtv lists since 2005 and wrote a cutting script that I > use daily on mpeg2video SD recordings from DVB-T; it cuts with Project-X, at > keyframes. I have been trying to write a similar script using ffmpeg to cut > h264-encoded HD recordings from DVB-T2 transmissions in the UK. Internal cuts > have not been good. > > I'm using mythffmpeg version 3.4.1, as incorporated in current mythtv-master, > in Fedora 26. Results have been similar with ffmpeg 3.3.7 for x86_64 f26 > from rpmfusion. > > I use a first pass to 'ignore_unknown' streams, and a second to do the > cutting. During the second pass I have almost always had error reports of > 'illegal reordering of pic_nums_idc' or 'reference count overflow.' > > I reported that and the following details yesterday on the mythtv-devel list, > and a re-post here has been suggested. > > The error reports apparently come from libavcodec/h264_parser.c, lines 186 > and 194. The numbers in the 'if/else if' combination at lines 182/184 look > very strange to me: > > unsigned int reordering_of_pic_nums_idc = get_ue_golomb_31(gb); > > if (reordering_of_pic_nums_idc < 3) > get_ue_golomb_long(gb) > else if (reordering_of_pic_nums_idc > 3) {.... > > ..and libavcodec/golomb.h has this at line 82: > > /** > * read unsigned exp golomb code, constraint to a max of 31. > * the return value is undefined if the stored value exceeds 31. > */ > static inline int get_ue_golomb_31(GetBitContext *gb) > {.... > > ***I think that the '3' in the 'else if' line in the parser should probably > be 31. ***
No. This is parsing a reference picture list modification block - see H.264 <https://www.itu.int/rec/T-REC-H.264-201704-I/en>, section 7.3.3.1. Valid meaningful values are 0-2, and 3 ends the list. Any other value is invalid. > I have patched my copy accordingly. I have seen no bad effects, most of the > error messages have gone, and the internal cuts are much neater. > > It would be great if someone would look to see if this and/or other patches > are appropriate. IIUC mythtv won't patch the ffmpeg code that it uses. > > I have more test results available if required. Can you share a short sample showing your problem? - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel