[mythtv] FFmpeg 4.4.1 problems

[Piotr Oniszczuk]

> Wiadomość napisana przez Scott Theisen <scott.the.elm at gmail.com> w dniu 17.11.2021, o godz. 04:42:
> 
> My second try rebasing worked: https://github.com/ulmus-scott/FFmpeg/tree/rebase/4.4m
> 
> Note the following changes vs https://github.com/MythTV/FFmpeg/tree/release/4.4 :
> two more cherry-picked commits from upstream
> 
> removed duplicated entry in libavcodec/codec_desc.c
> fixed indentation in two other files
> 
> tweaked Klaas' commit message to not confuse GitHub: https://github.com/ulmus-scott/FFmpeg/commit/77526ccf1dbf62cab94f8b0522b7615a016f9314
> 
> dropped two commits and their reversions
> 
> Regards,
> Scott

Scott,

This is great work!

Now it think we may transform list of current downstream commits into reasonably defined functional commits.

Example functional commits deduced from:
https://github.com/ulmus-scott/FFmpeg/commit/bb39833100571d981302e0203feac6f53dc6ff52

_Just proposal...._

prepare FFMpeg to be internal in MythTV
add MythTV mpegs demuxer
add MHEG support 
add CC support
add VBI support
change DVD subtitles handling
fix MPEG 4playback
fix Audio parser
fix NUV playback
fix ATSC captions
fix DVD PCM playback
fix DVD PGS subtitles
.......
 
We may discuss with git commit comment facility in each hunk regarding: what & why; then after this brain learning invent best name of functional commit for hunk; then group all relevant hunks into such functional commit. 
This is boring reverse engineering - but imho rather unavoidable for upstreaming & have shared FFmpeg goals. 
  

General assumptions:

Every functional commit:
-will be set of cherry-picked chunks from multiple current commits
-prepared to apply clean and allows to build at least partially working mythtv (for testing, regressions etc)
-is responsible for atomic functionality

this will help us to:
-easier find regression root causing commit (i.e. breaking NV decode mentioned by Klaas)
-be useful in future for regression & cross-regression testing

Note:
we have current multiple commits with spread multiple hunks each and we want to sort hunks into new list of functional commits.
key for me seems to be proper definition of functional commits.

Sorting current hunks in to commits we can do i.e.:
1.generate patch per each current commit
2.sort & move relevant hunks from p.1 patches into new functional patches (getting 1st functional patch and scan all relevant hunks and put them into patch; compile; test; repeat)
3.apply functional patch on upstream ffmpeg4.4 tree
4.check: after each functional commit we should 100% the same codebase between current 4.4 downstream & 4.4 upstream with functional patches
5.commit p.4 in git if OK

maybe this sounds crazy - but afaik git not allows to selectively move parts of commits between commit1 and commit2 (as commits are atomic).

or i'm wrong here?