(Updated) About YouTube 1080p and 480p ...

So I found a fairly compact Java MKV library and decided to go ahead and implement support for WebM multiplexing. I already made some changes to the YouTube plugin to facilitate this.

However, now I discovered that the library doesn't actually support writing. The method is just empty!

Language: Java
/**
 * Add a frame
 *
 * @param frame The frame to add
 */
public void AddFrame(MatroskaFileFrame frame) {
 
}

It doesn't seem overly complicated to implement. But it's late already so I can't finish it today.



Edited 1 time(s). Last edit at 04/08/2015 06:05PM by ntoskrnl.

No, I'm giving up on this, because I'd have to implement all kinds of cluster division and cue point selection algorithms, which existing programs like FFmpeg can already do just fine, and much faster and better than anything I could come up with in a couple of days. This is way out of the scope of FRD anyway.

Maybe we should just implement FFmpeg integration instead and get rid of all these questionable Java encoders and decoders (particularly the mp3 encoder... yuck). We don't have to distribute FFmpeg with FRD. The plugin could have an option to select the FFmpeg executable to use.



Edited 2 time(s). Last edit at 04/09/2015 02:08PM by ntoskrnl.

ntoskrnl Wrote:
-------------------------------------------------------
> Maybe we should just implement FFmpeg integration
> instead and get rid of all these questionable Java
> encoders and decoders (particularly the mp3
> encoder... yuck).

Yes, I agree.

> We don't have to distribute
> FFmpeg with FRD. The plugin could have an option
> to select the FFmpeg executable to use.

This will be problematic for most of users. Most of users expect "it should just work", without having to download and install 3rd party tools. How about bundling ffmpeg? If the size is the main concern, maybe we can trim it by custom build. For example, we don't need AVI or WMV, etc. I haven't tried building ffmpeg/avconv, but from past experiences building other apps, it usually only a matter of enabling/disabling build config's parameters.



Edited 1 time(s). Last edit at 04/11/2015 12:24PM by tong2shot.

The default static build of FFmpeg is huge, larger than FRD itself, so it cannot be distributed. However, I agree that many users cannot install it manually.

Building native libraries and programs is problematic because there are so many possible platforms. Do we have resources to build and test all of them? FFmpeg depends on many other libraries which need to be built too.

I guess we could also download and extract FFmpeg automatically when first required, but I'm not sure how to do it smoothly.

ntoskrnl Wrote:
-------------------------------------------------------
> Building native libraries and programs is
> problematic because there are so many possible
> platforms. Do we have resources to build and test
> all of them? FFmpeg depends on many other
> libraries which need to be built too.

Target win32 and let the rest (OSX, Linux, *BSD, etc) suffer, I guess :))

> I guess we could also download and extract FFmpeg
> automatically when first required, but I'm not
> sure how to do it smoothly.

This is even better idea. Maybe Vity and birchie have any opinions regarding this matter?

ntoskrnl or tong2shot Wrote:
-------------------------------------------------------
> We don't have to distribute FFmpeg with FRD. The plugin could have an option
> to select the FFmpeg executable to use.

>This will be problematic for most of users. Most of users expect "it should just work",
> without having to download and install 3rd party tools. How about bundling ffmpeg?

> I guess we could also download and extract FFmpeg automatically when first
> required, but I'm not sure how to do it smoothly.

It currently "just works". Leave this as the default encoding option.
There is no need to bundle or automatically download other software (just to support 1 plugin)

Have an optional 'Advanced' setting to use an external encoder (FFmpeg, etc.. - users choice)
where the user can select an encoder of their choice (already installed by user)
with all parameters needed also supplied by the user
The plugin executes the program with parameters (substituting Aud, Vid, Sub tags with the actual files)
-- not sure how to execute another program, but FRD already does something like this with GOCR

Tag any file type or qualities not supported by the current encoder to prevent inadvertent use
eg "* external encoder required"



Edited 1 time(s). Last edit at 04/11/2015 11:40PM by birchie.

The problem is that YT only provides 720p videos (and above) using DASH. Users can only download low quality videos unless FRD can mux the video and audio into one file. Our current plugin can mux MP4 DASH videos using a Java implementation, though it's not enabled by default. However, the newest video qualities (which are high resolution 60 fps videos) are only provided as WebM DASH. These are not supported at all currently. I would expect that WebM gets more and more common on YT.

ntoskrnl Wrote:
-------------------------------------------------------
> However, now I discovered that the library doesn't
> actually support writing. The method is just
> empty!
>
>
> /**
> * Add a frame
> *
> * @param frame The frame to add
> */
> public void AddFrame(MatroskaFileFrame frame) {
>
> }
>

Still interested in implementing WebM muxer in java? I found this code (http://code.metager.de/source/xref/openfire/src/plugins/jitsivideobridge/src/java/org/ebml/matroska/MatroskaFileWriter.java), the method is not empty. I haven't tested and haven't read it thoroughly though, so it may not work either.

@the devs:

Hello all

Are you familiar with the
"YouTube Video and Audio Downloader"
Firefox addon?

[addons.mozilla.org]

It is one of the best in its category and can even fetch those elusive VEVO
vids other YT downloaders can't.
It's written in Javascript and has muxing/transcoding support via FFmpeg,
which is not bundled, but the user can declare its path to the addon via a
simple "browse" button in the addon's prefs; if FFmpeg is not already found
on the system, the addon can easily download a copy of it (compatible with
the OS it is installed in) from a sourceforge URL the authors of the addon
maintain:

[sourceforge.net]

This is all done via a button in the prefs (about:addons).

As far as size is concerned, with UPX I have compressed a static FFmpeg 2.6.1 win32 binary to
just under 11MB (originally ca. 29 MB ).
Plus, if FFmpeg use is implemented, many other FRD plugins can use it,
so that downloaded FLV/.TS files could be remuxed losslessly to the MP4 -
M4A for audio files - or Matroska (MKV) containers, that are more universally
supported by software/hardware players...
I currently use FLVExtract+MP4Box to remux iPlayer FLVs fetched by FRD
(my hardware media player doesn't like FLVs), so this is only one user case scenario
- others may benefit from other FRD plugins...

Just my 2 cents...

Many thanks for your unwithering support of FRD

Some users may just want to get the original files (FLV)
If you gonna just watch and delete on computer itself, container hardly matters.
No matter how less the system resources are being used while automatically remuxing.. its more or less redundant.
But yes for archival purposes, MP4 sounds like a better option.
So remuxing AKA change of containers should be optional.

And agreed FFmpeg is more robust.
I can grab the binary myself and set the path in FRD options.
But it all depends on the technical level of end user..

Maybe you guys can leave the muxing part (so all users can get a basic working file)
Advanced users can grab a copy of FFmpeg and enable it in the FRD.

I know it will increase your work cause you have to manage twice the code for a single task
But I guess thats how you can keep both set of users happy ;)

Edit: And lets say there are 2 sites that offer FLV
site A for me is like one time watch videos
site B good quality videos I want to watch again

I would prefer site A FLV's to remain as it is
but for site B, I may want to remux them to MP4 or MKV

So remuxing option should be like per-site basis
I know its very confusing.. but lets see what other users and devs have to say!



Edited 1 time(s). Last edit at 04/14/2015 06:56AM by honey_ami.