Requests For Features

Budgie ajebay at
Sun Sep 27 07:18:46 PDT 2015

Hi Vangelis,

On 27/09/15 02:23, Vangelis forthnet wrote:
> Hi...
> On Sat Sep 26 17:07:13 BST 2015, Budgie wrote:
>> with long complex titles with meaningless reference numbers
> These are the default filenames GFV generates, based on the
> RTMPDUMP playpaths (i.e. stream identifiers) used on the
> ITV V-O-D RTMP server; a recent example would be:
> 1-8697-0044-001_Downton-Abbey-Episode-1_PC011800_16X9.flv
> While the first "serial number" does seem meaningless
> to us (it probably does mean something to ITV stuff),
> the rest of the filename is descriptive enough;
> "PC01" refers to stream type (... for PCs!),
> while 1800 refers to nominal overall file bitrate
> (currently the highest they offer: video BR ~ 1700kbps,
> audio BR ~ 96kbps); 16X9 is self evident
> (896x504p for PC011800).
> If you choose to use GFV's --filename (-f) switch
> in the download command (e.g. -f  "Downton-Abbey-S06E01.flv";
> MUST include file extension), then the
> downloaded FLV file will have a more "meaningful" filename...

Many thanks for the explanation.  My point was that unfortunately 
obvious descriptions like S1E3 are seldom extant in the filename and 
typing accurately is slow and tedious.

> Why would you need to type manually long filenames?

I leave the filename "as is" until I am satisfied that they are OK, ie. 
have re-muxed OK and metadata is all intact and they play on my 
renderers.  This way if I need to download again I know which to get. 
On the ITV site the description title is not always the same as the 
download title.

> On win32 I choose "Rename" from the right-click context menu
> and then save the filename to clipboard - from there
> it's usually pasted onto a text editor, where I compose/edit
> any command to be pasted onto the Command Prompt Window...


> I do not find myself often in need of batch remuxing FLV files -
> Usually I do them one-at-a-time, using a simple windows batch file;
> if anyone cares, here it is:
> FLVtoMP4remux.bat =>
> ---------------------------------------------------------
> @echo off
> Title Losslessly Remux FLV to MP4
> echo *** Remux AV streams to MP4 container ***
> FOR %%F in (*.flv) DO ffmpeg -i "%%F" -c copy -bsf:a aac_adtstoasc -f
> mp4 "%%~nF.mp4"
> rundll32 user32.dll,MessageBeep MB_ICONWARNING
> echo.
> echo [If you don't want this, close (X) the Command Prompt Window]
> DEL "*.flv"
> :END
> ---------------------------------------------------------

Thanks for that.  I see you are still using the -bsf:a aac_adtstoasc 
option.  I understood from your earlier posts that it was no longer 
required.  Otherwise a much more complete and properly commented batch 
than my quick fix.

>> The mp4 files are all about 3 MiB smaller (in 1.0 GiB). Why is that?
> Fear not! This is a lossless remux, so no loss of quality
> (either video/audio) is involved.
> If you care to see the output from the ffmpeg remux,
> in the end it states something along these lines:
> video:704889kB audio:47404kB subtitle:0kB other streams:0kB global
> headers:0kB
> muxing overhead: 0.362477%
> "muxing overhead" is the extra file size (disk space) needed for the
> media file to be created in the chosen media container (this is put
> very grossly, I'm sure others can rephrase this more accurately...).
> "muxing overhead" = (Overall media file size) - (combined sizes of all
> RAW media streams contained inside)
> The MP4 container has less overhead (is more compact)
> than the initial FLV one, hence the small reduction in file size;
> as a rule of thumb, when the exact same raw streams are at hand,
> muxing overhead: .TS > .FLV > .MP4 ~= .MKV
> The difference between MP4 & MKV is less pronounced...

OK thanks for the explanation.

>> When running the script I get the following comments for each file
>> converted:
>> [mp4 @ 0x22d38e0] Codec for stream 0 does not use global headers but
>> container format requires global headers
>> [mp4 @ 0x22d38e0] Codec for stream 1 does not use global headers but
>> container format requires global headers
>> This omission does not appear fatal but what is going on?
> Please read my June 20th list post:
> Both are benign warnings, issued by FFmpeg branch 2.7+,
> that do not translate to any end file deficiency...
> -----------------------------------------------------------------
That is good to know but I wonder why nobody has fixed it yet.

> A personal comment to the thread title ( Requests For Features):
> Up until this time, I am still hoping that some Perl wizard
> out-there will undertake the task of integrating ITV support
> to GiP (much like the case in GiA) - the plugin
> that is used in GiA for indexing ITV offerings
> does still work in GiP, if put inside
> ".get_iplayer/plugins" folder;
> get_iplayer --type=itv -f --force
> lists all the available ITV progs...
> Then for the actual downloading,
> some perl code could be borrowed from GFV -
> only a few additional perl modules (to the ones
> already shipped with GiP on Win) are needed for that;
> rtmpdump & ffmpeg are already there,
> so we could end up with nice MP4s natively
> (even tagged ones, if ITV metadata is used...).
> It's a shame that one has to install Perl separately,
> then install GFV perl script and then place rtmpdump (& ffmpeg)
> in the same folder, to have a working setup (on Windows)
> (I don't want to add them to PATH...).
> Most sadly, dinkypumpkin is planning to put
> an end (?) to my (and, no doubt, others') wishful thinking:
> C'est la vie!
> -----------------------------------------------------------------
I support your comment but since I am not able to contribute that is all 
I can do.

There is one thing I would like to add to GFV and that is to be able to 
add the target directory for saving the downloads in the same way as in 
GiP prefs.  Any idea how I could do that?


More information about the get_iplayer mailing list