ffmpeg and VLC versus 50fps

[Jim Lesurf]

I've started experimenting with using the hvfhd method for fetching HD
video from the iplayer. (Using gip.) This seems to work quickly and well
except for one problem.

The files I get are 1280x720 image size, as was the case for when I used
older methods. But the video is now 50fps rather than 25fps.

Some of the files play OK with VLC as normal. But others produce no sound
output. ffmprobe shows they all have an audio track (stereo 125k). I'm
puzzled by why some are OK and others are not. The sound is 'findable'
because I can get Audacious to play the audio from a file which VLC can
show the video from, but gives no sound.

I guess the problem is something about my copy of VLC, but am puzzled by
what is making the difference between files that are OK and ones that are
not.

(FWIW The example files are all from the John Wilson / Gershwin Prom.)

So I'm wondering if anyone can advise either with getting VLC to co-operate
or using fmpeg to 'reprocess' the files in some why that will make them
work as they should with VLC.

I'm also tempted by the idea of using ffmpeg to convert the files from
50fps to 25fps. The video quality of the 'old' 1280x720 videos at 25fps was
fine with me, and the new 50fps files are much bigger, so this would save
space.. And maybe that would help VLC to find the sound! (?)

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

[Phi]

"Jim Lesurf" <no...@audiomisc.co.uk> wrote in message
news:55affc8...@audiomisc.co.uk...

I have some films transcoded into .mkv format, they will not play sound in
VLC x64 v2.4.4.........there is blog on it but no definite answer. I use as
an alternative Pot Player x64 v1.6

[Andy Furniss]

Jim Lesurf wrote:
> I've started experimenting with using the hvfhd method for fetching
> HD video from the iplayer. (Using gip.) This seems to work quickly
> and well except for one problem.
>
> The files I get are 1280x720 image size, as was the case for when I
> used older methods. But the video is now 50fps rather than 25fps.

Haven't used gip for ages, so no idea about these new features as such.

Looking on the wiki I see the hvf gets 128kbit sound vs 96 for hls - I
guess that's why you want it.

Speaking of gip I should really get round to installing again to try the
binaural prom tests -

http://www.bbc.co.uk/programmes/articles/2913JxRtQl3ZTvw0wz5C4D1/proms-in-binaural-sound

> Some of the files play OK with VLC as normal. But others produce no
> sound output. ffmprobe shows they all have an audio track (stereo
> 125k). I'm puzzled by why some are OK and others are not. The sound
> is 'findable' because I can get Audacious to play the audio from a
> file which VLC can show the video from, but gives no sound.

Any errors shown starting from command line - maybe with -v?

