Add DVB subtitles support #1781

tresvecesseis · 2016-08-26T08:01:39Z

Added support for graphic subtitles and use that infrastructure to provide DVB subtitles over MP2T

tresvecesseis · 2016-09-02T10:52:03Z

@ojw28 Could you say if you approve our method to add support for graphic subtitles? our next patch (teletext subtitles) need support of graphic chars and we want to build it´s support in top of this pull request.

kiall · 2016-12-28T17:36:37Z

Any update on this? I'd love to see it wrapped up and merged, as it would be very useful for my app (See kiall/android-tvheadend#36) where we receive mostly raw satellite feeds from a local Satellite to IP server. Transcoding content is possible (albeit, at the cost of server CPU time), but tvheadend doesn't offer subtitle transcoding, so we're out of luck there.

ojw28 · 2016-12-29T00:02:18Z

@kiall - We asked for clarification about the CLA with respect to this pull request in #179 and didn't receive any. We wont be looking in detail until clarification is provided.

Note that a piece of the functionality needed to support bitmap subtitles, which overlaps will some of this pull request, is likely to be merged via #2219.

tresvecesseis · 2016-12-29T10:42:45Z

I was not aware of any pending CLA clarifications, just checked the email. In any case from the last conversation with @AquilesCanta and you, I assumed that you were not interested in support this code directly on ExoPlayer and that you will provide a way to do this out of tree, since then we are porting our DVB subtitle patches to use #726, but even if we finish this port (new features keeps us from finishing this) we need graphic subs support in the subtitle subsystem 530977d

perchrh

A more generic, and perhaps attractive api change for exoplayer could be to generalize subtitles into overlays. There could be text-based overlays and graphics-based overlays. Subtitle then, would be a type of overlay. Ads, news or live-discussions could be other types of overlays.

This patch places some Bitmap code in the exoplayer2.text package, which they may not like.

tresvecesseis · 2016-12-29T12:25:32Z

Something along these lines was our first approach but then we decide to maintain the changes on the ExoPlayer library at a minimum to have better chances to get the patches accepted. But for our VR player we are considering passing two surfaces to ExoPlayer to separate video and overlays and have more compositing possibilities (head aligned overlays, ...)

ojw28 · 2016-12-29T14:04:32Z

The plumbing of bitmaps through the text package is likely to be merged in via #2219. We've no objection to that change, and it's more or less required to enable support for bitmap subtitles to be added via extension in a clean way. Whether we then support DVB directly so that you don't need to do any extension is being re-assessed as per #179. It's more likely than it was in the past, at least.

The CLA question isn't about whether the CLA is signed. It's about whether the code is an original creation as per the requirements of the CLA. One of the changes in this PR has "Original C code taken from VLC project" written in it. I don't think you can take GPL licensed code, make a derivative work and then remove the license. In general we can only accept original code where the contributor owns the copyright/IP and where it's not subject to other licenses. If you believe the PR does meet the requirements of the CLA, please clarify. Thanks!

ojw28 · 2016-12-29T14:14:56Z

Re the more general overlay suggestion: As soon as you're thinking about arbitrary overlays (e.g. live discussions) you probably also want things like custom animations, fades, clever interactions with playback controls etc. I don't think it's possible to come up with a general way of modeling that, short of reimplementing the whole Android UI layer. So I think the best way to support such cases is just to provide a way for applications to insert custom layouts on top of the video where they can do whatever they like. Which is something you can already do. There are a whole bunch of ways to do this, for example overriding exo_simple_player_view.xml (see this post for details).

tresvecesseis · 2016-12-29T14:31:27Z

I suppose that a port of a LGPL code is a derivative work, so in his current state the including library will have to comply with the LGPL. We don't want to reimplement the lib from scratch so we will create a separate library with LGPL code that links with ExoPlayer and use a custom TsPayloadReader to inject de DVB subs reader, this way we will be able to redistribute the library with the appropriate license attached and without ExoPlayer code being tainted by LGPL code.

…

On Thu, Dec 29, 2016 at 3:04 PM, ojw28 ***@***.***> wrote: The plumbing of bitmaps through the text package is likely to be merged in via #2219 <#2219>. We've no objection to that change, and it's more or less required to enable support for bitmap subtitles to be added via extension in a clean way. Whether we then support DVB directly so that you don't need to do any extension is being re-assessed as per #179 <#179>; it's more likely than it was in the past, at least. The CLA question isn't about whether the CLA is signed. It's about whether the code is an original creation as per the requirements of the CLA. One of the changes in this PR has "Original C code taken from VLC project" written in it. I don't think you can take GPL licensed code, make a derivative work and then remove the license. In general we can only accept original code where the contributor owns the copyright/IP and where it's not subject to other licenses. If you believe the PR does meet the requirements of the CLA, please clarify. Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1781 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ99vwpL61AKCLAJOoh6P7spwBGoyI3jks5rM733gaJpZM4Jt1YP> .

