ffmpeg and VLC versus 50fps

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.

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

On Tue, 16 Aug 2016 16:42:25 +0100, Jim Lesurf
wrote:

In article , Roger
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

In article , Andy Burns
wrote:
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?

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

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

In article , Andy
Furniss [email protected] 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! :-/

Jim

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

Jim Lesurf wrote:
In article , Andy
Furniss [email protected] 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.

In article , Andy
Furniss [email protected] wrote:
Jim Lesurf wrote:
In article , Andy
Furniss [email protected] 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.

Jim

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

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)

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.

If ffmpeg uses autoconf to set up the Makefile it may be easier to edit
configure.ac or configure.in rather than running autoconf and then
editing Makefile.

If you'd like the contents of the /usr/local/* directories to survive
subsequent distro reinstalls/upgrades, do something like this:

cd /usr
mv local /home/local
ln -s /home/local local

though this does assume that /home is in its own partition and that you
don't reformat it during a clean install.


--
[email protected] | Martin Gregorie
gregorie. | Essex, UK
org |

In article , Andy
Furniss [email protected] 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

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

In article , Martin Gregorie
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.

Jim

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