I rarely test vlc anymore - they still haven't fixed up latm + channel
layout change :-(

It seems they still use faad by default for aac, which is old/unmaintained.

Maybe starting from command line and asking for ffmpeg decoder will make
a difference -

vlc --codec avcodec,all

maybe add --demux avformat,none as a further test.

>
> I guess the problem is something about my copy of VLC, but am puzzled
> by what is making the difference between files that are OK and ones
> that are not.

Does ffmpeg -i <filename> show any difference?

> (FWIW The example files are all from the John Wilson / Gershwin
> Prom.)
>
> So I'm wondering if anyone can advise either with getting VLC to
> co-operate or using fmpeg to 'reprocess' the files in some why that
> will make them work as they should with VLC.

Do other players eg. mpv have problems?

> I'm also tempted by the idea of using ffmpeg to convert the files
> from 50fps to 25fps. The video quality of the 'old' 1280x720 videos
> at 25fps was fine with me, and the new 50fps files are much bigger,
> so this would save space.. And maybe that would help VLC to find the
> sound! (?)

Eww, judder, though I suppose proms aren't in the same league as sport
for being horrible with half the temporal res thrown away. Additionally
if you are watching on TV it may interpolate the frames back anyway,
though mine interpolates a lot better with 50fps input.

No idea if vlc will work by doing this - I assume ideally you would want
to copy sound rather than recode, though you'll have to recode the vid
to loose half the frames.

Assuming you have libx264 installed and ffmpeg was build with it enabled
something like -

ffmpeg -i 50fps.mp4 -c:a copy -c:v libx264 -r 25 25fps.mp4

That will get you libx264 default speed/quality. There are many possible
options to control encode speed/quality/bitrate etc.

[Phi]

"Jim Lesurf" <no...@audiomisc.co.uk> wrote in message
news:55affc8...@audiomisc.co.uk...

Problem solved for the .mkv case.......try this: Open VLC - right click to
interface - preferences - show settings - all - video codecs - FFmpeg - skip
loop filter for H.264 decoding - all - save.

[Andy Furniss]

Phi wrote:

> Problem solved for the .mkv case.......try this: Open VLC - right
> click to interface - preferences - show settings - all - video codecs
> - FFmpeg - skip loop filter for H.264 decoding - all - save.

That's strange for fixing sound - it's an option for reducing cpu load
at the expense of video quality that you shouldn't really need unless
you are trying to decode on some ancient CPU.

Maybe selecting it has some other effect like forcing software decode
whereas before you were using hardware.

[Roger]

On Mon, 15 Aug 2016 12:03:39 +0100, Jim Lesurf
<no...@audiomisc.co.uk> wrote:

>I've started experimenting with using the hvfhd method for fetching HD
>video from the iplayer. (Using gip.) This seems to work quickly and well
>except for one problem.
>
>The files I get are 1280x720 image size, as was the case for when I used
>older methods. But the video is now 50fps rather than 25fps.
>
>Some of the files play OK with VLC as normal. But others produce no sound
>output.

Why did you choose to have such an easy problem to solve?

I'm not really a TV person; I installed gip to download radio.
Notwithstanding that, I went for "Weather for the Week Ahead" as
these are shown as being five minutes. I downloaded 14th, 15th,
and today. All play okay.

Command line: --no-tag --type-tv --tvmode=hvfhd --pid b07my???

Software: perl 5.18.1, get_iplayer 2.95, ffmpeg 3.1.2, vlc 2.2.4
sitting on top of what started as Slackware 14.1 64-bit.

>(FWIW The example files are all from the John Wilson / Gershwin Prom.)

I don't understand what these "example files" are, do we have
access to them?

Good luck.
--
Roger

[Jim Lesurf]

In article <jom5rbd1d72hsqpb7...@4ax.com>, Roger

<inv...@invalid.invalid> wrote:
> >The files I get are 1280x720 image size, as was the case for when I
> >used older methods. But the video is now 50fps rather than 25fps.
> >
> >Some of the files play OK with VLC as normal. But others produce no
> >sound output.

> Why did you choose to have such an easy problem to solve?

I tend to find things become easier in hindsight. :-)

> I'm not really a TV person; I installed gip to download radio.
> Notwithstanding that, I went for "Weather for the Week Ahead" as these
> are shown as being five minutes. I downloaded 14th, 15th, and today. All
> play okay.

I have fetched some hvfhd files that VLC plays OK. But others don't. It
isn't clear why as ffmprobe seems to show me they are the same in terms of
the stream details.

> Command line: --no-tag --type-tv --tvmode=hvfhd --pid b07my???

> Software: perl 5.18.1, get_iplayer 2.95, ffmpeg 3.1.2, vlc 2.2.4 sitting
> on top of what started as Slackware 14.1 64-bit.

The problem I think, is probably with VLC. So the fix might be something
like updating it (or avconv) in some way. However at present I'm not sure
what the cause is, so I'm looking at possibly ways to attack the problem.
Once I've fixed this, hindsight will tell me it was easy. :-)

> >(FWIW The example files are all from the John Wilson / Gershwin Prom.)

> I don't understand what these "example files" are, do we have access to
> them?