ojw28 · 2017-02-27T15:33:55Z

@tresvecesseis - We've now merged the rendering changes required to support DVB subtitles (i.e. the required changes to Cue and SubtitleView). It would be cool if we could get to the point where adding DVB support is as simple as inserting the additional subtitle decoder when building an ExoPlayer instance. Specifically, this means I think it would be fine for you to propose a pull request that merges:

The addition of the DVB mime type to MimeTypes.java
Any remaining change necessary to Format.java for your use case
Changes to TsExtractor that expose the track

This will result in the track being visible, but ignored as not supported by default. Enabling support in your app will not require any changes within the library itself. You'll be able to simply pass your own SubtitleDecoderFactory that's capable of instantiating a DvbSubtitleDecoder. The DvbSubtitleDecoder will live in your application code (or some other library, as appropriate).

Note: This is conditional on the TsExtractor changes being an original work (as far as I can see the LGPL derivative work is only in the decoder, but please confirm if you're interested in doing this).

Note2: We would also accept a pull request to add a DvbSubtitleDecoder subject to it meeting the CLA requirements and being an original work. But that can be considered separately.

Thanks!

tresvecesseis · 2017-02-27T16:54:41Z

@ojw28 – We were prioritizing other features in our v2 porting efforts, but we will review the necessary changes and come back to you with an ETA. From: ojw28 <notifications@github.com> Reply-To: google/ExoPlayer <reply@reply.github.com> Date: Monday, 27 February 2017 at 16:34 To: google/ExoPlayer <ExoPlayer@noreply.github.com> Cc: "tresvecesseis@gmail.com" <tresvecesseis@gmail.com>, Mention <mention@noreply.github.com> Subject: Re: [google/ExoPlayer] Add DVB subtitles support (#1781) @tresvecesseis - We've now merged the rendering changes required to support DVB subtitles (i.e. the required changes to Cue and SubtitleView). It would be cool if we could get to the point where adding DVB support is as simple as inserting the additional subtitle decoder when building an ExoPlayer instance. Specifically, this means I think it would be fine for you to propose a pull request that merges: The addition of the DVB mime type to MimeTypes.java Any remaining change necessary to Format.java for your use case Changes to TsExtractor that expose the track This will result in the track being visible, but ignored as not supported by default. Enabling support in your app will not require any changes within the library itself. You'll be able to simply pass your own SubtitleDecoderFactory that's capable of instantiating a DvbSubtitleDecoder, which will live in your application code (or some other library, as appropriate). Note: This is conditional on the TsExtractor changes being an original work (as far as I can see the LGPL derivative work is only in the decoder, but please confirm if you're interested in doing this). Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

tresvecesseis · 2017-03-02T08:35:31Z

I have been studying the needed changes to the ExoPlayer library and we have found that we only need to add the DVB mime type to MimeTypes.java, the other changes could be done in the player with our own TsPayloadReaderFactory and SubtitleDecoderFactory. We will finish our port and come back to you if we find anything else.

tresvecesseis · 2017-03-02T11:00:32Z

@ojw28, It´s possible to make the Ts readers classes public to be able to create a custom TsPayloadReaderFactory?

AquilesCanta · 2017-03-02T11:15:04Z

We will be pushing the visibility change soon.

ojw28 · 2017-03-02T14:01:04Z

@tresvecesseis - You may still want to consider sending a pull request to contribute the TsExtractor changes, despite the fact you're able to inject them via TsPayloadReaderFactory. The main benefit to you would be that if we ever significantly change any of the interfaces that you're implementing, we'd take care of also updating the contributed code. Where-as if it's injected by the application, this will be your responsibility. Up to you of course :).

tresvecesseis · 2017-03-02T14:47:01Z

@ojw28, I was worried about the posible memory leak if I wire up a reader but there is not a subtitle decoder able to consume these buffers.

tresvecesseis · 2017-03-30T23:54:04Z

@ojw28 , I've implemented all your requests, tomorrow I will send some samples of dvb subtitles in matroska and mp2t containers

kiall · 2017-04-02T11:14:27Z

I've re-tested with the latest changes, and have found no issues with the various DVB-S streams I've tested with (other than the colored debug border around the subtitles).

Re samples - here are two sample MKV files, ffprobe output below:

https://www.dropbox.com/s/mb9r314tc2m6taj/The%20Big%20Bang%20Theory.mkv?dl=1
https://www.dropbox.com/s/qm951wa1jhorvgj/BBC%20News.mkv?dl=1

These are both short recordings of programs broadcast over DVB-S which each contain a DVBSUB and a subrip subtitle track.

Input #0, matroska,webm, from 'BBC News.mkv':
  Metadata:
    title           : BBC News
    encoder         : Tvheadend Matroska muxer
    DATE_BROADCASTED: 2017-03-18 19:00:00
    ORIGINAL_MEDIA_TYPE: TV
    CONTENT_TYPE    : News / Current affairs
    TVCHANNEL       : BBC NEWS
    SUMMARY         : Twenty four hours a day - the latest national and international stories as they break. Also in HD. [S]
    SUMMARY-eng     : Twenty four hours a day - the latest national and international stories as they break. Also in HD. [S]
  Duration: 00:04:30.72, start: 0.000000, bitrate: 2002 kb/s
    Stream #0:0(eng): Video: mpeg2video, none(top first), 720x576, SAR 64:45 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 50 tbc (default)
    Stream #0:1(eng): Audio: mp2, 48000 Hz, 2 channels, 192 kb/s (default)
    Stream #0:2(eng): Subtitle: dvb_subtitle (default)
    Stream #0:3(eng): Subtitle: subrip (default)


Input #0, matroska,webm, from 'The Big Bang Theory.mkv':
  Metadata:
    title           : The Big Bang Theory
    encoder         : Tvheadend Matroska muxer
    DATE_BROADCASTED: 2017-03-19 17:30:00
    ORIGINAL_MEDIA_TYPE: TV
    TVCHANNEL       : E4
    SUMMARY         : Penny tells the girls she is unsure about her relationship with Leonard and is considering breaking up with him, but when Sheldon finds out, he tries his best to change her mind. Meanwhile, on the International Space Station, Howard is being bullied by th
    SUMMARY-eng     : Penny tells the girls she is unsure about her relationship with Leonard and is considering breaking up with him, but when Sheldon finds out, he tries his best to change her mind. Meanwhile, on the International Space Station, Howard is being bullied by th
    SYNOPSIS        : S6 E2/24
  Duration: 00:01:56.65, start: 0.000000, bitrate: 2288 kb/s
    Stream #0:0(eng): Video: mpeg2video, none(top first), 704x576, SAR 16:11 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 50 tbc (default)
    Stream #0:1(eng): Audio: mp2, 48000 Hz, 2 channels, 192 kb/s (default)
    Stream #0:2(nar): Audio: mp2, 48000 Hz, 2 channels, 128 kb/s (default)
    Stream #0:3(eng): Subtitle: dvb_subtitle (default)
    Stream #0:4(eng): Subtitle: subrip (default)

ojw28 · 2017-04-03T09:07:16Z

Thanks. We're working on getting this change merged.

ojw28 · 2017-04-03T12:28:26Z

@kiall - Any idea why the audio tracks in those samples have the codec ID set to A_MPEG/L3? Shouldn't the codec ID be set to A_MPEG/L2? This results in the track selector trying to play the track on devices that have an MP3 decoder but don't support MP2. In the case that both are supported but the decoders are distinct, ExoPlayer will feed the audio to the wrong one. Not sure if I've misunderstood something...

kiall · 2017-04-03T14:55:39Z

@ojw28 Humm - ffprobe shows these are mp2 audio, VLC also shows these as "MPEG Audio L1/2".

mkvinfo however does show Codec ID: A_MPEG/L3.

Looking at the muxer code, they have a bug: https://github.com/tvheadend/tvheadend/blob/master/src/muxer/muxer_mkv.c#L293-L296

ojw28 · 2017-04-03T15:07:38Z

library/core/src/main/java/com/google/android/exoplayer2/text/dvb/DvbParser.java

+                    pixel-data_sub-block()
+                while (processed_length<bottom_field_data_block_length)
+                    pixel-data_sub-block()
+                if (!wordaligned())


This looks like it's not implemented (and needs to be). I assume you're supposed to skip 0, 1, 2 or 3 bytes so that you're a multiple of 4 from the start of object_data_segment.

Don't worry about updating the change; I'm working on some changes to merge with it and will put a fix in as part of that. But let me know if the above sounds right. It's not actually defined in the spec what the word length is, as far as I can tell!

Probably more robust just to use the section length and skip to the end of the section.

Is taken into account in code beginning at line 1410:

+ // test for segment Sync Byte and account for possible additional wordalign byte in Object data segment + while (sync == 0x0f || (sync == 0x00 && (sync = tsStream.readBits(8)) == 0x0f)) { + parseSubtitlingSegment(); + if (isSet(FLAG_PES_STRIPPED_DVBSUB) && tsStream.bitsLeft() == 0) { + break; + } + sync = tsStream.readBits(8); + + }

Was done that way because we also didn't know the word length

kiall · 2017-04-03T15:09:02Z

re MP2/MP3 issue - I'll raise this with the TVHeadend folks, in the meantime, I've corrected both samples. Please re-download.

tresvecesseis · 2017-04-04T07:16:02Z

@ojw28 , I have shared with you a google drive folder with some test streams, it even contains a stream with two subs in one PID that, with the current patch, have two problems; only the first subtitle is shown and the two tracks are in french language but one is for the hearing impaired and we have removed the information about the subtitlingType because there is no way to signal this feature

tresvecesseis · 2017-04-04T07:23:33Z

@ojw28 , there are more samples in:

http://samples.mplayerhq.hu/sub/dvbsub/

but the french one is the only ts that is playable in the demo player, I didn't investigate the problem but other players have no issues with them

tresvecesseis · 2017-04-04T13:07:25Z

@ojw28 , finally I decided to implement the multiple subtitles track per PID the ugly way, at least we are feature complete now, fell free to drop the last patch if you think there is a better way

…ng impaired subtitles

ojw28 · 2017-04-05T13:18:00Z

library/core/src/main/java/com/google/android/exoplayer2/text/dvb/DvbParser.java

+            " (x/y): (" + object.objectHorizontalPosition + "/" + object.objectVerticalPosition + ")");
+      }
+
+      region.regionObjects.put(arrayIndex++, object);


