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

Reply via email to