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? Thursday, July 16, 2015, 11:57:25 PM, you wrote: HL> There was a specific reason this was done this way. HL> You should definitely inquire with the original author of this code HL> for the reason of not using the header parser, IIRC it was broken in HL> some cases. -- Best regards, Ivan mailto:ivan.us...@nablet.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
