Youtube component for foobar2000 3D Youtube Downloader 3D Youtube Downloader - Batch 3DYD Youtube Source

Changelog

Beta version details

2.0 beta 8 (17-Aug-2017)

Changelog

Beta changelog

Temporary placed here to make it easier to track the changes between beta versions.

Beta 4. Initial public release.

Beta 5. Support decoding and info read for tracks without custom URL scheme. Fixed incorrect behavior of Enter key in search results list. Fixed metadata filling for tracks coming from search popup window. Corrected support of fy+file scheme.

Beta 6. Restored missing labels for controls (screen reader). Added Replaygain support in track properties storage. Also now component will retain info and metadata managed by 1.x version. Updated ffmpeg to 3.3.3.

Beta 7. Added Copy and Columns popup menus to context menu of search results list in search popup window. Fixed lack of clips duration in that list. Adapted that context menu for screen readers. Fixed intermittent failure to start video playback. Fixed search-related context menu items and a crash causing by Make Album menu item.

Beta 8. Metadata overriding now is also possible for tracks representing feeds. Metadata editing now is possible for everything (regular tracks / feeds; with / without metadata overriding; shortcut files), exception - tracks representing search, if they are not coming from shortcut files. Fixed possible hang in album art provider.

Retrospective

While that was started (more than half year ago) with clear intent to add support for live streams and few other things, with the time it became comprehensive rework, refactoring and rethink of the component.

After closer meet with chunked streams (both HLS and DASH) shy hopes to eventually separate component to few ones (site analysis, video, utilities) were ruined because that would require either code and functionality duplication or rich SDK to handle various aspects of data access. Not enough time and patience for second option, but enough conscience not to choose the first one. With that said, there was chosen third option: do one's best within single component. Not elegant, but functional. After the choice was made, everything became simple and started to develop rapidly. One thing was triggering another, and so on.

At first there will definitely be some issues. Please, treat with understanding and notify about everything that does not seem to work properly and is not stated below to been changed.

Live streams support

It finally has been added to component. Currently only for Youtube.

For now video works only when LAV Splitter is selected in component preferences Video Media downloading. There are also problems with video+audio synchronization.

Video visualization

Youtube Video item from menu View Visualization now became just Video. Treat it as a visualization that can play some video for currently played track. It is possible, but not necessary, to use video from the same file where the audio comes from.

Previous behavior (to play videos only from supported sites) can be brought back using advanced preferences Video Allow video playback only for supported URLs.

Improved feeds support

Work with the feeds now is performed in a different way. Visible change in this regard - when adding Youtube feed (i.e. channel or playlist) using menu File Add location... now will be added one track representing this feed, instead of retrieving content of the feed.

Internally the change was to make the feeds to behave like any other tracks. This will make it possible (in future) to search for feeds and to list playlists that channel consists of when it is being added (instead of retrieving videos from 'Uploads' playlist of this channel, as it is done now).

External metadata storage

In 1.x version metadata was getting lost once the track was removed from playlist. That was because metadata and clip properties (description, view count etc.) were stored in track tech info, an internal storage associated with the track. So this storage existed only while track was in the playlist.

Now for the clip properties and metadata edits is used external storage (local file system at this moment). Note, tech info is still used as intermediate storage, so the issue with limit of custom metadata fields length is still there (e.g. description gets clipped and appended with (...) if it is longer than maximum length of tech info field).

Metadata construction changes

Now component maps existing clip properties to metadata instead of developing metadata out of the title.

That is about clip title parse rule. The problem with it is that if you listen the music, it works mostly but not always. If you listen something other than music, it just does not work, making a mess in regular playlist view setups. With that said, it just cannot be default option for metadata construction. New approach is an attempt to make the clips and feeds to look more consistently in regular playlist viewer configurations.

For tracks representing video clips new approach is straightforward: use uploader as %artist% and full clip title as %title%.

Similar thing is done for tracks representing the next portion of the feed ('get more' items in 1.x version). There are more metadata fields developed out of info available from these tracks:

