Add media.ccc specific parsing of recordings #1250
Conversation
Instead of pushing the `media.ccc` recordings straight into the StreamExtractor straightjacket (which does not really provide the correct API for handling the semantics of the media.ccc data), we parse into an intermediate structure first that contains all relevant information about the different streams. This is required for correct handling of the different languages.
ShareASmile
added
media.ccc.de
...java/org/schabi/newpipe/extractor/services/media_ccc/extractors/MediaCCCStreamExtractor.java
Show resolved
Hide resolved
| .flatMap(r -> | ||
| r instanceof MediaCCCRecording.Video | ||
| ? Stream.of((MediaCCCRecording.Video) r) | ||
| : Stream.empty() | ||
| ) |
There was a problem hiding this comment.
(also in other places)
| .flatMap(r -> | |
| r instanceof MediaCCCRecording.Video | |
| ? Stream.of((MediaCCCRecording.Video) r) | |
| : Stream.empty() | |
| ) | |
| .filter(MediaCCCRecording.Video::isInstance) | |
| .map(MediaCCCRecording.Video::cast) |
| MAIN, | ||
| /** A side-recording of a talk/event that has the slides full-screen. | ||
| * Usually if there is a slide-recording there is a MAIN recording as well */ | ||
| SLIDES |
There was a problem hiding this comment.
Probably we should add something like this but for videos, to distinguish between the main and secondary types
There was a problem hiding this comment.
I’d go for “as small an enum here as possible” and then convert on the NewPipe side to the enum that NewPlayer expects. I’d slowly expand these as I find new edge-cases in the mediaCCC APIs (they add new kinds of features every year or so, usually with backwards compat in mind).
There was a problem hiding this comment.
True, but it's something that should be exposed at the extractor-level APIs, not be specific for every service. This way it would be easy in clients to add a switch that allows choosing the video track type.
There was a problem hiding this comment.
Yes, maybe, once we figured out which parts are specific to media.ccc.de and which ones can be abstracted :)
I think a major issue with NPE is that it’s trying to unify the services too much, and then we get lots of workarounds on the NewPipe side cause we have to reconstruct specific service behaviour again that was unified on the NPE side. I’d rather cast on the class and then have some service-specific functionality available if I need it in the player.
|
I would be ok with merging this as-is (after you fix my other comment), since it's not adding any new functionality for now but just adds the ability to load all recordings. Going forward, I believe it's important to make the API general (especially when it comes to just classifying the type of audio/video, be it slides, normal video, voiceover, etc.), but to also allow subclasses with service-specific information as suggested by Audric in #858 (comment) . |
Instead of pushing the
media.cccrecordings straight into the StreamExtractor straightjacket (which does not really provide the correct API for handling the semantics of the media.ccc data), we parse into an intermediate structure first that contains all relevant information about the different streams.This is required for correct handling of the different languages.
It should not change the API, since its specfic to the media.ccc Extractor. I just type-cast in frankenplayer at the moment.
I skipped adding getters/setters in the MediaCCCRecording structs, once this repository is migrated to Kotlin (?), it would just be a data class.