If L783 is executed, this line also affects tempRegion.regionObjects. Is that intentional, or should L783 make a copy of the SparseArray rather than just taking a reference to it?

That's why the I added the additional variable, to keep adding elements to the array in case of a page composition update, see the last part of the BBC stream sample, where words are added incrementally to a region

My question is whether it's intentional that both the local object and subtitleService.regions.get(region.regionId) are being modified on this line (because they're both referencing the exact same regionObjects array). Intuitively I'd expect L783 to copy the elements from tempRegion.regionObjects into region.regionObjects, not just update the reference. That would result in only object being modified on this line.

Oh, right. Looking deeper it looks like subtitleService.regions is updated to remove tempRegion anyway after the call to this method complete at L523, so it doesn't make much difference.

ojw28 · 2017-04-05T13:18:56Z

library/core/src/main/java/com/google/android/exoplayer2/text/dvb/DvbParser.java

+    region.regionDepth = tsStream.readBits(3);
+    tsStream.skipBits(2);
+    region.clutId = tsStream.readBits(8);
+    tsStream.skipBits(16);


Is there a reason region8BitPixelCode/region4BitPixelCode/region2BitPixelCode aren't parsed and set on the region here? They're currently not set anywhere in code, but they are read (and will always have a value of 0).

Nop, I forgot to set the values when I implemented the fill region part.