MetadataInfo about search portionInfo about playlist portion
%title%search query stringplaylist title
%album%"Search""Playlist"
%album_artist%"Youtube"title of the channel where this playlist comes from
%tracknumber%index that would have the first clip obtained from this portion of the feed
%totaltracks%number of search resultsnumber of clips in the playlist
%discnumber%index of this feed portion, like page number for search results on the site
%totaldiscs%total number of feed portions
Additionally track duration represents number of items in this portion, one second equals to one item. Well, it is more convenient than it sounds.

If one would like to bring back behavior from 1.x version, it can be enabled using option Enable clip title parsing rule from Features tab of component preferences. Note, to update info for already added tracks in this case (as well as after rule edit) now need just reload track info (e.g. using context menu Properties Metadata Tools Reload info).

Sharing for files being currently downloaded

There can exist several readers at the same time (for audio playback, for video playback, RG scanner, Waveform Seekbar etc) and in 1.x they were initiating individual separate download even if the source file was the same. Now they will use single instance of the file, reducing bandwidth usage.

Previously, to somehow mitigate this need to start several downloads, audio quality settings were divided to settings for playback and 'for other', i.e. anything not related to playback. And quality 'for other' was set to lowest possible. This possibility is retained, but quality 'for other' now is defaulted to the same quality as for playback.

Shortcut files support

These are textual files that behave like shortcuts for the clips. Pretty like m-TAGS, but is designed specifically for the component needs. Note, since feeds are represented by single items now, these files can also point to the feeds, i.e. it is possible to make shortcuts for Youtube playlists or for search.

Well, that one came almost for free, since it is used internally by metadata and properties cache implementation, so why not.

File extension is *.foo_youtube (no imagination). As an example can be used cache files located at <fb2k_config_dir>\foo_youtube\cache\meta\. Reference documentation is not prepared yet.

Technical changes

Custom URL scheme used by component was changed. There was three problems with the old one: it did not conform RFC (started with a number); I never liked it; and (this is what triggered the change) it did not retain original URL scheme. Now this is important, scheme should be retained. So custom URL scheme now is fy+<original_scheme>. Examples: fy+https, fy+file. Full URL example: fy+https://www.youtube.com/watch?v=fJ9rUzIMcZQ

Tracks representing the feeds are special. They have scheme fy+search for search, fy+playlist for playlists, and in future will be added fy+channel for channels.

In 2.x was removed possibility to switch between built in decoder (which uses ffmpeg) and decoding provided by foobar2000 core. There do not seem to be any advantages in context of this component to use both of them. Internal decoder is the must to have chunked streams support. And with possibility to select external ffmpeg binaries it brings additional direction for experiments. So it is the one that stays.

So, decoding is done entirely by ffmpeg. Data access is handled by the component, bringing possibility for shared access (described above) and caching (in a distant future).

When a track is added with fy+ prefix in the URL scheme, component does not check, whether it points to the supported site (or to site at all), and just does its best. In other words, it is possible to play regular files, local or remote. Side effect, that was possible to develop without too much additional effort. Note, embedded ffmpeg has support only for media formats and audio decoders commonly used on online media sites. I.e. formats: mp4, webm, 3gp, mpegts (hls); decoders: aac, opus, vorbis. So you may need to setup external ffmpeg for that. For example, the one that is shipped with LAV Filters can be used.

Live streams support is available only for HLS streams (ffmpeg does not support chunked DASH). Stream selection is handled by the component (according to appropriate quality settings).

Now all Internet access is performed either using foobar2000 API or internally by the component (related settings previously controlled only media files downloading).

Back compatibility

Support for old custom scheme is fully retained. For the clips that were already added to playlist, initial info read will move everything (custom metadata, clip properties, replaygain) to new location. That move is not back compatible.

Support for old custom scheme used for 'get more' items was not retained.

Possibility to override clip title parsing rule via URL param was not retained.

Custom metadata prefix was changed to fy_. Few fields were added, few renamed. Briefly, full list is: %fy_title%, %fy_description%, %fy_uploader%, %fy_published_at%, %fy_view_count%, %fy_like_count%, %fy_dislike_count%, %fy_rating%, %fy_like_ratio%, %fy_channel_url%, %fy_thumbnail_url%.

Other changes

Changelog Beta version details