There is a 'Proms on TV' webpage on the BBC site. This lists all the Proms
on TV with their full-broadcast pids. It *also* tends to have extra 'per
work' file pids. There are also some 'extras'. The available resoultions,
etc, do vary a bit. But some make it easier to find and watch/listen to a
given item. e.g. the NYOGB Prom has files for the Holst and Strauss as well
as the full prom (and I don't think it was actually broadcast over-air!).

I can't recall the URL offhand, but I have it bookmarked with FF on the
relevant machine (not this one) so can report if you or others would find
it useful.

I chose the Gershwin Prom for using gip to download versions of the files
using different gip methods/modes for comparison purposes. The results are
what I was referring to as 'example' files. I've also recorded it via
DVB-T2 and may do a comparison after the Proms end. Too busy recoroding
and trying to help sort out some current problems at present to do that!
8-]

[Roger]

On Tue, 16 Aug 2016 12:59:34 +0100, Jim Lesurf
<no...@audiomisc.co.uk> wrote:

>In article <jom5rbd1d72hsqpb7...@4ax.com>, Roger
><inv...@invalid.invalid> wrote:
>
>> >(FWIW The example files are all from the John Wilson / Gershwin Prom.)
>
>> I don't understand what these "example files" are, do we have access to
>> them?
>
>There is a 'Proms on TV' webpage on the BBC site. This lists all the Proms
>on TV with their full-broadcast pids. It *also* tends to have extra 'per
>work' file pids. There are also some 'extras'.

Okay, I've got that page. Going to prom 38 (Gershwin) there are
three extras. All three failed to download because there isn't
an hvfhd version only four hls versions.

Prom 29 (Holst, Strauss, Schiphorst) does have hvfhd for the
Planets. Downloading as I type. There will be a long inter-
mission before I can play it (ADSL only here. Even when FTTC
is available I don't need it for what I usually do.).

That took 26 minutes and plays fine. That's a success rate
of 4 out of 4 using hvfhd. Unless you have a PID for an
unsuccessful download I shall stop now. Please remember
to say if an unsuccessful download is hvfhd or something
else.
--
Roger

[Jim Lesurf]

In article <dt96rbpqjvmpvbt5j...@4ax.com>, Roger

<inv...@invalid.invalid> wrote:

> Okay, I've got that page. Going to prom 38 (Gershwin) there are three
> extras. All three failed to download because there isn't an hvfhd
> version only four hls versions.

That is strange. I got four 1280x720 50fps files with 125k audio using the
hvfhd mode. I'll list the details below:

p044lk2b = Rhapsody in Blue. This plays with VLC here. It is the only
example that does. ffmpeg tells me it is 1280x720 50fps with an aac fltp
125k stereo sound stream. File size 398 MB

p044lmdc = American in Paris. No sound with VLC but the ffmpeg report is as
above. 553 MB file

b07pj9nl = The full prom. No sound with VLC. ffmpeg report as above 4347 MB

p044lpr1 = Shall we dance. No sound. ffmpeg as above.

These were all found by starting from

bbc.co.uk/events/r938q9/series/rd4wrz

and opening a new webpage from the link on that to the Gershwin prom.

Not that (ignoring the 'missing segments' problem) hls-fetched hd files are
fine, but are 25fps and < 100 k sound bitrates.

Andy: I already was using the --codec avcodec,all option as you suggested
it some time ago, and it helped wity the problems arising from the streams
switching stereo <-> surround. However using/omitting this made no
difference to the current problem. Nor did adding --demux avformat,all.

A vlc -v in a terminal for playing a file with no audio gave me:

mp4 demux warning: elst box found
mp4 demux warning: CTTS table
mp4 demux warning: elst box found
(This is followed by two occurrances of)
Fontconfig warning: FcPattern object size not acceptable "0"
(Then)
avcodec decoder warning: disabling direct rendering
main vout display error: failed to resize display
main video out warning: picture is too late to be displayed (missing 38ms)

Not sure that helps, but I don't understand it! :-)

[Andy Burns]

Jim Lesurf wrote:

> p044lmdc = American in Paris. No sound with VLC but the ffmpeg report is as
> above. 553 MB file

Is it just that there is a silent or null audio track 0, which VLC plays
bye default, and you can choose e.g. audio track 1 to play it?

[Andy Furniss]

Jim Lesurf wrote:

> p044lmdc = American in Paris. No sound with VLC but the ffmpeg report is as
> above. 553 MB file
>
> b07pj9nl = The full prom. No sound with VLC. ffmpeg report as above 4347 MB
>
> p044lpr1 = Shall we dance. No sound. ffmpeg as above.

I just pulled those and with both my installed vlc and git master they
play OK for me.

Installed = VLC media player 2.2.2 Weatherwax (though I can't remember
whether it was a proper release or some git version from January)

ffmpeg installed version = 2.8.4

I logged the downloads with -v and there were thousands of lines with
ffmpeg reporting about broken timestamps - but the conversion worked.
I guess it just ignored the apparent error of the decode time stamps
being later than the presentation time stamps.

> Andy: I already was using the --codec avcodec,all option as you suggested
> it some time ago, and it helped wity the problems arising from the streams
> switching stereo <-> surround. However using/omitting this made no
> difference to the current problem. Nor did adding --demux avformat,all.

OK that's me out of vlc ideas then other than trying different versions.

I suppose we could be getting content from different CDNs so just
because it worked for me may mean nothing.

If you use -v with gip and redirect output to a file &>logfile it
will be rather large due to the nature of the gip display, but you
can see the urls of the m3u8 files.

> A vlc -v in a terminal for playing a file with no audio gave me:
>
> mp4 demux warning: elst box found
> mp4 demux warning: CTTS table
> mp4 demux warning: elst box found
> (This is followed by two occurrances of)
> Fontconfig warning: FcPattern object size not acceptable "0"
> (Then)
> avcodec decoder warning: disabling direct rendering
> main vout display error: failed to resize display
> main video out warning: picture is too late to be displayed (missing 38ms)
>
> Not sure that helps, but I don't understand it! :-)

I see almost the same, but of course it works for me. -v -v will spew a
lot more, though I don't know whether it will show anything interesting.

[Roger]

Sorry to keep you waiting; I was busy yesterday evening.

On Tue, 16 Aug 2016 16:42:25 +0100, Jim Lesurf
<no...@audiomisc.co.uk> wrote:

>In article <dt96rbpqjvmpvbt5j...@4ax.com>, Roger
><inv...@invalid.invalid> wrote:
>
>> Okay, I've got that page. Going to prom 38 (Gershwin) there are three
>> extras. All three failed to download because there isn't an hvfhd
>> version only four hls versions.
>
>That is strange. I got four 1280x720 50fps files with 125k audio using the
>hvfhd mode. I'll list the details below:

Strange? Yes and no! I was browsing with javascript off so no
pretty pictures and the only sections I could see were "Love
walked in", "The man that got away", and "Applause, applause".

Enabling javascript I see that the sections you mention below.
Ho hum.

>p044lk2b = Rhapsody in Blue. This plays with VLC here. It is the only
>example that does. ffmpeg tells me it is 1280x720 50fps with an aac fltp
>125k stereo sound stream. File size 398 MB

Not tried as this works for you.

>p044lmdc = American in Paris. No sound with VLC but the ffmpeg report is as
>above. 553 MB file

Downloaded and plays fine.

>b07pj9nl = The full prom. No sound with VLC. ffmpeg report as above 4347 MB

Not downloaded; I'm not on unlimited. Might schedule for after
midnight when I'm not metered.

>p044lpr1 = Shall we dance. No sound. ffmpeg as above.

Downloaded and also plays fine.

>A vlc -v in a terminal for playing a file with no audio gave me:

I get similar warnings to you. It looked as though they were
scrolling up the whole time so redirected stderr to a file.
There are 13788 lines of warnings when playing "Shall we dance".

The first six are "cannot load module" for various modules. Then
"running vlc with the default interface..." then

mp4 demux warning: elst box found

mp4 demux warning: STTS table of 16392 entries
mp4 demux warning: CTTS table of 8538 entries

mp4 demux warning: elst box found

mp4 demux warning: STTS table of 1 entries
faas decoder warning: decoded zero sample
also audio output warning: device cannot be paused
avcodec decoder warning: plane 0 not aligned

avcodec decoder warning: disabling direct rendering

The last two lines go on and on and on and ... to the
end of the file.

What does it all meaning? Don't know. All I know is that sound
and vision are okay.

As Mr Furniss and I are using completely different versions of
ffmpeg that can be ruled out. His VLC 2.2.2 and my 2.2.4 are
probably very similar; I don't recall you saying which version
you are using. If it isn't a 2.2.x version that could be
significant. Or not.

Again good luck.
--
Roger

[Jim Lesurf]

In article <e1gttp...@mid.individual.net>, Andy Burns

Before replying to that I'll add some *good* news.

I experimented this morning and fetched the same pids using hvfhd, but this
time with the --raw option for gip. The resulting .ts files all play fine
with my copy of VLC! Audio and Video are fine, and the timestamping also
seems fine.

The 'cleaned' (converted from ts to mp4 automatically after fetching)
versions still give no audio.

On a practical level, that solves the difficulty, but doesn't really tell
me what was going wrong or how to fix it (as distinct from avoiding it by
using -raw).

re your question: I had tried switching the audio track on and off with the
VLC interface (I've forgotten what they call the option to not play the one
track shown.) This made no difference.

IIRC The audio stream is 0,1 according to ffprobe. The video 0,0.

[Jim Lesurf]

In article <GaydnS754Yt11C7K...@brightview.co.uk>, Andy
Furniss <spam@spam> wrote:

First: If you haven't already read it, cf my previous posting about using
--raw with gip to dodge the problem...

> Installed = VLC media player 2.2.2 Weatherwax (though I can't remember
> whether it was a proper release or some git version from January)

Mine VLC is 2.1.4 Rincewind so is presumably old.

> ffmpeg installed version = 2.8.4

I think the relevant machine has Avconv installed. I do use a locally built
ffmpeg that is relatively recent. I guess I should dig out the details and
get the current ffmpeg.

My guess is that something involved on my machine is 'too old' and doesn't
handle the hvfhd files properly. But I'm not clear if the problem is with
VLC or Avconv (installed) or what!

Need to do some experiments when I get a chance. But the focus now is to do
some more fetching over the next few days. Sod's Law that all this happens
during the Proms! :-/

[Andy Furniss]

Jim Lesurf wrote:
> In article <GaydnS754Yt11C7K...@brightview.co.uk>, Andy
> Furniss <spam@spam> wrote:
>
> First: If you haven't already read it, cf my previous posting about using
> --raw with gip to dodge the problem...

That's handy - I did test raw by cp before a download had finished and
noticed vlc played them without logging timestamp issues. The same file
played with ffmpeg or vlc -v --demux avformat,none will spew warnings
so I guess vlcs ts demuxer is just not verbose about or doesn't see it.

On your "ts made with ffmpeg being larger" question elsewhere, that's
normal as ffmpeg puts in lots of PID 0 packets and also it seems dups
them on PID 0x1000. I'm not sure why it does the dups - it could be to
make the stream compatible with atsc as well as dvb.

>
>> Installed = VLC media player 2.2.2 Weatherwax (though I can't remember
>> whether it was a proper release or some git version from January)
>
> Mine VLC is 2.1.4 Rincewind so is presumably old.
>
>> ffmpeg installed version = 2.8.4
>
> I think the relevant machine has Avconv installed. I do use a locally built
> ffmpeg that is relatively recent. I guess I should dig out the details and
> get the current ffmpeg.

Could be avconv/ffmpeg version, you can see the command used with -v on
gip command line - so you could experiment with the ts files from --raw.

all it does roughly on my setup is -

ffmpeg -i in.ts -vcodec copy -acodec copy -absf aac_adtstoasc out.mp4

which causes ffmpeg to note -

[mp4 @ 0x20c21a0] Codec for stream 0 does not use global headers but
container format requires global headers
[mp4 @ 0x20c21a0] Codec for stream 1 does not use global headers but
container format requires global headers

Maybe there's scope for some different behavior there.

[Jim Lesurf]

In article <asednWLJmqLsUynK...@brightview.co.uk>, Andy

Furniss <spam@spam> wrote:
> Jim Lesurf wrote:
> > In article <GaydnS754Yt11C7K...@brightview.co.uk>, Andy
> > Furniss <spam@spam> wrote:
> >

> >
> > I think the relevant machine has Avconv installed. I do use a locally
> > built ffmpeg that is relatively recent. I guess I should dig out the
> > details and get the current ffmpeg.

> Could be avconv/ffmpeg version, you can see the command used with -v on
> gip command line - so you could experiment with the ts files from --raw.

I'll check that. All being well, I'll git and build the current ffmpeg some
time today. The question then will be how best to use it!

> all it does roughly on my setup is -

> ffmpeg -i in.ts -vcodec copy -acodec copy -absf aac_adtstoasc out.mp4

> which causes ffmpeg to note -

> [mp4 @ 0x20c21a0] Codec for stream 0 does not use global headers but
> container format requires global headers [mp4 @ 0x20c21a0] Codec for
> stream 1 does not use global headers but container format requires
> global headers

> Maybe there's scope for some different behavior there.

I've been told that the problems are due to the use of the he-aac which the
ts spec can't actuially describe correctly in its header. So the ts fibs
and says it is aac lc. It then relies on the client to recognise what it
has been given from the actual stream details. It was also pointed out to
me that the notes on the new release of gip warn that you need at a
relatively recent version of ffmpeg. I guess this may by one reason why!

My next step after building ffmpeg will to to see how to get gip to use
that version.

Alas, the hls 'segmentation problems' continued yesterday, so the server
hasn't yet been fixed. Fingers crossed for that...

But at least I've now had two happy morning sessions of fetching the hvfhd
versions of proms I can actually *play*. 8-] Just a shame the 'first night'
is now out of time.

