Bug 5884

Summary: AC-4 codec support
Product: Fedora Reporter: Michael Cronenworth <mike>
Component: ffmpegAssignee: Dominik 'Rathann' Mierzejewski <dominik>
Status: RESOLVED WONTFIX    
Severity: enhancement CC: belegdol, kwizart, leigh123linux
Priority: P1    
Version: f33   
Hardware: x86_64   
OS: GNU/Linux   
namespace:
Attachments: ffmpeg ac-4 patchset for ffmpeg-4.3

Description Michael Cronenworth 2020-12-31 05:52:59 CET
Created attachment 2262 [details]
ffmpeg ac-4 patchset for ffmpeg-4.3

The latest over-the-air TV format is ATSC 3.0 for the USA. The format allows for many different audio codecs including a brand new codec Dolby AC-4. Unfortunately AC-3/E-AC-3, and AAC are not being used and instead AC-4 is being used by every market. There's an open trac ticket with ffmpeg and initial support is available in non-upstream repos.

https://trac.ffmpeg.org/ticket/8349

ATSC 3.0 is being brought online in many major cities and Silicon Dust released their CONNECT 4K unit that can read the signal. Most brand-new TVs have ATSC 3.0 tuners and have the AC-4 codec support built-in.

I've applied the latest AC-4 patchset, slightly modified to apply against 4.3, and I can play a live stream using my CONNECT 4K and Kodi 19. I would like to see these patches applied for RPMFusion.

https://github.com/richardpl/FFmpeg/tree/ac4

I am attaching my 4.3 patchset.
Comment 1 Nicolas Chauvet 2020-12-31 09:18:45 CET
It looks like an interesting feature to have.


I'm not against the backport, but I have some concerns:

1/ This patchset isn't yet in the master branch. So It's annoying to backport something that is still discussed, so it may have to be adapted more of less often.

Will you provide the needed adaptations in case there is any changes needed (specially when a new 4.3 minor release appears?)

Also, is there any "chance" that this patch won't land in the next ffmpeg version ? So we would have to maintain two different branches with this feature backported ?

2/ This patchset is huge and having to put in/out about 240k of patches in git isn't pleasant.
I would recommend to uploaded a single compressed squashed patch in the lookaside cache. Then apply this compressed patch in the ffmpeg package for 4.3.
Also to publish a link to the exact ffmpeg 4.3 branch with your own modifications, even little ones. (so that anyone else will be able to take-over if needed).

Please publish a git-am version against the rpmfusion ffmpeg tree (or the github fork). So this can be reviewed.

@rathann , any additional concerns about this ?
Comment 2 leigh scott 2020-12-31 10:13:01 CET
(In reply to Nicolas Chauvet from comment #1)
> It looks like an interesting feature to have.
> 
> 
> I'm not against the backport, but I have some concerns:
> 
> 1/ This patchset isn't yet in the master branch. So It's annoying to
> backport something that is still discussed, so it may have to be adapted
> more of less often.
> 
> Will you provide the needed adaptations in case there is any changes needed
> (specially when a new 4.3 minor release appears?)

Michael will need to support this  patch-set till f33 goes EOL.

> 
> Also, is there any "chance" that this patch won't land in the next ffmpeg
> version ? So we would have to maintain two different branches with this
> feature backported ?

I intend to update f34 to a ffmpeg-4.4 snapshot this week which will possibly mean two patch-sets are required.
Hopefully 4.4 will be released by late February / early March. 
 

> 
> 2/ This patchset is huge and having to put in/out about 240k of patches in
> git isn't pleasant.
> I would recommend to uploaded a single compressed squashed patch in the
> lookaside cache. Then apply this compressed patch in the ffmpeg package for
> 4.3.

+1 for compressed patch.

> Also to publish a link to the exact ffmpeg 4.3 branch with your own
> modifications, even little ones. (so that anyone else will be able to
> take-over if needed).
> 
> Please publish a git-am version against the rpmfusion ffmpeg tree (or the
> github fork). So this can be reviewed.
> 
> @rathann , any additional concerns about this ?

I have no concerns as long as Michael does the required maintenance.
Comment 3 Michael Cronenworth 2020-12-31 17:11:10 CET
(In reply to leigh scott from comment #2)
> I have no concerns as long as Michael does the required maintenance.

Fine with me. I'll put together the necessary changes and come back around when it's ready.
Comment 4 Dominik 'Rathann' Mierzejewski 2021-01-04 12:56:06 CET
(In reply to Nicolas Chauvet from comment #1)
[...] 
> @rathann , any additional concerns about this ?

I found this thread in ffmpeg-devel:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/257981.html

There was no conclusion to the discussion and there was a serious question about the right way to pass AC-4 frames between different parts of FFmpeg.
Comment 5 Dominik 'Rathann' Mierzejewski 2021-01-04 13:20:40 CET
In other words, I wouldn't feel confident keeping a downstream patch that has seen no progress getting upstream for the last 9 months.
Comment 6 Michael Cronenworth 2021-01-07 18:10:49 CET
This effort will be on hold for the time being. I was under the impression that this latest WIP branch was newer than the March patches. It is not. While the code does work for me within Kodi I noticed other users had issues when attempting to transcode.

I reached out to the original patch author and received no reply. I know he's still contributing as he has patches submitted from a few days ago.
Comment 7 Dominik 'Rathann' Mierzejewski 2021-10-07 12:39:16 CEST
I'm closing this for now. Feel free to reopen if/when there's a solid indication that this is going to get accepted upstream.
Comment 8 Nicolas Chauvet 2021-10-07 15:15:15 CEST
Well, this is unfortunate that AC-4 codec isn't mergeable upstream.

If we could have a copr instance in rpmfusion that would be a matter some 
volunteer to maintain an alternate build with automatically rebasing the changes. (which can occasionally fail, but can be fixed at one owns pace).

Unfortunately it's unlikely that we can have such resources so far...