[mythtv] ffmpeg pull requests

Scott Theisen scott.the.elm at gmail.com
Wed Jun 1 01:22:55 UTC 2022


Peter,

You already merged all of the changes to FFmpeg from 
https://github.com/MythTV/mythtv/pull/416 (except 
https://github.com/MythTV/mythtv/pull/416/commits/5c6288f52f6c6b3e07992bae6c9ba80e051fbb78 
and 
https://github.com/MythTV/mythtv/pull/416/commits/a51d4e8b67cfa5dc54744c7339527c2c79d14455) 
to https://github.com/MythTV/FFmpeg/commits/master back in February.

However, I have slightly re-worked some of the changes to make them more 
coherent and grouped together, instead of mixing it all together as I 
went.  The end results should be the same, however.

On 5/31/22 09:41, Peter Bennett wrote:
> Please can you let me know which ffmpeg pull requests are ready to go. 

https://github.com/MythTV/mythtv/pull/557 ByteReader (replace 
avpriv_find_start_code) the change to FFmpeg is in a separate commit and 
not strictly necessary for that PR (although it does silence many 
warnings when compiling FFmpeg).  This PR needs to be merged before I 
can submit my BitReader PR to replace the use of get_bits.h and golomb.h 
in MythTV (shared context lines in MythTV).

https://github.com/MythTV/mythtv/pull/565 lavc/utils-mythtv.c (MythTV 
changes depend on the FFmpeg changes in order to work fully.)

https://github.com/MythTV/mythtv/pull/566 libpostproc; solely changes to 
FFmpeg, identical to what you already merged. Independent of all other 
changes.

https://github.com/MythTV/mythtv/pull/568 independent MythTV change 
split from a commit that I have redone.

> Code changes need to be applied to the MythTV/FFmpeg repository first, 
> then we can copy the structure into MythTV/mythtv, ffgmpeg-resync branch. 

An alternative would be to edit the patches generated by `git 
format-patch` to remove the MythTV parts and fix the paths, `git am 
*.patch` to apply them to ffmpeg/release/4.4 and then rebase onto 
master.  (This is what I did to move the patches back and forth between 
the two repositories).

> we need to keep commits that affect ffmpeg separate from ones that 
> affect the MythTV code.

They are interdependent, so that is impossible.  Most FFmpeg changes 
depend on MythTV changes, but some MythTV changes depend on FFmpeg changes.

>
> Once they are done, we can attempt merging ffmpeg 5.
>
> Does this sound good to you? Do you have any recommendations for a 
> better way to get everything merged with the least pain?. Having the 
> MythTV/FFmpeg repository makes it easier to merge new versions, but 
> does separate out the history and makes it more difficult to track 
> down bugs, however I don't know of any better way.

The cleanup changes depend on each other (both ways), so that history 
needs to be in the MythTV repository.

I want to merge the changes to MythTV first, because of their 
interdependence, and to create a sensible history for bisection if 
necessary.  Then, I can separate out the changes to FFmpeg as described 
above (if necessary, although I know I made some different changes); 
however, I'm not sure if you want to keep the ffmpeg/master history that 
you already merged or create a new history that is one to one with the 
MythTV repository.

However, my mpegts-mythtv.c harmonization should, in my opinion, appear 
in the MythTV repository as a single monolithic change because I can't 
guarantee that it works at each commit.  It compiles at each commit and 
works at the end, but I didn't test the intermediate commits.  This 
should be separate from and before the merging of FFmpeg 5.0.

Regards,

Scott


More information about the mythtv-dev mailing list