[Andy Furniss]

Jim Lesurf wrote:

> I've been told that the problems are due to the use of the he-aac which the
> ts spec can't actuially describe correctly in its header. So the ts fibs
> and says it is aac lc. It then relies on the client to recognise what it
> has been given from the actual stream details. It was also pointed out to
> me that the notes on the new release of gip warn that you need at a
> relatively recent version of ffmpeg. I guess this may by one reason why!

I don't think the 128kbit streams are he-aac testing with hvflow does
get he-aac and ffmpeg/mediainfo sees it as such so I expect they call
the 128kbit correctly as LC (also HE is IIRC not really worth using for
"normal" bitrates).

> My next step after building ffmpeg will to to see how to get gip to use
> that version.

Yea, not messing up distros is something I don't have to deal with.
VLC will be using the libs and that may be harder to sort than gip which
just seems to use the ffmpeg command.

If you build your own ffmpeg it will I think be static(ish) by default,
so maybe just copying it to $HOME/bin and checking/making that first in
your path would do.

> Alas, the hls 'segmentation problems' continued yesterday, so the server
> hasn't yet been fixed. Fingers crossed for that...

I haven't seen that, but I see if you make gip verbose you can see
which servers are available/used, so maybe you could use that to look
into things or specify which one to use by appending 1 or 2 to hvfhd -

