av_read_frame_flush is deprecated and the wrapper call to
ff_read_frame_flush has been removed.
Since I don't understand the use of av_read_frame_flush in CDVDDemuxFFmpeg::Flush() it's quite hard to come up with a proposal for an alternative solution. My solution during the "quick 'n dirty" port was to create a temporary wrapper but how shall we solve this in the long term?
Old wrapper in libavformat/utils.c that has been removed:
Code:
void av_read_frame_flush(AVFormatContext *s)
{
ff_read_frame_flush(s);
}
reference to
av_read_frame_flush from CDVDDemuxFFmpeg::Flush():
Code:
void CDVDDemuxFFmpeg::Flush()
{
g_demuxer.set(this);
// naughty usage of an internal ffmpeg function
if (m_pFormatContext)
m_dllAvFormat.av_read_frame_flush(m_pFormatContext);
m_iCurrentPts = DVD_NOPTS_VALUE;
}
Where do you see that ff_read_frame_flush has been deprecated? I can't find anything about it either in the source or in the APIChanges doc.
With what I've gathered it should be a safe bet to change the import/wrapper in DllAvFormat to ff_av_read_frame_flush and go with that.
In the current code, look in the patches folder. Patch 0024 exposes internal function ff_read_frame_flush by creating a av_read_frame_flush wrapper.
Remember in your post about how to do a PR? The dev said you need to pull those patches into the bump or the PR will be rejected.
(2013-02-18, 00:33)bobb0 Wrote: [ -> ]In the current code, look in the patches folder. Patch 0024 exposes internal function ff_read_frame_flush by creating a av_read_frame_flush wrapper.
Remember in your post about how to do a PR? The dev said you need to pull those patches into the bump or the PR will be rejected.
Yeah, I found it! It's hard to tell if patch 0024 is from the ffmpeg-repo or is our own. If it came from the ffmpeg-repo I presume someone reverted it. If it is one of our own, it certainly confuses me since I read in a post that we don't create and applies own patches direct on ffmpeg
Regarding the other patches, they look like they came from the ffmpeg-repo which means they "should" be included in the current ffmpeg version. Do you know if anyone kept track of the patches from the ffmpeg-repo so we can find out which patches that are already included or not in the current ffmpeg release? Otherwise I don't know how we can solve this situation, any suggestions?
--
Regards, Lars
everything in lib/ffmpeg/patches are XBMC's patches to ffmpeg. They are all applied and in use.
'git log lib/ffmpeg/patches' will show how they come in.
Makes sense since custom patches would make it hard to support external libs, but I downloaded the 0.10.6 package (closest to the 0.10.2 package in Frodo) and didn't find any patches directory in it, so I assume that all patches are xbmc specific.
you guys can listen to me anytime now
Can't hear ya ...
I try a clarification aswell (maybe together they will be able to understand
).
All patches in the patches folder are applied in our code base (they are already applied and only there for tracking history!). They are applied on top of the latest ffmpeg version we pulled (0.10.2 atm afaik). Either those patches are ours - or they are backports from ffmpegs upstream. Normally you can have a look into that patchfile itself to see if its a backport or not (we normally leave the original commit message and the committer in there). Also what davilla said "'git log lib/ffmpeg/patches" shows you the history where the patch file came from.
I hope its clear now.
Whenever you have to patch the ffmpeg source you apply the patch and then add the git diff to the patches folder in the next commit (if its a backport - adapt the patch so that it clearly states that it is a change from upstream and which commit in ffmpeg repo it is).
For example the
Code:
0012-include-stdint.h.patch
still seems to be valid, because I couldn't find
in "your"
file
Just to avoid duplication of effort, I have already ported patches 0001 through 0012 to ffmpeg 1.1.2...
(2013-02-18, 12:40)Memphiz Wrote: [ -> ]Can't hear ya ...
I try a clarification aswell (maybe together they will be able to understand 
).
All patches in the patches folder are applied in our code base (they are already applied and only there for tracking history!). They are applied on top of the latest ffmpeg version we pulled (0.10.2 atm afaik). Either those patches are ours - or they are backports from ffmpegs upstream. Normally you can have a look into that patchfile itself to see if its a backport or not (we normally leave the original commit message and the committer in there). Also what davilla said "'git log lib/ffmpeg/patches" shows you the history where the patch file came from.
I hope its clear now.
Whenever you have to patch the ffmpeg source you apply the patch and then add the git diff to the patches folder in the next commit (if its a backport - adapt the patch so that it clearly states that it is a change from upstream and which commit in ffmpeg repo it is).
Hello folks, sorry about the late answer but I'm dealing with XMBC "after work" (without the beer
)) .
To start with, it does always make sense to clarify things in contrast to one-line orders that lacks background infomation.
Anyhow, thanks for the comprehensive answer! It explains a lot in a clear way, especially the way of working with patches in the past. I'll put the info in a README file in the patches directory.
Basically I'm not particular found of the idea to implement "locally produced" patches in a library like FFmpeg that has high volume of changes, simply because a custom built library is really hard to maintain in the long run (believe me, I have been there!)
But I'll look into it to see if (and how) we can implement the old patches though it seems that some are actually already included in the FFmpeg 1.1.x main branch
. But for the future I suggest we try to find out a better way of working, like for example submit new patches through ffmpeg.org. As usually, all feedback is welcome.
--
Regards, Lars.
(2013-02-18, 15:00)vicbitter Wrote: [ -> ]Just to avoid duplication of effort, I have already ported patches 0001 through 0012 to ffmpeg 1.1.2...
Greeaat work! You are most welcome to push those changes to
https://github.com/FlyingRat/xbmc-ffmpeg-v1.1-bump ! Btw, did you make any notes on which patches that were included the ffmpeg master branch so we can put that info to a README in the patch directory for future use? /Lars.
I have ported all of the XBMC specific patches... The only patches still required are 0001 to 0024, 0026, 0029 and 0035. All of the other patches are now upstream.
I now need to build and do some testing after which I'll provide the updated patches for others to test...
(2013-02-18, 21:09)flyingrat Wrote: [ -> ]Basically I'm not particular found of the idea to implement "locally produced" patches in a library like FFmpeg that has high volume of changes, simply because a custom built library is really hard to maintain in the long run (believe me, I have been there!)
Neither are we but the alternative is some patches would never be accepted upstream and they do fix real problems. So we are left with a) fix the problem or b) ignore it.
