[mythtv-users] next step the player, any suggestions?

[John Pilkington]

On 27/10/2022 02:16, Stephen Worthington wrote:
> On Wed, 26 Oct 2022 16:25:38 +0100, you wrote:
> 
>> On 26/10/2022 14:15, Hika van den Hoven wrote:
>>> Hoi Hika,
>>>
>>> Wednesday, October 26, 2022, 2:40:15 PM, you wrote:
>>>
>>>> Hoi Stephen,
>>>
>>>> Wednesday, October 26, 2022, 10:44:12 AM, you wrote:
>>>
>>>>> On Tue, 25 Oct 2022 17:51:24 +0200, you wrote:
>>>
>>>>>> hdhomerun_config <ip-address> save /tuner<id> - | ffmpeg -i - -map 0:a -f mp3 - | mpg123 -
>>>
>>>>> I am not sure why you are using the MP3 codec here.  MP3 is a dreadful
>>>>> codec - compressing with it drastically reduces the quality of the
>>>>> audio.  Just converting the audio by decompressing it to WAV format
>>>>> would be much better, and then you can just use aplay:
>>>
>>>>> hdhomerun_config <ip-address> save /tuner<id> - | ffmpeg -i - -map 0:a
>>>>> -f wav - | aplay
>>>>> _______________________________________________
>>>
>>>> I'll give it a try. Earlier aplay would not accept piped input. But
>>>> that could have been the mp3 format. I did try forwarding the native
>>>> format with 'copy' but that created confusion between the pipe and the
>>>> format auto-detect mechanism. A pipe has no extension! ;-)
>>>> The first task was getting it to work. Now comes optimization and the
>>>> fancy work. I might add switches to my python shell to select what
>>>> output to use.
>>>
>>> Well, that does not exactly work. Either aplay's auto-detect is not so
>>> very well or ffmpeg sends incorrect metadata. The result anyhow is a
>>> kind of white noise. It's difficult to determine which text output is
>>> from ffmpeg and which from aplay. I'll have to exactly specify output
>>> and input on both side and maybe that will work.
>>> I think I will first try to implement pyalsa and possibly pyffmpeg.
>>> That will probably give more control.
>>>
>>> For now at least my morning wake-up radio is working.
>>
>> I tried this on a normal TV recording file:
>>
>>   ffmpeg -i  /home/john/SGs/RcSG2/11157_20221017143600.ts  -map 0:a -f
>> wav - | aplay
>>
>> and the audio played fine
> 
> The net says there was a bad version of aplay around in 2018 that
> failed to work out the format of its input files and had to be
> explicitly told the format.  If the version you are using has that
> bug, then try saving to a WAV file and running mediainfo or ffprobe on
> it to see the exact format.  Then use the aplay -f option to set the
> correct format.

I have to admit that my last post was based on recordings that had 
already been processed to remove all but one audio aand one video 
stream.  Raw recordings work for me with -map 0:1, but that might not 
always select the right stream.  The terminal output does show a stream 
analysis, but may not be available in an alarm clock.

ffmpeg -i /full/path/to/xxxxx_hhmmssxx.ts -map 0:1 -f wav - | aplay