Mailing List Archive

On 11/22/21 1:07 PM, Klaas de Waal wrote:
>
> tl;dr Also blocking artifacts when skipping with mpv when VDPAU is used.
> Blocking artifacts with vlc when using VDPAU but also when NOT
> using VDPAU.
> Blocking artifacts with mplayer.
> Failed to create a MythTV with an unmodified FFmpeg tree.
>
> And this is the long version....
>
> I have been doing some more tests with mpv and this time with various
> options.
> The file used for testing, tweevoortwaalf-ffmpeg.ts, has been shared
> in this thread.
> Note that this file is the first 100Mbyte of a mythtv recording and it
> is representative of what is here on the local cable network, it is
> not a sequence specially crafted to test decoders.
>
> This plays OK:
> $ mpv tweevoortwaalf-ffmpeg.ts
> $ mpv -vo vdpau tweevoortwaalf-ffmpeg.ts
> $ mpv -vo=gpu tweevoortwaalf_ffmpeg.ts
> $ mpv --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
> $ mpv -vo=gpu --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
>
> This gives blocking artifacts with skipping:
> $ mpv -vo=vdpau --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
> $ mpv --vo=gpu --hwdec=vdpau-copy tweevoortwaalf_ffmpeg.ts
>
> This is the mpv version used, as present in Fedora 35.
> [klaas@modu videos]$ mpv -version
> mpv 0.34.0 Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects
>  built on UNKNOWN
> FFmpeg library versions:
>    libavutil       56.70.100
>    libavcodec      58.134.100
>    libavformat     58.76.100
>    libswscale      5.9.100
>    libavfilter     7.110.100
>    libswresample   3.9.100
> FFmpeg version: 4.4.1
>
> This plays correct but while it uses Nvidia hardware it does NOT use
> VDPAU as pointed out by Peter:
> $ ffplay -sst 0 -vcodec h264_cuvid tweevoortwaalf_ffmpeg.ts
> But interesting: playback with VLC also gives blocking artifacts!
> VLC uses VDPAU by default as shown here:
> [klaas@modu videos]$ vlc tweevoortwaalf_ffmpeg.ts
> VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2)
> [0000560ed8f70b70] main libvlc: Running vlc with the default
> interface. Use 'cvlc' to use vlc without interface.
> [00007fd348005720] gl gl: Initialized libplacebo v4.157.0 (API v157)
> libva info: VA-API version 1.13.0
> libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
> libva info: Found init function __vaDriverInit_1_12
> libva info: va_openDriver() returns 0
> [00007fd348005720] glconv_vaapi_x11 gl error: vaCreateSurfaces:
> attribute not supported
> [00007fd344077100] main video output error: video output creation failed
> [00007fd354c10f90] main decoder error: failed to create video output
> [00007fd3484ada50] gl gl: Initialized libplacebo v4.157.0 (API v157)
> [00007fd354c10f90] avcodec decoder: Using NVIDIA VDPAU Driver Shared
> Library  495.44  Fri Oct 22 06:03:50 UTC 2021 for hardware decoding
>
> Further complicating the issue is that when playing the same clip on
> another system with Intel built-in graphics, VLC also gives the
> blocking artifacts.
>
> Next test with the mplayer: also blocking artifacts when skipping for
> all tested video output options (vdpau, xv, x11, gl).
> [klaas@modu videos]$ mplayer tweevoortwaalf_ffmpeg.ts
> MPlayer SVN-r38302-11 (C) 2000-2021 MPlayer Team
> do_connect: could not connect to socket
> connect: No such file or directory
> Failed to open LIRC support. You will not be able to use your remote
> control.
>
> Playing tweevoortwaalf_ffmpeg.ts.
> libavformat version 58.76.100 (external)
> TS file format detected.
> VIDEO H264(pid=2301) AUDIO MPA(pid=2311) SUB Teletext(pid=2401)
>  PROGRAM N. 1
> FPS seems to be: 25.000000
> ==========================================================================
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> libavcodec version 58.134.100 (external)
> Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
> ==========================================================================
> Load subtitles in ./
> ==========================================================================
> Requested audio codec family [mpg123] (afm=mpg123) not available.
> Enable it at compilation.
> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
> AUDIO: 48000 Hz, 2 ch, floatle, 256.0 kbit/8.33% (ratio: 32000->384000)
> Selected audio codec: [ffmp2float] afm: ffmpeg (FFmpeg MPEG layer-1
> and layer-2 audio)
> ==========================================================================
> AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
> Starting playback...
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> VO: [vdpau] 1920x1080 => 1920x1080 Planar YV12
> A:71555.4 V:71556.4 A-V: -0.948 ct:  0.000   2/  2 ??% ??% ??,?% 0 0
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
>
>
> It looks like skipping correctly in these transport streams with H264
> 1080 interlaced is not trivial.
> However, mythfrontend has been skipping correctly for the last 15
> years up to and including the current master.
> So it should be feasible to get this working also with the latest FFmpeg.
>
> In order to start somewhere I have replaced, in a copy of the current
> master, the FFmpeg tree with the latest FFmpeg master and then hacked
> away in the MythTV code so that it could work with an (almost)
> unmodified ffmpeg tree.
> The great plan behind this is:
> - If it shows blocking behaviour then bisect the ffmpeg from the
> latest version to something that is close to what is now in master.
> This is why I want ffmpeg master because there is then a linear
> sequence of commits instead of a tree.
> - If it does NOT show blocking behaviour then add the MythTV changes
> one by one and check for blocking behaviour.
>
> However, while compilation is now OK, linking fails with unresolved
> symbols.
> These are symbols that do show up as global in the object file but
> then are local when included in the .so file.
> Example, for a file that I did add to libavcodec (that is the "almost"
> unmodified):
>
> [klaas@modu libavcodec]$ nm libmythavcodec.so | grep ff_codec_type
> 00000000006b4200 t ff_codec_type_string
> [klaas@modu libavcodec]$ nm utils-mythtv.o | grep ff_codec_type
> 0000000000000940 T ff_codec_type_string
> [klaas@modu libavcodec]$ readelf -s utils-mythtv.o | grep ff_codec_type
>    181: 0000000000000940   128 FUNC    GLOBAL DEFAULT    1
> ff_codec_type_string
> [klaas@modu libavcodec]$ readelf -s libmythavcodec.so | grep ff_codec_type
>  20731: 00000000006b4200   128 FUNC    LOCAL  DEFAULT   12
> ff_codec_type_string
>
> Note that there are more unresolved who are not from a file that I added.
> This is the complete list from linking programs/mythavtest:
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ffurl_close'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ffurl_seek'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ffurl_open'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ff_ue_golomb_vlc_code'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ffurl_write'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ffurl_read'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ff_se_golomb_vlc_code'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ff_read_frame_flush'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ff_codec_type_string'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ffurl_size'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ff_golomb_vlc_len'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference
> to `ff_codec_id_string'
> The two ff_codec_.. functions are in file avcodec/utils-mythtv.c and
> they can be moved to outside FFmpeg.
> I would have done that if it were the only unresolved symbols.
>
> This is basically where the project is currently halted....
>
> Klaas.
>
>
Those ff_ and ffurL_ functions are in FFmpeg/libavformat/url.h. They are
exposed in our version of ffmpeg by updating libavformat/libavformat.v.
You can resolve this by patching libavformat/libavformat.v.

_FFmpeg's version of __libavformat/libavformat.v_

LIBAVFORMAT_MAJOR {
    global:
        av*;
    local:
        *;
};

_Our Version of __libavformat/libavformat.v_

LIBAVFORMAT_MAJOR {
    global:
        av*;
        ffurl_read;
        ffurl_read_complete;
        ffurl_seek;
        ffurl_size;
        ffurl_protocol_next;
        ffurl_open;
        ffurl_open_whitelist;
        ffurl_close;
        ffurl_write;
        url_*;
        ff_timefilter_destroy;
        ff_timefilter_new;
        ff_timefilter_update;
        ff_timefilter_reset;
        get_*;
        put_*;
        ff_codec_get_id;
        ff_read_frame_flush;
    local:
        *;
};

Note: In the latest 4.4.1, /ffurl_open/ is no longer defined, and you
have to change the calls to /ffurl_open_whitelist/, with three extra
nullptr parameters added to the call. This change has already been made
in the devel/ffmpeg_resync branch.

Peter

On 11/22/21 1:07 PM, Klaas de Waal wrote:
> tl;dr Also blocking artifacts when skipping with mpv when VDPAU is used.
> Blocking artifacts with vlc when using VDPAU but also when NOT
> using VDPAU.
> Blocking artifacts with mplayer.

None of the other players have blocking at the beginning of
tweevoortwaalf the way that mythtv ffmpeg_resync has. Something is
different there. Also it is strange the way it plays perfectly if you
skip back to the beginning in mythtv ffmpeg_resync.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, 22 Nov 2021 at 22:05, Peter Bennett <pb.mythtv@gmail.com> wrote:

>
> On 11/22/21 1:07 PM, Klaas de Waal wrote:
> > tl;dr Also blocking artifacts when skipping with mpv when VDPAU is used.
> > Blocking artifacts with vlc when using VDPAU but also when NOT
> > using VDPAU.
> > Blocking artifacts with mplayer.
>
> None of the other players have blocking at the beginning of
> tweevoortwaalf the way that mythtv ffmpeg_resync has. Something is
> different there. Also it is strange the way it plays perfectly if you
> skip back to the beginning in mythtv ffmpeg_resync.
>
>
> Yes it is strange. I consider it correct if both the initial playback and
the skipping are OK. For the time being, fixing the other players is
definitely out of scope.....
Thanks for the ".v" file tip for the visibility configuration, this did
solve the link problem!!
The last time I did build shared libraries the visibility feature did not
even exist...
I have now a clean FFmpeg 4.3 running in a (basic/not enhanced/no CC)
MythTV master and this plays without blocks.

To be continued....

Klaas.

The cause for the blocking artifacts with VDPAU playback start and skipping
is the following commit in release 4.4 of ffmpeg:

[klaas@modu ffmpeg]$ git show 99042c2bf6
commit 99042c2bf6cc79006036502a6abbec5e51f73673
Author: James Almer <jamrial@gmail.com>
Date: Mon Mar 8 23:10:10 2021 -0300

avcodec/h264_slice: don't copy frame data during error concealment

In addition to the fact that av_image_copy() cannot handle hardware
pixel formats,
h->short_ref[0]->f may not be writable at this point.

Based on a patch by Hendrik Leppkes.

Signed-off-by: James Almer <jamrial@gmail.com>

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index fa7a639053..14b945756b 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1599,14 +1599,15 @@ static int h264_field_start(H264Context *h, const
H264SliceContext *sl,
ff_thread_await_progress(&prev->tf, INT_MAX, 0);
if (prev->field_picture)
ff_thread_await_progress(&prev->tf, INT_MAX, 1);
- av_image_copy(h->short_ref[0]->f->data,
- h->short_ref[0]->f->linesize,
- (const uint8_t **)prev->f->data,
- prev->f->linesize,
- prev->f->format,
- prev->f->width,
- prev->f->height);
+ ff_thread_release_buffer(h->avctx, &h->short_ref[0]->tf);
+ h->short_ref[0]->tf.f = h->short_ref[0]->f;
+ ret = ff_thread_ref_frame(&h->short_ref[0]->tf, &prev->tf);
+ if (ret < 0)
+ return ret;
h->short_ref[0]->poc = prev->poc + 2U;
+ ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX,
0);
+ if (h->short_ref[0]->field_picture)
+ ff_thread_report_progress(&h->short_ref[0]->tf,
INT_MAX, 1);
} else if (!h->frame_recovered && !h->avctx->hwaccel)
ff_color_frame(h->short_ref[0]->f, c);
h->short_ref[0]->frame_num = h->poc.prev_frame_num;


The attached patch reverses the above commit and can be applied to the
devel/ffmpeg-resync branch.

Klaas.

> Wiadomo?? napisana przez Klaas de Waal <klaas.de.waal@gmail.com> w dniu 24.11.2021, o godz. 21:55:
>
> The cause for the blocking artifacts with VDPAU playback start and skipping is the following commit in release 4.4 of ffmpeg:
>
> [klaas@modu ffmpeg]$ git show 99042c2bf6
> commit 99042c2bf6cc79006036502a6abbec5e51f73673
> Author: James Almer <jamrial@gmail.com>
> Date: Mon Mar 8 23:10:10 2021 -0300
>
> avcodec/h264_slice: don't copy frame data during error concealment
>
> In addition to the fact that av_image_copy() cannot handle hardware pixel formats,
> h->short_ref[0]->f may not be writable at this point.
>
> Based on a patch by Hendrik Leppkes.
>
> Signed-off-by: James Almer <jamrial@gmail.com>
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index fa7a639053..14b945756b 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1599,14 +1599,15 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl,
> ff_thread_await_progress(&prev->tf, INT_MAX, 0);
> if (prev->field_picture)
> ff_thread_await_progress(&prev->tf, INT_MAX, 1);
> - av_image_copy(h->short_ref[0]->f->data,
> - h->short_ref[0]->f->linesize,
> - (const uint8_t **)prev->f->data,
> - prev->f->linesize,
> - prev->f->format,
> - prev->f->width,
> - prev->f->height);
> + ff_thread_release_buffer(h->avctx, &h->short_ref[0]->tf);
> + h->short_ref[0]->tf.f = h->short_ref[0]->f;
> + ret = ff_thread_ref_frame(&h->short_ref[0]->tf, &prev->tf);
> + if (ret < 0)
> + return ret;
> h->short_ref[0]->poc = prev->poc + 2U;
> + ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0);
> + if (h->short_ref[0]->field_picture)
> + ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1);
> } else if (!h->frame_recovered && !h->avctx->hwaccel)
> ff_color_frame(h->short_ref[0]->f, c);
> h->short_ref[0]->frame_num = h->poc.prev_frame_num;
>
>
> The attached patch reverses the above commit and can be applied to the devel/ffmpeg-resync branch.
>
> Klaas.
>

Klaas

Fantastic work !


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/24/21 3:55 PM, Klaas de Waal wrote:
> The cause for the blocking artifacts with VDPAU playback start and
> skipping is the following commit in release 4.4 of ffmpeg:
>
> [klaas@modu ffmpeg]$ git show 99042c2bf6
> commit 99042c2bf6cc79006036502a6abbec5e51f73673
> Author: James Almer <jamrial@gmail.com <mailto:jamrial@gmail.com>>
> Date:   Mon Mar 8 23:10:10 2021 -0300
>
>     avcodec/h264_slice: don't copy frame data during error concealment
>
>     In addition to the fact that av_image_copy() cannot handle
> hardware pixel formats,
>     h->short_ref[0]->f may not be writable at this point.
>
>     Based on a patch by Hendrik Leppkes.
>
>     Signed-off-by: James Almer <jamrial@gmail.com
> <mailto:jamrial@gmail.com>>
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index fa7a639053..14b945756b 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1599,14 +1599,15 @@ static int h264_field_start(H264Context *h,
> const H264SliceContext *sl,
>                  ff_thread_await_progress(&prev->tf, INT_MAX, 0);
>                  if (prev->field_picture)
>  ff_thread_await_progress(&prev->tf, INT_MAX, 1);
> -  av_image_copy(h->short_ref[0]->f->data,
> -  h->short_ref[0]->f->linesize,
> -                              (const uint8_t **)prev->f->data,
> -                              prev->f->linesize,
> -                              prev->f->format,
> -                              prev->f->width,
> -                              prev->f->height);
> +                ff_thread_release_buffer(h->avctx, &h->short_ref[0]->tf);
> +                h->short_ref[0]->tf.f = h->short_ref[0]->f;
> +                ret = ff_thread_ref_frame(&h->short_ref[0]->tf,
> &prev->tf);
> +                if (ret < 0)
> +                    return ret;
>                  h->short_ref[0]->poc = prev->poc + 2U;
> +  ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0);
> +                if (h->short_ref[0]->field_picture)
> +  ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1);
>              } else if (!h->frame_recovered && !h->avctx->hwaccel)
>                  ff_color_frame(h->short_ref[0]->f, c);
>              h->short_ref[0]->frame_num = h->poc.prev_frame_num;
>
>
> The attached patch reverses the above commit and can be applied to the
> devel/ffmpeg-resync branch.
>
> Klaas.
>
Thank you. Great work. I plan to combine the list of commits that Scott
Theisen created, plus the pull request that he created for eliminating
unnecessary code that is no longer used, plus this, and use a new
methodology as suggested by Piotr, to take the FFmpeg code and apply our
patches on it, rather than merging the FFmpeg version with our code.

The list of our patches can be stored somewhere and updated as necessary
so that it can be applied to each new FFmpeg version. Alternatively,
once the patches have been applied to a version, they can be extracted
again using git format-patch and applied to the next version with git
am. This could also pick up any new patches that were subsequently
applied to our FFmpeg code, although hopefully these could be kept to a
minimum.

Peter

On 11/24/21 8:39 PM, Peter Bennett wrote:
>
> Thank you. Great work. I plan to combine the list of commits that
> Scott Theisen created, plus the pull request that he created for
> eliminating unnecessary code that is no longer used, plus this, and
> use a new methodology as suggested by Piotr, to take the FFmpeg code
> and apply our patches on it, rather than merging the FFmpeg version
> with our code.
>
I rebased https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m2 to
remove the various reversion commits I added.  See
https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m3 , not (yet)
tested to compile at each commit.

My pull request, https://github.com/MythTV/mythtv/pull/416 , mostly does
not touch the FFmpeg copy in the mythtv repository.
>
> The list of our patches can be stored somewhere and updated as
> necessary so that it can be applied to each new FFmpeg version.
> Alternatively, once the patches have been applied to a version, they
> can be extracted again using git format-patch and applied to the next
> version with git am. This could also pick up any new patches that were
> subsequently applied to our FFmpeg code, although hopefully these
> could be kept to a minimum.
>
> Peter
>
It should be easier to rebase from one release branch to another, since
I have split the changes and eliminated others.

The subtitle changes need to be investigated to determine if they are
still necessary.  What the mpegts changes *are* also needs to be
determined.  Additionally, the use of internal ffmpeg headers in MythTV
needs to be replaced.

Peter: you deleted README.sync.  Was that intentional?  If so, you can
probably drop the commits editing it.


Scott

> Wiadomo?? napisana przez Scott Theisen <scott.the.elm@gmail.com> w dniu 25.11.2021, o godz. 07:50:
>
> On 11/24/21 8:39 PM, Peter Bennett wrote:
>> Thank you. Great work. I plan to combine the list of commits that Scott Theisen created, plus the pull request that he created for eliminating unnecessary code that is no longer used, plus this, and use a new methodology as suggested by Piotr, to take the FFmpeg code and apply our patches on it, rather than merging the FFmpeg version with our code.
>>
> I rebased https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m2 to remove the various reversion commits I added. See https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m3 , not (yet) tested to compile at each commit.
>
> My pull request, https://github.com/MythTV/mythtv/pull/416 , mostly does not touch the FFmpeg copy in the mythtv repository.
>> The list of our patches can be stored somewhere and updated as necessary so that it can be applied to each new FFmpeg version. Alternatively, once the patches have been applied to a version, they can be extracted again using git format-patch and applied to the next version with git am. This could also pick up any new patches that were subsequently applied to our FFmpeg code, although hopefully these could be kept to a minimum.

Peter,
Why not to go with ffmpeg as git subproject of mythv?
With capability of optional ffmpeg git hash declaration at i.e. myth config stage?
In myth releases we can go ffmpeg tags (so no any config variables) - but for any ffmpeg bisecting or experiments or even forking (absolutely to avoid but you know life is life......)


>>
>> Peter
>>
> It should be easier to rebase from one release branch to another, since I have split the changes and eliminated others.
>
> The subtitle changes need to be investigated to determine if they are still necessary.

Scott
You are reading my minds :-)
IMHO we should do this painful work of: reducing downstream to minimal must have.

> What the mpegts changes are also needs to be determined.
IMHO this will be great - especially for:
-any interactions with upstream (bugs report, potential upstreaming some of our code as ffmpeg improvements, etc)
-go with shared ffmpeg (i can imagine model with: system ffmpeg + just few patches on it for mythtv; this shared ffmpeg used by mythtv/kodi/mpv/etc)
-minimize potential regressions due downstream incompatibilities with upstream changes

> Additionally, the use of internal ffmpeg headers in MythTV needs to be replaced.
Indeed.
For me this - when achieved - will force "kind of discipline" regarding ffmpeg api consumption, better decouple life-cycles of ffmpeg & mythtv, make modularity, etc


>
> Peter: you deleted README.sync. Was that intentional? If so, you can probably drop the commits editing it.
Maybe we can drop all README commits and put content into subproject git README.md?


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/25/21 1:50 AM, Scott Theisen wrote:
> Peter: you deleted README.sync.  Was that intentional?  If so, you can
> probably drop the commits editing it.
>
Scott

I moved it to a new location so that it was not in the FFmpeg directory
and renamed it

https://github.com/MythTV/mythtv/blob/devel/ffmpeg-resync/mythtv/external/FFmpeg-sync-instructions.txt

This is instructions for the resync process. They will have to be
rewritten if the new approach works.

Thank you for all the work. Let me know when it is ready to be
committed. I will commit the MythTV changes in master and create a new
devel/ffmpeg_resync based on master with the new setup there.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/25/21 5:42 AM, Piotr Oniszczuk wrote:
> Peter,
> Why not to go with ffmpeg as git subproject of mythv?
> With capability of optional ffmpeg git hash declaration at i.e. myth config stage?
> In myth releases we can go ffmpeg tags (so no any config variables) - but for any ffmpeg bisecting or experiments or even forking (absolutely to avoid but you know life is life......)

I had looked at this before. I am not experienced with advanced git
usage like subprojects. From what I could find out there would be a
problem with the build process, because a git clone or pull of the
mythtv project would not get the ffmpeg code, there had to be a separate
git command to refresh the FFmpeg directory in MythTV. There may be a
way but I could not figure it out.

My thinking is now that we can stop using the MythTV/FFmpeg repository.
For each new resync just copy the code from the latest tag of
FFmpeg/FFmpeg into MythTV/external/FFmpeg and apply our patches to that.

For bisecting FFmpeg we will need to bisect in the FFmpeg repository,
then copy and apply patches for each test.

If you have details of a better way please let me know. How would the
subproject work? Would we still use the MythTV/FFmpeg repository? How
would the pull or clone work to get the subproject code pulled into the
main code structure?

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

>
>
> My thinking is now that we can stop using the MythTV/FFmpeg repository.
> For each new resync just copy the code from the latest tag of
> FFmpeg/FFmpeg into MythTV/external/FFmpeg and apply our patches to that.
>
> For bisecting FFmpeg we will need to bisect in the FFmpeg repository,
> then copy and apply patches for each test.
>
> This is exactly what I did when searching for the offending commit.
And it is a way of working that I can understand.
Getting the git submodules to work properly needs a collection of scripts
harnessing the git commands to avoid too many mistakes, as I understand it.
Also, where I work they are not using git modules and they do have huge
devops teams... Unless somebody stands up as the git master I prefer to
keep things as simple as possible.

About the bug itself.
I have built the mpv player against pristine ffmpeg release/4.4 and against
ffmpeg release/4.4 with the offending commit reversed and also here
reversing the commit does fix the blocking issue.
My plan is to report this to the ffmpeg bug list. YMMV but at least I
should try.

Klaas.

And this is the FFmpeg ticket:

https://trac.ffmpeg.org/ticket/9532#ticket

Klaas.

On 11/25/21 9:16 AM, Peter Bennett wrote:
> Thank you for all the work. Let me know when it is ready to be
> committed. I will commit the MythTV changes in master and create a new
> devel/ffmpeg_resync based on master with the new setup there.
I have cleaned up the patches as well as I could.  Each now compiles on
top off the previous commit.

No new mythtv changes.

More reversions and fixups at
https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m2

Rebased and force pushed:
https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m3


The patches should be ready now.

As an aside, I think the ffmpeg code would be much cleaner and clearer
as C++ instead of C.

Scott

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Thu, 25 Nov 2021 20:58:00 +0100, you wrote:

>And this is the FFmpeg ticket:
>
>https://trac.ffmpeg.org/ticket/9532#ticket
>
>Klaas.

It would help them fix this if they could download a copy of the
tweevoortwaalf_ffmpeg.ts file from somewhere.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/25/21 9:27 PM, Scott Theisen wrote:
> On 11/25/21 9:16 AM, Peter Bennett wrote:
>> Thank you for all the work. Let me know when it is ready to be
>> committed. I will commit the MythTV changes in master and create a
>> new devel/ffmpeg_resync based on master with the new setup there.
> I have cleaned up the patches as well as I could.  Each now compiles
> on top off the previous commit.
>
> No new mythtv changes.
>
> More reversions and fixups at
> https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m2
>
> Rebased and force pushed:
> https://github.com/ulmus-scott/FFmpeg/commits/rebase/4.4m3
>
>
> The patches should be ready now.
>
> As an aside, I think the ffmpeg code would be much cleaner and clearer
> as C++ instead of C.
>
> Scott
>
Scott

Thank you for all the work.

I assume that all of the changes are now in 4.4m3? 4.4m2 is now defunct?

Peter


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/26/21 09:25, Peter Bennett wrote:
> Scott
>
> Thank you for all the work.
>
> I assume that all of the changes are now in 4.4m3? 4.4m2 is now defunct?
>
> Peter
They are equivalent in terms of the changes.

4.4m2 has the commits reverting some of the changes that were made with
the reasons I made those changes (excluding the ones I made from the
initial rebase 4.4m to 4.4m2 that I explained earlier in the mailing list).

4.4m3 has those reversions squashed into the commits making the changes
(or dropped altogether) to simplify the history, reduce the number of
extra commits, and make each commit compile (in their new order).

4.4m2 is intended to be a reference for what and why I changed the
MythTV additions.

4.4m3 is intended to be what is applied onto FFmpeg because of its
simplified history and the extra commit messages referencing the
original changes in the mythtv repository.

Scott
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org