dhumketuxbox / ror5

Automatically exported from code.google.com/p/get-flash-videos
0 stars 0 forks source link

Feature Request: Put the source URL in the file's xattrs #531

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I just noticed today that Chrome has an excellent feature -- it puts the URL 
that you download a file from in the file's extended attributes.

Here's an example:

# file: Bret Victor - Media for Thinking the Unthinkable (2013).mp4
user.xdg.origin.url="http://pdl.vimeocdn.com/51867/368/167262784.mp4?token=13700
19941_fd03e60e7a0dc088e95e66dd3fd4a0bf"
user.xdg.referrer.url="http://vimeo.com/67076984"

I think it would be great if get-flash-videos supported this feature. It would 
make it easy to archive videos, but still give people links to them, or be able 
to download a higher-quality version at a later date.

Original issue reported on code.google.com by seegahan@gmail.com on 20 Aug 2013 at 6:25

GoogleCodeExporter commented 8 years ago
Here's a nice simple Perl wrapper around the xattr system calls: 
http://search.cpan.org/~opi/Linux-UserXAttr-0.02/lib/Linux/UserXAttr.pm

Original comment by seegahan@gmail.com on 20 Aug 2013 at 6:27

GoogleCodeExporter commented 8 years ago
Another good use for these xattrs is as a sanity check when resuming a 
download, so that you don't accidentally resume a youtube video with a 
different video ID.

It might also be useful to store other metadata, like the quality level. I've 
downloaded corrupted videos by accident before by doing something like this:

$ get-flash-videos <youtube url>
# <starts downloading>
^C
$ get-flash-videos -r medium <youtube url>
# <appends medium quality video to partially-downloaded high-quality video>

If the quality level was stored in the xattr, when the user tried to download 
at a different quality setting, it could prompt the user to overwrite the file, 
or to resume with the proper quality setting.

Original comment by seegahan@gmail.com on 20 Aug 2013 at 6:44

GoogleCodeExporter commented 8 years ago
get_flash_videos has to be portable and work on Windows, MAC, and so on. I use 
OpenBSD myself. The clue this isn't portable is in the name, to be sure look at 
the cpan perl version/platform coverage.

The example given the token may only be valid for a short period, storing that 
may not be such a good idea if that is the case. 

The mp4 file format includes quality already, ffprobe can extract, mp4 may also 
include additional metadata.

Original comment by njtaylor...@gmail.com on 26 Aug 2013 at 12:37

GoogleCodeExporter commented 8 years ago
There are some good use cases for this feature:

---

1) The Archivist

People who are archiving content from Youtube, Vimeo, etc., so that if a video 
gets taken down, they'll have a record of where it came from. They could then 
figure out a way to publish it so that people looking for the original can find 
it.

---

2) The Video Creator/Remixer (for attribution)

If you're using other people's clips in your own video, you should be giving 
attribution. This would allow you to easily keep a record of where the clips 
came from without having to resort to manually maintaining your own database of 
filenames and urls.

---

The concern about portability shouldn't be an issue. If an operating system 
doesn't support extended attributes, then get-flash-videos can still download 
the file.

I'm not sure if you were aware, but all modern filesystems support extended 
attributes. See: http://en.wikipedia.org/wiki/Extended_attribute

The two major platofrms have a different name for them -- "Resource Forks" on 
Mac OSX, "Alternate Data Streams" on Windows -- but they function identically. 
(In fact, Linux's NTFS driver just pretends that NTFS' "Alternate Data Streams" 
are xattrs.)

Original comment by seegahan@gmail.com on 27 Aug 2013 at 5:03