ojw28 · 2017-04-05T13:24:21Z

library/core/src/main/java/com/google/android/exoplayer2/text/dvb/DvbParser.java

+          " (w/h): (" + region.regionWidth + "/" + region.regionHeight + ")");
+    }
+
+    int arrayIndex = 0; // index by an incremental counter to allow repeating objects in one region


What's the purpose of this variable? It looks like it's always equal to the number of items in the regionObjects SparseArray. I think it's equivalent to get rid of this variable and just use an ArrayList. It looks like it's always true that b == objectKey at L1496 as well.

tunip · 2017-04-05T21:12:19Z

German DVB-S2 brodcast sample which contains a DVBSUB:
https://www.dropbox.com/s/74zvfabbq879alg/zdf-hd-sample.ts?dl=0

  Duration: 00:00:28.05, start: 20714.283333, bitrate: 14895 kb/s
  Program 11110 
    Metadata:
      service_name    : ?ZDF HD
      service_provider: ?ZDFvision
    Stream #0:0[0x17de]: Video: h264 ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    Stream #0:1[0x17e8](deu): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 256 kb/s
    Stream #0:2[0x17ea](deu): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, stereo, fltp, 448 kb/s
    Stream #0:3[0x17f3](deu): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006) (hearing impaired)

ojw28 · 2017-04-06T21:56:22Z