INFO: Found mode hvfhd1: (gip_hvf_iplayer_5380) hls h264 1280x720
5380kbps stream (CDN: mf_limelight_uk_hls/2)
INFO: Found mode hvfhd2: (gip_hvf_iplayer_5380) hls h264 1280x720
5380kbps stream (CDN: mf_akamai_uk_hls/1)

[Jim Lesurf]

In article <6tSdnWFt9eCurivK...@brightview.co.uk>, Andy

Furniss <spam@spam> wrote:

> > Alas, the hls 'segmentation problems' continued yesterday, so the
> > server hasn't yet been fixed. Fingers crossed for that...

> I haven't seen that, but I see if you make gip verbose you can see which
> servers are available/used, so maybe you could use that to look into
> things or specify which one to use by appending 1 or 2 to hvfhd -

> INFO: Found mode hvfhd1: (gip_hvf_iplayer_5380) hls h264 1280x720
> 5380kbps stream (CDN: mf_limelight_uk_hls/2) INFO: Found mode hvfhd2:
> (gip_hvf_iplayer_5380) hls h264 1280x720 5380kbps stream (CDN:
> mf_akamai_uk_hls/1)

The segmentation problems are with the hls streams (as distinct from hvf).
If I try to exclude Akamai for these, the fetching fails.

