1177 replies to this topic

[christophecvr]

I'm doubting if we shoild domthat as this is in fact a bug in the source... This should be solved at handbrake. Also vlc should habe issues with that extra space!

Well believe me i've been in a discussion with the handbrake guys. The won't change it.

 

But I now have the real reason.

At start older days the ssa codec indeed could not have \N \h  signs.

But since that like a lot of stuff the ssa codec has been extended, to support these signe that's actually the ass tag extention.

So handbrake makes now use off advanced sub station alpha and then yes \N is allowed.

http://docs.aegisub.org/3.2/ASS_Tags/

 

Ok this advanced tag signs are there already longer. gstreamer did solved it with code routine in gstssaparse.c:  of plugins-base subbparse

static gboolean
gst_ssa_parse_remove_override_codes (GstSsaParse * parse, gchar * txt)
{
  gchar *t, *end;
  gboolean removed_any = FALSE;

  while ((t = strchr (txt, '{'))) {
    end = strchr (txt, '}');
    if (end == NULL) {
      GST_WARNING_OBJECT (parse, "Missing { for style override code");
      return removed_any;
    }
    /* move terminating NUL character forward as well */
    memmove (t, end + 1, strlen (end + 1) + 1);
    removed_any = TRUE;
  }

  /* these may occur outside of curly brackets. We don't handle the different
   * wrapping modes yet, so just remove these markers from the text for now */
  while ((t = strstr (txt, "\\n"))) {
    t[0] = ' ';
    t[1] = '\n';
  }
  while ((t = strstr (txt, "\\N"))) {
    t[0] = ' ';
    t[1] = '\n';
  }
  while ((t = strstr (txt, "\\h"))) {
    t[0] = ' ';
    t[1] = ' ';
  }

  return removed_any;
}

Other programs then handbrake already used it , some official media has even been made with those ssa/ass tags for the internal subtitle codecs.

 

Ok this has been done to solve a error with this \N into c and c++ text strings.

Somehow gstreamer provides a valid base. to work further with it into c and c++ but with an unwanted side effect:

- it ads a white space at each end off line.

- the txt line end string trailing edge (string line end) is not removed. Which indeed results in a still very valid c or c++ string a space at the end of line is not invalid we just do not like it or wan't it a trailing edge \n newline  is also valid in c/c++ strings . we do not wan't it.

 

here extra debug code with also the base parsing by gstreamer self.

Attached Files

•  e2-log-gst-log-ssa-codec.txt   7.12KB   2 downloads

[christophecvr]

cvr, you are completely missing the point. The reformatting of the text is done inside the text renderer of enigma. It has nothing to do with either C or C++ or Python. It's a flag you can enable or disable while requesting the text to be rendered.

I can't find such a thing anywhere in the code off e2

[littlesat]

The rerendering breaks the orriginal line break made by the subtitles... I'm afraid Erik dos not really understand the issue. The issue is that handbreak adds some crasy characters when it muxes subs. So the issue should be solved there... And it seems they refuse, so we should add the reverse of what handbrake did do wrong???

The issue handbrake induces must also have side effects on other players... The issue should be solved by handbrake -or- use mkvmerge instread...

I think it is not recommended to put a lot of extra code in our software to work-a-round someone else's crap....

Please post the link of the thread to handbreak here so a lot of people from here can add a lot of comments to them....

Edited by littlesat, 11 June 2016 - 09:22.

[christophecvr]

@Erik Slaghter

 

rendering is done in subsink. this outputs a txt string like said which overlays by us in a pango-page element.

 

Since :

Handbrake is not wrong they are using advanced ssa codecs  this will happen with more programs in future iot also maybe expected by official media.

 

Ok we can go :

- in a building discussion to perhaps improve the base parsing off ssa into gstreamer

- but in the mean time a simple performant patch does solve all in a very clean and performant way with patch on :

http://forums.openpl...ndpost&p=551967

[christophecvr]

The rerendering breaks the orriginal line break made by the subtitles... Some like it, but in fact it is undone...
The issie handbrake induce must also have side effects on other players... The issue should be solved by the source -or- use mkvmerge instread... I think it is not recommended to put amlot of extra code in our software to work-a-round someone else's crap....

Please post the link of the thread to handbreak here so a lot of people from here can add a lot of comments to them....

Well good luck here the result i've been pushing by handbrake :  (note i did not dind at that time the extented tag use for ssa but it is really allowed and ok you wil in time find this in all ssa codecs and official media will have those aslo)

 

https://github.com/H...rake/issues/215

 

https://github.com/H...rake/issues/221

 

Ok what well can be done is perhaps improve gstreamer self to corrcet the parsing from \N to  ' \n' to '\n' or at the end off line just erase it.

[christophecvr]

@littlesat what also can be done is execute the extra find remove space and \n at the end

 

for ssa codecs only since indeed it's not making any sence to run that code for a srt  (SubRip codec). This only cause unfortunately what handbrake does is not wrong it is the evolution ......

 

Off course I'm now analysing it all earlier at the gstreamer ssaparse phase . And see if change is possible if so then send a proposal to gstreamer.

[littlesat]

Thanks... I think thus should not belong to the e2 level... And I understand it is easier to put it in e2 as you can influence it. Hopefully gstreamer will take it!

[christophecvr]

Thanks... I think thus should not belong to the e2 level... And I understand it is easier to put it in e2 as you can influence it. Hopefully gstreamer will take it!