Merged. Thanks a lot for your help on this! I ended up doing quite a bit of cleanup, but it was all pretty mechanical. Mainly making things static and final where-ever possible. For parser code in particular, if you can get to the point where you have:

private static SomeObject parseSomeObject(SomeInput input)

where SomeObject is immutable, it makes everything a lot easier to understand. You know the only side effect of calling the method is consuming some input, you know that the parsed object wont be mutated once it's created, and you also know that the parse method doesn't forget to set any fields in the object it's creating. The cleanup change is: 156bc52.

Note: The last commit on this pull request got clobbered as part of the cleanup. Sorry about that. Please feel free to send a new pull request that makes the equivalent change on top of the cleaned up code!

needz · 2017-04-06T21:58:33Z

When testing the newly merged dev-v2 version, I noticed that when there are dvbsubs and cea-608 tracks detected in the stream, it will not select/activate dvbsubs by default:

Renderer:6 [
  Group:0, adaptive_supported=N/A [
 [ ] Track:0, id=1/68, mimeType=application/dvbsubs, language=pol, supported=YES
  ]
  Group:1, adaptive_supported=N/A [
 [ ] Track:0, id=1/8263, mimeType=application/cea-608, supported=YES
  ]
]

But when opening another sample with x-subrip subtitles, the first track is selected and activated by default:

Renderer:6 [
Group:0, adaptive_supported=N/A [
       [X] Track:0, id=4, mimeType=application/x-subrip, language=rus, supported=YES
     ]
     Group:1, adaptive_supported=N/A [
       [ ] Track:0, id=5, mimeType=application/x-subrip, language=rus, supported=YES
     ]
     Group:2, adaptive_supported=N/A [
       [ ] Track:0, id=6, mimeType=application/x-subrip, language=eng, supported=YES
     ]
     Group:3, adaptive_supported=N/A [
       [ ] Track:0, id=7, mimeType=application/x-subrip, language=fre, supported=YES
     ]
     Group:4, adaptive_supported=N/A [
       [ ] Track:0, id=8, mimeType=application/x-subrip, language=spa, supported=YES
     ]
   ]
 ]

Is this expected behaviour?

ojw28 · 2017-04-06T22:04:19Z

If the media indicates that a subtitle should be enabled by default then we enable it. Else we don't. So yes, this is expected behavior where the first sample doesn't mark a subtitle track as default and the second sample does. For MKV I think tracks are marked using FlagDefault (see the spec here).

needz · 2017-04-06T22:50:49Z

Here is a TS sample with DVB Teletext subtitles that are currently not detected by ExoPlayer: https://www.dropbox.com/s/smqq070j0cxug90/NAR_subtitles.ts?dl=0

Input #0, mpegts, from 'NAR_subtitles.ts':
  Duration: 00:03:11.40, start: 8860.800000, bitrate: 2141 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 544x576 [SAR 32:17 DAR 16:9], max. 15000 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x101](NAR): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 128 kb/s
    Stream #0:2[0x102](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 128 kb/s
    Stream #0:3[0x103](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006), 492x250

kiall · 2017-04-07T06:57:02Z

