Some interesting comments all, thanks.
The reason I put --pid at the end of my string is partially to stop me
from forgetting to change it ;-) And I only ever use get_iplayer to grab
stuff for which I've already found the PID for, I always found its PVR
features a little cumbersome for what I wanted.
My explicit SWFVfy declaration was after the default player URL was
removed by the BBC so rtmpdump was having problems with dropped frames
and corrupt downloads, particularly on the HD content.
I was under the impression get_iplayer still transcoded to MP3? I'm
using 2.79 on Windows; I remember a lot of discussion a while back about
the quality of the downloads and people asking how to stop it from
transcoding. I left it as-is because I remember a few things being
broken in updates pushed out - but if newer versions have those bugs
squished and have a newer build of ffmpeg rolled in, I'll certainly give
that a try. I'm a sucker for metadata. Undoubtedly YAMB is a bit long in
the tooth now, I've only just got used to some of its UI quirks ;-)
On 26/09/2012 19:26, dinkypumpkin wrote:
On 26/09/2012 18:19, Christopher Woods (CM) wrote:
Some clarification for new users -
get_iplayer --raw --output G:\iplayer\raw\ --modes
flashaachigh,flashaac,flashaacstd,flashaudio,flashaaclow --rtmptvopts
"--swfVfy http://www.bbc.co.uk/emp/revisions/18269_21576_10player.swf"
--rtmpradioopts "--swfVfy
http://www.bbc.co.uk/emp/revisions/18269_21576_10player.swf" --force
--get --type=liveradio --pid=pidhere
The --swfvfy value is built into get_iplayer. There is no need to use
it on a command line unless you know of a case where the built-in
value no longer works. Also, you don't need --get if you specify
--pid. Think of --pid as shortcut to download a specific programme
when you already know its unique identifier.
a liveradio category result for the pid you enter. My golden rule is to
always have --pid or --url at the very end of the string. Specifying the
10player URL stopped frame drops in videos when rtmpdump couldn't swfvfy
properly.
There is no need to put --url or --pid at the end of your command
line. get_iplayer's argument parsing is not sensitive to entry order.
Using --raw obviates the transcoding (yeurgh). use FLVExtract to rip out
AAC from the FLVs and then use YAMB (or MP4Box if you're not lazy like
me) to remux as an M4A and get it seekable. For videos, I just leave as
FLV as MPC can parse and decode them fine natively; when I remuxed as
MP4 I had frame drift for whatever reason... and at that point I was
happy enough anyway with the H.264 FLVs. :-)
To echo SeƱor Guano: get_iplayer does not transcode. You only need to
re-mux files yourself if you wish to use a different tool or different
parameters. If you prefer to use --raw and stick with FLV files,
that's fine. But if you prefer to re-mux files to MP4 format and get
metadata tags, etc., the combination of get_iplayer and ffmpeg works
pretty well.
If you're using YAMB and consistently seeing drift in re-muxed video,
get an up-to-date version of ffmpeg and let get_iplayer re-mux a few
programmes and then compare the results. No guarantee it will be
better, but ffmpeg (as well as MP4Box) has come along a bit since YAMB
was released a few years ago.
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer