On Fri, Jul 17, 2015 at 01:13:41AM +0300, Ivan Uskov wrote: > Hello Hendrik, > > Ok, no problem. I will ask. But in general it makes no sense. I have > got enough experience for MXF using and common transcoding developing > to see that current implementation is not good and dangerous. > > I should to say that actually I see lot minor issues and quite ugly > code pieces into QSV-related modules. > I have got big doubts that all that was "by specific reason". > > For example discussed code piece not able to handle a case when decoded > stream begins from arbitrary place, not from SPS. Decoding fails. It > is common scenario for MPEG TS decoding. > Also current code tries to handle dynamic SPS change at bad place (good > place should be into the qsvdec.c) and by bad way (no fifo flush). > My patch does not solve these issues but at least I have got clear > roadmap in mind how to get qsv decoder more reliable and usable. > It is just question of another patches.
> Should we keep this code which obvious bad? no, bad code should be replaced by good or improved to become good also maybe you want to send a patch to add yourself to the MAINTAINERs file for qsv* thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