The 'old' Flash mode works, but is slooow, and of course may cease being
offerred as the BBC want to get people off using it.

[Jim Lesurf]

In article <np5eql$faj$1...@dont-email.me>, Martin Gregorie
<mar...@address-in-sig.invalid> wrote:

> On Thu, 18 Aug 2016 10:17:59 +0100, Jim Lesurf wrote:

> > My next step after building ffmpeg will to to see how to get gip to
> > use that version.
> >

> I think the best approach, whenever you install something that isn't one
> of your distro's packages, is to modify Makefile so "make install" puts
> all compiled components in the /usr/local directory structure rather
> than in the /usr structure and change PATH (and LD_LIBRARY_PATH if
> necessary) so that /usr/local/* is searched before the directories
> containing packaged executables and libraries. This prevents the code
> you've just installed from overwriting anything in a distro package, so
> you can always revert to packaged code by simply deleting the stuff you
> compiled.

[snip]

Thanks. I'll note that for future use! :-)

For now, though, I did my usual: ran a make, then put copies of the results
into an ~/Applications directory.

I found that gip will then let me specify this using

--ffmpeg ~/Applications/ffmpeg

Using this I can now get gip to call this version when fetching via hvfhd
and it converts the fetched ts into an mp4 that *does* give sound with VLC.

Used this a few times this morning and it worked OK.

[Pete Forman]

Jim Lesurf <no...@audiomisc.co.uk> writes:

> In article <np5eql$faj$1...@dont-email.me>, Martin Gregorie
> <mar...@address-in-sig.invalid> wrote:
>> On Thu, 18 Aug 2016 10:17:59 +0100, Jim Lesurf wrote:
>
>> > My next step after building ffmpeg will to to see how to get gip to
>> > use that version.
>> >
>> I think the best approach, whenever you install something that isn't one
>> of your distro's packages, is to modify Makefile so "make install" puts
>> all compiled components in the /usr/local directory structure rather
>> than in the /usr structure and change PATH (and LD_LIBRARY_PATH if
>> necessary) so that /usr/local/* is searched before the directories
>> containing packaged executables and libraries. This prevents the code
>> you've just installed from overwriting anything in a distro package, so
>> you can always revert to packaged code by simply deleting the stuff you
>> compiled.
>
> [snip]
>
> Thanks. I'll note that for future use! :-)
>
> For now, though, I did my usual: ran a make, then put copies of the results
> into an ~/Applications directory.
>
> I found that gip will then let me specify this using
>
> --ffmpeg ~/Applications/ffmpeg
>
> Using this I can now get gip to call this version when fetching via hvfhd
> and it converts the fetched ts into an mp4 that *does* give sound with VLC.
>
> Used this a few times this morning and it worked OK.

I haven't looked at ffmpeg but many packages offer either altinstall or
--prefix to install an extra version to a different location.

--
Pete Forman
https://payg-petef.rhcloud.com
(formerly on http://petef.22web.org/payg.html)