@needz that sample has a DVB teletext stream, not a DVB subtitles stream (the ffprobe output naming is confusing, but that's what it says)

needz · 2017-04-07T07:01:40Z

@kiall, yes, but in this case the subtitles are brought using Teletext (some broadcasters use this instead of DVB subtitles) and most of the devices/players detect and show them just fine. I thought it could be a next step to implement in ExoPlayer in the future.

googlebot added the cla: yes label Aug 26, 2016

This was referenced Aug 26, 2016

Implement bitmap subtitle support #179

Closed

Support injection of custom stream readers into TsExtractor (e.g. to handle DVB subtitles) #726

Closed

EIA608 subtitles enabled unconditionally by TsExtractor #1793

Closed

tresvecesseis force-pushed the dev-v2-dvbsubs branch from 9b72586 to b97e9c8 Compare September 7, 2016 10:20

tresvecesseis force-pushed the dev-v2-dvbsubs branch 4 times, most recently from e69d8f3 to ce2a80f Compare September 15, 2016 13:34

ojw28 assigned AquilesCanta Nov 2, 2016

kiall mentioned this pull request Dec 28, 2016

Support Closed Caption kiall/android-tvheadend#36

Closed

perchrh reviewed Dec 29, 2016

View reviewed changes

kiall mentioned this pull request Jan 3, 2017

Support DVBSUB Closed Captions kiall/android-tvheadend#101

Closed

davic-anime mentioned this pull request Feb 1, 2017

[CC] Implement DVB Subtitles Fleker/CumulusTV#250

Open

ojw28 mentioned this pull request Feb 27, 2017

Dev v2 dvbsubs #2494

Closed

AquilesCanta mentioned this pull request Mar 30, 2017

Support CEA-608 embedded in H262 in MPEG-TS #2565

Closed

Pull request review fixes

d34d3f7

ojw28 reviewed Apr 3, 2017

View reviewed changes

tresvecesseis force-pushed the dev-v2-dvbsubs branch from 05d25a2 to e6f2b88 Compare April 4, 2017 15:06

Add support for multiple subtitle tracks per PID and for naming heari…

38779de

…ng impaired subtitles

tresvecesseis force-pushed the dev-v2-dvbsubs branch from e6f2b88 to 38779de Compare April 4, 2017 15:17

ojw28 reviewed Apr 5, 2017

View reviewed changes

ojw28 merged commit 38779de into google:dev-v2 Apr 6, 2017

rossinior mentioned this pull request May 5, 2017

Support PNG subtitles in SMPTE-TT #1583

Closed

google locked and limited conversation to collaborators Aug 5, 2017

ojw28 added should merge and removed should merge labels Aug 9, 2017

Add DVB subtitles support #1781

Add DVB subtitles support #1781

Conversation

tresvecesseis commented Aug 26, 2016

tresvecesseis commented Sep 2, 2016

kiall commented Dec 28, 2016

ojw28 commented Dec 29, 2016

tresvecesseis commented Dec 29, 2016

perchrh left a comment

Choose a reason for hiding this comment

tresvecesseis commented Dec 29, 2016

ojw28 commented Dec 29, 2016 • edited Loading

ojw28 commented Dec 29, 2016

tresvecesseis commented Dec 29, 2016 via email

ojw28 commented Feb 27, 2017 • edited Loading

tresvecesseis commented Feb 27, 2017 via email

tresvecesseis commented Mar 2, 2017

tresvecesseis commented Mar 2, 2017

AquilesCanta commented Mar 2, 2017 • edited Loading

ojw28 commented Mar 2, 2017

tresvecesseis commented Mar 2, 2017

tresvecesseis commented Mar 30, 2017

kiall commented Apr 2, 2017

ojw28 commented Apr 3, 2017

ojw28 commented Apr 3, 2017 • edited Loading

kiall commented Apr 3, 2017

ojw28 Apr 3, 2017

Choose a reason for hiding this comment

ojw28 Apr 3, 2017

Choose a reason for hiding this comment

tresvecesseis Apr 3, 2017 • edited Loading

Choose a reason for hiding this comment

tresvecesseis Apr 3, 2017

Choose a reason for hiding this comment

kiall commented Apr 3, 2017

tresvecesseis commented Apr 4, 2017

tresvecesseis commented Apr 4, 2017

tresvecesseis commented Apr 4, 2017

ojw28 Apr 5, 2017

Choose a reason for hiding this comment

tresvecesseis Apr 5, 2017

Choose a reason for hiding this comment

ojw28 Apr 5, 2017

Choose a reason for hiding this comment

ojw28 Apr 5, 2017 • edited Loading

Choose a reason for hiding this comment

tresvecesseis Apr 5, 2017

Choose a reason for hiding this comment

ojw28 Apr 5, 2017 • edited Loading

Choose a reason for hiding this comment

tunip commented Apr 5, 2017

ojw28 commented Apr 6, 2017 • edited Loading

needz commented Apr 6, 2017

ojw28 commented Apr 6, 2017

needz commented Apr 6, 2017

kiall commented Apr 7, 2017

needz commented Apr 7, 2017

ojw28 commented Dec 29, 2016 •

edited

Loading

ojw28 commented Feb 27, 2017 •

edited

Loading

AquilesCanta commented Mar 2, 2017 •

edited

Loading

ojw28 commented Apr 3, 2017 •

edited

Loading

tresvecesseis Apr 3, 2017 •

edited

Loading

ojw28 Apr 5, 2017 •

edited

Loading

ojw28 Apr 5, 2017 •

edited

Loading

ojw28 commented Apr 6, 2017 •

edited

Loading