There is well one thing to mention about this.

 

gstreamer does do it that way. If You are working with the own gstreamer suboverlay (the suboverlay.bin then they solve the issue based on the 200A they set at parsing phase )

On a stb we can't use the suboverlay.bin that is unfortunately for video-raw cap only which we can't use.

 

Since we are working with a own developped factory plugin subsink we will have to do it there, or ... for us it's much easier to do it in the application self instead of modifying the buffer into subsink since it's all much easier with c++

(subsink is c code , this means it will be much more code ....)

 

The result :

 

- Unfortunately but handbrake is not wrong.

- gstreamer correct it at parsing phase but then uses code for them on which base they later on will set it 100 % ok in there own suboverlay (only usable by gstreamer self)

  (I will well later on after some tries launch a question if we can eventually improve the code but  it is again an special thing for stb self ??)

 

- So I'm afk that we will have to do this code since it is not done by our own self made non standard plugin subsink. (but indeed and that case I must limit it to codec = "SubStation Alpha" this can be done.

[Erik Slagter]

@Littlesat, yes, now you understand that a problem should be solved where the problem originates. As handbrake is open source, one can easily contribute a patch.

@CVR, the subsink does not do the graphical text rendering, you're still looking in the wron direction, it's done by a wrapper around freetype, don't be stubborn.

[Erik Slagter]

And @Littlesat, I still don't understand why people want to hang on to the original formatting so strongly. If the text uses '-' to switch speaker, you can even make enigma change the text colour.

[littlesat]

You indeed don't understand... but subtitles make these brakes with the '-' on the next row for readability.... in fact the rerendering is an additional feature it manipulates what was intended......

Edited by littlesat, 11 June 2016 - 13:18.

[christophecvr]

@Erik Slagter

 

pure textual subtitles may contain a - so the refromat will directly cause a bug (into subtitles of for example srg or some other dvb based subtitles we suffering off that unwanted changes off color just the text subfile has an wanted -)

The reformat is much more cpu intensif then just a procedure into c++ or c .

 

point is at this time:

 

Modern ssa/ass codecs do contain special chars such as \N

 

This problem is here actual the base feeding more to say it is at codec level.

 

also other players actually suffers from this issue. (wrong centration off ssa codecs subtitles) but they all well just remove end off string or the trailing edge \n.

That we do now also.

 

I just currently sended a message in a still open thread (enhancement in gstreamer)

 

they already solved the problem by replacing the \N by 200A  (to really make it 100 % in c this does require much more code in c++ it's easy)

https://bugzilla.gno...g.cgi?id=625113

 

I added now a request to it.

[Erik Slagter]

You keep explaining things I already know and are completely irrelevant. Come to the point! SSA is completely irrelevant, gstreamer+enigma doesn't play it. The part about reformatting being "cpu intensif" is completely silly.

[christophecvr]

You keep explaining things I already know and are completely irrelevant. Come to the point! SSA is completely irrelevant, gstreamer+enigma doesn't play it. The part about reformatting being "cpu intensif" is completely silly.

Sorry but here the problem is nothing about refromat and colors and ...

1) There are no colors

2)  It is an ssa and not completely irrelevant but extremely relevant this point .

 

Do not mixup the SubRip codec for media muxed with mkvmerge there are no problems with that. and this was never a fact. Also do not mix it up with a external srt file which is also imported on the fligh as a SubRip codec.

 

But is it all not ok that is a fact . And no it comes

 

Actually handbrake 0.10.5 (and a lot off official media and this will be more in future) do merge the code now not as an ass but as an ssa codec and that's different, and yes then newline is \N.

there is actually a general confusion with ssa or ass. This also lets to miscommunication.

ssa has a line break \n sor if You dec a srt to ssa You must put \n for new line and also at the end off the string an \n (otherwise the container build will be wrong)

When You build it like that encode (the ssa like a said above) all will be fine by the final decoded subtitle by gstreamer to a pango-page it will give a string without any extra white space before the \n if there are more then one line in the current subtittle and there will be no trailing edge \n at all. And that just cause the ssa is made correctly.

 

But now with handbrake we are phasing an ass codec (while they tell it's an ssa  that's a whole other issue but the \N is normal for a ass codec).

 

 

 

But the source is an internal codec its is ssa .... wel here it comes actually handbrake 0.10.2 set an ssa codec and that worked perfect. an ssa codec also does not have \N or \h or such special chars.

[Panther-6]

When will finally come this OpenPli-5? Why it takes so long here? Why are other forums much quicklier with new Images than OpenPli?

[MastaG]

You can easily build it youself mate :-)

[Panther-6]

I have no idea how to make images, but you can do it MastaG. Come on, I believe in you MastaG...  

[MastaG]

I'm not going to create and distribute public OpenPLi-5 images.

It's still in development.

 

I'll check it out once the PLi team officially releases it.

Trust me it will be worth the wait

[tapai]

I'm not going to create and distribute public OpenPLi-5 images.

It's still in development.

 

I'll check it out once the PLi team officially releases it.

Trust me it will be worth the wait

 

We (OpenPLi image Fans) are patient and we believe, in fact, that it is worth to wait, but is it a matter of days, weeks or months ;-)

[buc61b]

I'm not going to create and distribute public OpenPLi-5 images.
It's still in development.

I'll check it out once the PLi team officially releases it.
Trust me it will be worth the wait

Will it be any changes for amiko alien since your last image?




Sent from my iPhone using Tapatalk